For many of our Salesforce development projects we are doing trunk-based development. I only use short-lived feature or bug branches which are merged into the trunk (branch) using Pull Requests. Before a PR can be merged it needs to be approved by a mandatory Code Review.

I would like to have a Bitbucket pipeline script which rejects a PR when any of the following steps fails:

  1. Create Scratch Org
  2. Deploy Code
  3. Run all tests

I have built such scripts in the past based on my own minimal scriptings skills using flaky Docker images for SFDX and hope that now all of that stuff exists and I can just use a professional script that:

  • Uses a proper Salesforce-maintained Docker SFDX
  • Uses the scratch org creation sh scripts in the current repository
  • Minimal certification key complexity (just scratch org no packages)
  • 2
    Just FYI as uses Jenkins pipelines, but supports multiple scratch org configs as well as multiple branches claimvantage.github.io/sfdx-jenkins-shared-library. I doubt that there is a commercial market for this kind of thing though, so will be interesting to see what answers you get.
    – Keith C
    Feb 6, 2020 at 10:11
  • 2
    We use the same development model and Bitbucket - would love to see if others have worked this out Feb 6, 2020 at 12:55
  • There is an official repo from Salesforce but I don't like their script as it uses the inflexible JWT DevHub authentication. I opened an issue to improve that github.com/forcedotcom/sfdx-bitbucket-org/issues/3 Feb 7, 2020 at 14:51

1 Answer 1


Here is a short Bitbucket pipeline script that solves the purpose

image: salesforce/salesforcedx:latest-full

    - step: &verifyInScratchOrg
        name: Create scratch org, deploy & test metadata
            - echo $DEV_HUB_URL > devHubURLFile
            - sfdx force:auth:sfdxurl:store -d -f devHubURLFile
            - rm devHubURLFile
            - chmod +x ./scripts/org/verificationScript.sh
            - ./scripts/org/verificationScript.sh

      - step: *verifyInScratchOrg
      - step: *verifyInScratchOrg

To use this script you need to configure a Secured Repository variable, DEV_HUB_URL to connect to Dev Hub.

Steps to generate Auth URL:

  1. Authorize the org whose auth URL you need using sfdx force:auth:web:login -a OrgAlias
  2. Log in with your credentials and authorize the Global Connected App.
  3. Once you've successfully authorized the org, close that browser tab and run sfdx force:org:display -u <OrgAlias> --verbose command (substituting the appropriate OrgAlias).
  4. This will display the Auth URL for the org. You can then add that as a secured repository variable in your Bitbucket pipeline to connect to that org.

The above script will run whenever a Pull request is created from any feature branch or bugfix branch. It merges the destination branch into your working branch before it runs, ensuring the target branch doesn't fail when code is merged giving reviewer more confidence

I have provided a relative path to Scratch ORG creation script which is part of the repository, a sample scratch org creation script can be

source `dirname $0`/config.sh

execute() {
  $@ || exit

echo "deleting old scratch org"
sfdx force:org:delete -p -u $SCRATCH_ORG_ALIAS

echo "Creating scratch ORG"
sfdx force:org:create -a $SCRATCH_ORG_ALIAS -s -f ./config/project-scratch-def.json -d 1

echo "Pushing changes to scratch org"
execute "sfdx force:source:push"

echo "Assigning permission"
execute "sfdx force:user:permset:assign -n Admin"

echo "Running apex tests"
execute "sfdx force:apex:test:run -l RunLocalTests -w 30"

echo "Running jest tests"
npm install
execute "npm run test:unit"
  • I am creating a temporary dev hub URL file because force:auth:sfdxurl:store only accepts a file name as parameter and Auth URL should never be part of the repository and should be configurable by repository admins
  • I am also setting the permission for executable script file to avoid permission exceptions
  • I love this script as it is already covering 99% of my requirements. I am facing the problem that the pipeline is not stopping/failing when the SFDX deployment fails for some reason. Do you know why? Feb 25, 2020 at 8:46
  • 1
    Bitbucket pipeline looks at the exit code of subscript to fail the build. In the above example, we can either use JQ parser to parse the status code and return a non zero value if any of the steps fail to fail the entire build or simply move all the sfdx command to the Bitbucket pipeline file and let bitbucket handle everything. Feb 25, 2020 at 11:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .