Resolving Issues With Bitbucket Shared Pipeline and Environment Variables

Resolving Issues With Bitbucket Shared Pipeline and Environment Variables

Resolving Issues With Bitbucket Shared Pipeline and Environment Variables

Resolving Issues With Bitbucket Shared Pipeline and Environment Variables

Bitbucket has several frustrating limitations around shared pipelines, especially when environment variables are involved.

The Atlassian documentation explicitly calls out one of them:

Note: There is a known limitation with using variables in custom pipelines that utilize a shared Pipeline Configuration. If a repository imports a shared Pipeline Configuration and uses it as part of a custom pipeline, variable values specified at runtime via the UI will not pass to the pipeline execution. Instead, the default values specified in the exported Pipeline configuration will be used.

Source: https://support.atlassian.com/bitbucket-cloud/docs/share-pipelines-configurations/

If you need to use runtime input variables with a shared pipeline, there are two main options.

1. Capture user input first, then call a child pipeline

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
pipelines:
  custom:
    deploy:
      - variables:
          - name: ENV
          - name: VERSION
      - step:
          name: Call child
          type: pipeline
          custom: deploy-child
          input-variables:
            DEPLOY_ENV: $ENV
            APP_VERSION: $VERSION

    deploy-child:
      - step:
          script:
            - echo "$DEPLOY_ENV"
            - echo "$APP_VERSION"

This approach works for passing user-provided values forward, but it comes with a major drawback: you completely lose access to Bitbucket Deployments features, including environment-scoped variables.

Source: https://support.atlassian.com/bitbucket-cloud/docs/child-pipeline-step-options/

2. Trigger the shared pipeline through the API and pass the required variables

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
image:
  name: nodejs:24.10.0-slim

definitions:
  imports:
    pipeline-scripts: shared-pipelines:main
  steps:
    - step: &trigger-shared-deploy
        name: Trigger shared deploy pipeline
        script:
          - 'echo "Trigger target: ${BITBUCKET_WORKSPACE}/${BITBUCKET_REPO_SLUG}@${BITBUCKET_BRANCH}"'
          - pipe: atlassian/trigger-pipeline:5.10.1
            variables:
              ATLASSIAN_ACCOUNT_EMAIL: $ATLASSIAN_ACCOUNT_EMAIL
              ATLASSIAN_API_TOKEN: $ATLASSIAN_API_TOKEN
              ACCOUNT: $BITBUCKET_WORKSPACE
              REPOSITORY: $BITBUCKET_REPO_SLUG
              REF_TYPE: branch
              REF_NAME: $BITBUCKET_BRANCH
              CUSTOM_PIPELINE_NAME: nodejs-build-deploy-wrapper
              WAIT: "false"
              DEBUG: "true"
              PIPELINE_VARIABLES: >
                [{
                  "key": "ENV_NAME",
                  "value": "${ENV_NAME:-dev}"
                },
                {
                  "key": "EXAMPLE_SECRET",
                  "value": "${EXAMPLE_SECRET}"
                }]
pipelines:
  custom:
    development:
      - variables:
          - name: ENV_NAME
            default: dev
      - step:
          <<: *trigger-shared-deploy
          deployment: development

    nodejs-build-deploy-wrapper:
      import: nodejs-build-deploy@pipeline-scripts

  pull-requests:
    "**":
      import: nodejs-build-deploy@pipeline-scripts

This second approach is usually more practical if you need both shared pipeline logic and deployment-specific variables. The tradeoff is that it is more complex because you must trigger the pipeline indirectly through the Bitbucket API.