I would like to deploy to different environments in our Bitbucket pipeline. Our environments are limited to three, and I'd like to limit the options available when starting the pipeline.
A pipeline right now looks like this:
- name: ENVIRONMENT
- step: *plan-cosmos
- step: *apply-cosmos
I would like to limit the possible variables:
- name: ENVIRONMENT
enum: [dev, staging, prod]
Is this possible?
PS. How do you copy paste into this editor? It decimates new lines, even in code blocks.
We only have a set number of environments, I want to limit the possibility for errors when others deploy. Therefore I want the options to be limited by an enum. I think this makes sense since custom pipelines are only triggered manually and require user input anyway.
I have looked into using deployments, but unfortunately it doesn't satisfy our use case. We have a monorepo with terraform templates for all our infrastructure for a project. Using deployments, I can't specify the same environment twice in the same pipeline. E.g. if I want a manual deployment step for cosmos to dev and declare deployment: dev for that step, then I cannot do that for any other resource since deployment: dev can only occur once. I would have to deploy everything in a single step, I don't want that.
Instead, I have several custom pipelines for each piece of the infrastructure, as seen above. The first step is automatic and reviews any changes that will occur, the last step is applying it to the targeted environment.
What I'm after:
I have no need to control permissions, a user that has repo access has deploy access.
Unfortunately it is not the same, it doesn't work. Deployments are limited to be declared once per pipeline. This is my full pipeline, without the definitions:
Now all custom steps are able to be run individually and target all three different environments. This enables me to run one specific commit and one specific piece of infrastructure.
With deployments, this block would have to be repeated for each environment, and that is if deployments could be repeated.
Ah, got it, indeed this is somewhat an unusual setup I'd say, because from a single repo (that is usually a single service) you're controlling actually multiple service to multiple environments. See https://jira.atlassian.com/browse/BCLOUD-18771
I don't know what your repository looks like, but personally I would probably split those services into 3 separate repositories if they should be managed independently.
...hey are a part of us, shaping how we interact with the world around us. The same holds true for programming languages when we think about how different kinds of vulnerabilities raise their heads in t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events