Configuring CI Using Bitbucket Pipelines and Nx

Below is an example of a Bitbucket Pipelines, building and testing only what is affected.

bitbucket-pipelines.yml
1image: node:20 2 3clone: 4 depth: full 5 6pipelines: 7 pull-requests: 8 '**': 9 - step: 10 name: 'Build and test affected apps on Pull Requests' 11 script: 12 # This line enables distribution 13 # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested 14 - npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci" 15 - npm ci 16 17 - npx nx-cloud record -- nx format:check 18 - npx nx affected -t lint test build e2e-ci --base=origin/main 19 20 branches: 21 main: 22 - step: 23 name: "Build and test affected apps on 'main' branch changes" 24 script: 25 - export NX_BRANCH=$BITBUCKET_PR_ID 26 # This line enables distribution 27 # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested 28 - npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci" 29 - npm ci 30 31 - npx nx-cloud record -- nx format:check 32 - npx nx affected -t lint test build e2e-ci --base=HEAD~1 33

The pull-requests and main jobs implement the CI workflow.

Get the Commit of the Last Successful Build

Unlike GitHub Actions and CircleCI, you don't have the metadata to help you track the last successful run on main. In the example below, the base is set to HEAD~1 (for push) or branching point (for pull requests), but a more robust solution would be to tag an SHA in the main job once it succeeds and then use this tag as a base. See the nx-tag-successful-ci-run and nx-set-shas (version 1 implements tagging mechanism) repositories for more information.

We also have to set NX_BRANCH explicitly.