Use enum for variable in custom pipeline

Johan Karlsson April 23, 2020

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:

 custom: 
deploy-cosmos-to-env:
-
variables:
-
name: ENVIRONMENT
-
step: *plan-cosmos
-
step: *apply-cosmos

I would like to limit the possible variables:

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.

1 answer

0 votes
Radek Antoniuk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 23, 2020

I'm not sure I understand what is your usecase, can you describe it a little bit more?
Also, take a look at this example for multi-environment handling.

Johan Karlsson April 23, 2020

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.

Screenshot from 2020-04-23 12-17-13.png

What I'm after:

Screenshot from 2020-04-23 12-27-56.png

Like Radek Antoniuk likes this
Radek Antoniuk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 28, 2020

I think that you are just trying to implement deployment permission per environment - this is already available in BitBucket pipelines.

Johan Karlsson May 5, 2020

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:

Screenshot from 2020-05-05 10-15-35.png

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.

Radek Antoniuk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 5, 2020

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.

Johan Karlsson May 11, 2020

I had already voted for that issue :) The monorepo approach has brought some headaches so far, but its also very convenient in some ways. I will sleep on it, thanks for your input.

Like Radek Antoniuk likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events