YAML anchors + Overriding + Reusing deployment variables

Ming Han Chung May 1, 2020

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

 

 

 

3 answers

2 votes
Christopher Bentzrud April 10, 2023

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 21, 2023

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 

Like Christopher Bentzrud likes this
Christopher Bentzrud August 15, 2023

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.

2 votes
stefan.cross January 13, 2021

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... 

2 votes
Abryan Manalansang August 20, 2020

@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 January 6, 2021

@Abryan Manalansang  did you get a solution to this?

stefan.cross January 13, 2021

likewise! This would save me a lot of effort

Miguel Lopez Ariza September 2, 2022

did this work for you?

Deleted user March 10, 2023

Any updates on this? Looking for exactly same solution

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events