Use duplicate environment in the same pipeline (Bitbucket Pipelines)

cvivieca January 29, 2020

I have three deployments environment Test, Staging and Production. Each one has some environment variables that the another also has (e.g. DEPLOY_URL). DEPLOY_URL has a different value per deployments environment. 

Actually, we can't have the deployment keyword duplicate in the pipeline definition.  I wanna know how can I achieve this in another way. This is because I have a step that deploy the application (Step One) and another that trigger a service based on the current deployment (Step Two). 

For example:

definitions:

steps:
- step: &stepOne
name: Run Step One
script:
- ... commands

- step: &stepTwo
name: Run Step One
script:
- ... commands
pipelines:
branches:
master:
- step:
<<: *stepOne
deployment: Production
- step:
<<: *stepTwo
deployment: Production
develop:
- step:
<<: *stepOne
deployment: Staging
- step:
<<: *stepTwo
deployment: Staging

 

2 answers

1 accepted

2 votes
Answer accepted
Sergio Flores January 31, 2020

Sadly, this can't be done yet.

If you want to use deployments, you will have to merge your steps into one.

Actually, there's an open issue on Atlassian's Jira:

https://jira.atlassian.com/browse/BCLOUD-18261?error=login_required&error_description=Login+required&state=1ff78d4f-18fc-44ad-82be-5771fbf0b731

I'm facing the same problem right now, trying to figure out how i can organize things better without deployments.

In summary:

- Multiple steps (parallel or not) = don't use deployment

- Single steps = use deployment

That's what i found researching through community forums, hope this helps!

Waiting for Atlassian Team to implement this.

cvivieca April 10, 2020

Thanks @Sergio Flores 

I will implement it as you suggest. 

0 votes
Adam Bellas June 27, 2020

While this isn't a solution, it might help you think of your issue a bit differently. I, too, ran into this problem as I broke up my pipeline into steps. When I realized I couldn't put the "staging" or "production" deployment marker on all the steps, I paused and remembered the value deployment markers bring to my workflow.

My number one reason for deployment markers is so I can trace a deployment back to the Jira issues that were part of it. This helps me author release notes, etc. This all led me to place the deployment marker on the step that builds the Docker image with the new code and publishes it to Amazon ECR. All the other steps in the pipeline didn't really have a direct impact on the code that was just moved. 

Hope this helps in some way. And sorry I'm so late to the game - wanted to see if my $0.02 can help.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events