Use duplicate environment in the same pipeline (Bitbucket Pipelines)

[cvivieca]

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

[Sergio Flores · Accepted solution]

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]

Thanks @Sergio Flores 

I will implement it as you suggest. 

[Adam Bellas]

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.