Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Usage of Deployment variables on multiple steps

Hi,

I have broken down my pipeline in multiple steps to speed it up, and I'm using deployment variables to manage secrets:

pipelines:
default:
- step:
name: Step1
deployment: test
script:
- echo $DEPLOYMENT_CREDENTIALS > /tmp/keyfile.json
- parallel:
- step:
  name: Step2
   deployment: test
script:
- echo $DEPLOYMENT_CREDENTIALS > /tmp/keyfile.json
- step:
name: Step3
deployment: test
script:
- echo $DEPLOYMENT_CREDENTIALS > /tmp/keyfile.json

 

It looks like my pipeline it invalid, as it doesn't allow to specify "deployment" multiple times, however if I specify it only once the other steps do not find the variables. 

Is it possible to have multiple steps which make use of deployments ? Otherwise any suggestion on how to implement such scenario?

Cheers

 

Nicola

15 answers

this feature is A MUST

we also facing same issue. we have steps like build docker image and push to ECR different AWS account. and another step we are publishing to the Kubernetes (again on different Kubernetes based on deployment).

``` - step: &deploy_set_env
name: "Deploy: Set Env"
clone:
enabled: false
artifacts:
- .env
script:
- printenv | xargs -L 1 echo export > .env```

 

and then in the following steps:

```

- step: &deploy
name: "deploy"
script:
- |
source .env

...```

Like # people like this

I used this approach but getting error in sourcing the .env file

bash: export: `%s': not a valid identifier

This worked well. However, the ability to tell multiple steps to use the same environment is necessary

Like # people like this

Same issue.

When will we have a solution?

You cant use the same deployment in different steps. It is supossed to be used one time. So, what you can do is to create one deployment for each step and use it in the pipeline.

Like...

Lab-deploy-1 to execute a script

Lab-deploy-2 to execute a seconds script

Until they allow us to repeat deployments in steps thats all you can do.

Any updates on this please? 

I'm facing almost the same issue. I was looking for some sort of environment variable that bitbucket is pushing by default (like BITBUCKET_DEPLOYMENT_ENVIRONMENT) in order to get the names of the steps in a pipeline. And I was thinking to use the one I mentioned but .... I need to declare fake environments in settings. Please let us use `deployment` or expose the name of the steps in an environment variable so that we don't need to repeat ourselves.

Is there any other way to achieve this?

2 votes
Deleted user May 04, 2020

Here we are facing the same issue. This will be really nice to have.

Like # people like this
Deleted user May 05, 2020

Done. Thank you for pointing me that.

2 votes
Philip Hodder
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jun 13, 2019

Hello Nicola,

Currently, you can only define a particular deployment environment once per pipeline. In the example you have provided, you have used it in three steps. Which is why you're get errors in your pipeline.

You could try one of the following strategies. They have various trade-offs though.

  1. Consolidate the steps into a single one. Though, you'll lose the performance improvements you're trying to add.
  2. Create 3 separate environments, then reference each one once in each step. However, this will need duplicate environment variable configuration across the environments. And will also cause three Test environments to show in the dashboard, for what I assume is a single deployment?
  3. Set the Deployment credential as a repository-level variable. This will make it accessible to any pipeline that runs in the repository. But could have security concerns depending on how much trust other users with write access have.

You might also find these feature request interesting to follow: 

If neither of those cover what you'd like, you can also create a new feature request.

It would be helpful for us if you could add details of your use-case to one of those feature requests.

Thanks,

Phil

Deleted user Feb 28, 2020

I have the same issues here. I have three steps to separate functionality but not be able to define the same deployment. This means that the variables that are need to all steps must either be defined elsewhere (very ugly and approach) or create a huge step (also ugly).

And I would like another problem that appears with this deployment limitation. I was using a python image in one step to achieve certain goals. And on the next step I was using another image. Having to merge the multiple steps to one means that I will have to do with one image for all of my goals in this step.

This should be fixed asap.

Like # people like this

Facing the exact same issue there. 
I've added more verbose env variables such as DEV_VARIABLE_NAME, PROD_VARIABLE_NAME in order to keep my multiple steps process.

Please consider fixing this ASAP :) 


Like # people like this

It would be great to be able to reuse the deployment variables.

Like # people like this

More than two years and still nothing?

Like # people like this

Still waiting for a fix.

Like # people like this

I'm having the exact same issue - waiting for a fix.

Like # people like this

Exactly the same issue, no acceptable solution to this yet.

Like # people like this

On the same boat, please allow deployment variables to be shared across steps.
Artifacts wont work for secret variables.

Like # people like this

Wow, more than 3 years and no update

Like # people like this

Stages were introduced, where you can group multiple steps
if you define the "deployment:" variable at stage, the env variables will be shared across all steps within this stage.

Looking for this solution right now for our team. It would be very helpful!

Create different deployment in the branch. Like lab-dep-1 lab-dep2 and use it for the steps in the same deployment. Is the only thing you can do.

I would like this to be implemented as well.

 

Ideally we could define a deployment variable for multiple steps for an entire pipeline

Not sure what it cause so much problems for so long. Solution is very simple

Just make it like this. First grab  env variables from deployment definition into artifact, then use them in next steps.

steps:
   step_init: &build_init_step
     script:
      - touch environment.sh
      - echo "export REPOSITORY=$REPOSITORY" >> environment.sh
      - echo "export BUILD_TAG=$BUILD_TAG" >> environment.sh
      - echo "export TARGET_HOST=$TARGET_HOST" >> environment.sh
   artifacts:
    - environment.sh
   step_deploy: &build_deploy_step
     script:
      - source environment.sh

 

pipelines:
  branches:
    'master':
   - step:
     name: Build "Test" environment images
     deployment: Test
     <<: *build_init_step
   - parallel:
     <<: *build_images_parallel_test
   - step:
     name: Deploying to "Test"
     <<: *build_deploy_step

Our company has decided to slowly migrate to an alternative version control supplier solely because this issue has been around for multiple years and all the suggested work arounds have the potential to expose the pipeline variables. 

Anyone on this thread, look into stages, which were recently implemented; they provide multi step deployments, but have some limitations, like no parallel steps in them, and no manual steps in them: https://support.atlassian.com/bitbucket-cloud/docs/stage-options/

Are there any plans for stages to run in parallel eventually? 

Like Jose María Rodríguez likes this

How is it possible that everything they do have so many limitations?

Like Jon Kofal likes this

wow wow

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events