How to access deployment variables in multiple steps (or work around it)

[Ian Klek]

I've been fighting with bitbucket pipelines for a while now.

I need to perform a step that requires deployment level variables, but is not a deployment

I know about Deployments, and I know that I can only have a single deployment step. I'm ok with that because the deployment is linked back to the Jira ticket and I do want to know when something has actually been deployment successfully and to which environment.

BUT

Take Terraform for example. Before deploying infrastructure, I want to see what it's going to change before applying it for real, so i must factor in a manual trigger.

For this I have a -plan step, which is environment specific. I don't want to make that a deployment because it's not actually deploying, yet how else can I get the variables??

- step: &plan
    image: hashicorp/terraform
    name: Validate and Plan
    script:
      - cd src
      - terraform init -backend-config="bucket=$BACKEND_BUCKET" -backend-config="key=$BITBUCKET_DEPLOYMENT_ENVIRONMENT/terraform.tfstate"  -upgrade
      - terraform validate
      - terraform plan 

On Azure DevOPs this is simple. Bitbucket just needs to separate the deployment variables and defining what is an actual deployment step.

So my question to bitbucket is: how can I achieve this? I can't pass an argument. Do I have to output a var to a file each time?

[Patrik S]

Hello @Ian Klek ,

Thank you for reaching out to Atlassian Community!

Deployment variables are indeed only available for deployment steps or deployment stages to the specific environment where they were defined.

However, you also have the option to create Workspace variables or Repository variables, that will not be attached to deployments and will be available to every step.

When you defined a variable with the same name in multiple levels, this is the order of precedence: Workspace variables > Repository variables > Deployment variables.

This means that you could, for example, define a variable at Repository level - which would contain the generic value of when you don't want to actually deploy - with the same name you currently use for the Deployment Variable. This way, for steps that are not actually a deployment, the Repository variable value would be used. For steps that are an actual deploy, the deployment variable would take precedence.

Hope that helps! Let me know if you have any questions.

Thank you, @Ian Klek !

Patrik S

[Ian Klek]

Thanks @Patrik S but issue is that i need to perform a step that requires deployment level variables, but is not a deployment. This is standard behaviour for other ci/cd providers.

[Patrik S]

Hello @Ian Klek !

Got it! I'm afraid that currently, deployment variables are only available for deployment steps, but for the use-case you shared, in case passing the variables as a parameter when the pipelines are triggered is an option for you, you can try using custom pipelines with variables.

With custom pipelines, you can configure all the variables that need to be manually supplied when the pipeline is manually triggered. To enable the variables, you need to define them on your YML file like the below example : 

pipelines:

  custom:

    custom-name-and-region: #name of this pipeline

      - variables:          #list variable names under here

          - name: Username

          - name: Role

            default: "admin"          # optionally provide a default variable value

          - name: Region

            default: "ap-southeast-2"

            allowed-values:           # optionally restrict variable values

              - "ap-southeast-2"

              - "us-east-1"

              - "us-west-2"

      - step: 

          script:

            - echo "User name is $Username and role is $Role"

            - echo "and they are in $Region"

Then, once you manually trigger the pipeline, you will be prompted to provide the values for all the configured variables.

Thank you,@Ian Klek !

Patrik S

[Ian Klek]

Hi @Patrik S I appreciate your help but this is not a solution. I'm looking for feedback as to whether this has been acknowledged by your product team and if there are any plans to improve? As I said, I'm after something which is standard behaviour elsewhere. If there are no plans to improve, then we'll have to look at moving elsewhere.

Thanks

[Patrik S]

Hey @Ian Klek !

I think we already have a feature request to implement the functionality you are looking for : 

• https://jira.atlassian.com/browse/BCLOUD-20821

This is to add the ability to provide step-specific environment variables, without having to use deployment. 

I would suggest you to add your vote there, since this helps both developers and product managers to understand the interest. Also, make sure you add yourself as a watcher in case you want to receive first-hand updates from that ticket. Please note that all features are implemented with this policy in mind.

If you think that the feature request does not cover your use case, please let me know.

Thank you @Ian Klek .

Patrik S