You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
name: Validate and Plan
- 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?
Hello @ian ,
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.
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 !
Hello @ian !
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 :
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
allowed-values: # optionally restrict variable values
- 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 !
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.
Hey @ian !
I think we already have a feature request to implement the functionality you are looking for :
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 .