YAML anchors + Overriding + Reusing deployment variables

[Ming Han Chung]

So here is a doozy

1. For some reason bitbucket does not allow us to use the deployment variables for more than on step.
2. To get around this we are passing in variables through the use of artifacts to the next step.
3. As one of those variables is an AWS Key we obviously don't want to pass that off as an artifact to leave out in the open.
4. To get around this we are creating a separate AWS variable at the repo level for each environment.

The problem is if you are reusing steps vs YAML anchors (say s3 deploy pipe), how would you get the right AWS variable to be called in the reused pipes? Sample code below. So say I have different keys for Dev and UAT

definitions:
 - step: &build-and-deploy 
     name: Build And Deploy 
     script:
        - pipe: atlassian/aws-s3-deploy:0.2.4 
          variables: 
            AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID 
            AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY 
pipelines:
  branches:
    dev:
      - step: *build-and-deploy
    uat:
      - step: *build-and-deploy

[Christopher Bentzrud]

We had a similar issue that we found a workaround for.

Consider the following step where we use the trigger-pipeline pipe, and want to specify later which pipeline to trigger:

        - step: &run-deploy-pipeline
              name: Run a deploy pipeline
              trigger: manual
              script:
                  - &deploy-script
                    pipe: atlassian/trigger-pipeline:5.0.0
                    variables: &deploy-variables
                        BITBUCKET_USERNAME: $BITBUCKET_USERNAME
                        BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
                        REPOSITORY: "repo-to-run-in"
                        REF_TYPE: "tag"
                        REF_NAME: $BITBUCKET_TAG
                        CUSTOM_PIPELINE_NAME: "pipeline-name" # This is the value we want to override
                        PIPELINE_VARIABLES: >
                            [{
                              "key": "APPLICATION_VERSION",
                              "value": "$BITBUCKET_TAG"
                            }]
                        WAIT: "true"

Here we needed to override/replace the CUSTOM_PIPELINE_NAME variable in this pipe. Note the various anchors we created, they're all necessary.

Using the step and performing the replacement looks like this:

                - step:
                      <<: *run-deploy-pipeline
                      name: "Deploy to Some Env"
                      script:
                          - <<: *deploy-script
                            variables:
                                <<: *deploy-variables
                                CUSTOM_PIPELINE_NAME: "my-deploy-pipeline"

Feels very hacky, but does work. :) 

[Bhuvnesh Bhatt]

Hi @Christopher Bentzrud i wanted some help here , can we define extra variables after defining the anchor like in anchor we defined var1 , var2 , now in some step in our pipeline we use the anchor and defined some var3, is it possible?

Edit: this is working , thanks for the solution 

[Christopher Bentzrud]

Yes, you should be able to add any number of variables below CUSTOM_PIPELINE_NAME in the example I gave. If they already exist in the anchor, then you will override those values. Otherwise they'll just be added.

[stefan.cross]

There a possible hacky solution here: https://community.atlassian.com/t5/Bitbucket-questions/Bitbucket-Pipeline-Using-a-different-environmental-variable/qaq-p/1023246

Basically use a step that writes env vars to a file and pass that around... 

[Abryan Manalansang]

@Ming Han Chung I have the same issue. I want to reuse codedeploy pipe and replace the value of DEPLOYMENT_GROUP.

 master:
   - step: *build
   - step:
       <<: *deploy
       name: Deploy to Prod
       deployment: production
       trigger: manual
       script:
         variables:
           DEPLOYMENT_GROUP: 'production-deployment-group'

[John C]

@Abryan Manalansang  did you get a solution to this?

[stefan.cross]

likewise! This would save me a lot of effort

[Miguel Lopez Ariza]

did this work for you?

[Deleted user]

Any updates on this? Looking for exactly same solution