If I push to `branch-A`, I want to run tests using `branch-A` envs.
If I push to `branch-B`, I want to run tests using `branch-B` envs.
How can I do that without creating new `steps` just to change the environmental variable?
@alexwonguhuru, if you only need the variable variation for you deployments, you should be able to use Deployment Variables to do that. They'll let you define different values for the same key on different deployment steps.
We have documentation about it here: https://confluence.atlassian.com/bitbucket/variables-in-pipelines-794502608.html
An example bitbucket-pipelines.yml would be:
pipelines: branches: develop: - step: name: Deploy to Test deployment: test script: - echo $MY_ENV # Would print www.mysite.com/develop staging: - step: name: Deploy to Staging deployment: staging script: - echo $MY_ENV # Would print www.mysite.com/staging production: - step: name: Deploy to Production deployment: production script: - echo $MY_ENV # Would print www.mysite.com/production
The variables are configured in the Repository Settings -> Pipelines -> Deployments section, per environment.
Currently Pipelines only supports those 3 deployment environments. However, we are currently working on extending this to more environments. You can follow the progress of this feature here: https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible
Thanks,
Phil
Hi Alex,
I am not on the Bitbucket Team, but I will try to help.
I know you'd like to avoid creating additional steps, but have you tried using mutliple, smaller steps so that you can re-use all of the parts that are common?
https://bitbucket.org/site/master/issues/12750/allow-multiple-steps
If this doesn't meet your needs, feel free to create an issue in the public issue tracker for Bitbucket: https://bitbucket.org/site/master/issues?status=new&status=open&component=Pipelines
I know that the team listen to Customer feedback to improve our products.
I hope that helps!
Hi Martyn,
Thank you for the response. I tried dividing it into smaller steps as you suggested.
Test
Prerequisite
- Repository Env already has `MY_ENV=hello`
branch A
- step1: MY_ENV=world
- step2: echo $MY_ENV (result: `hello`)
Conclusion
Basically on a new step, whatever ENV I set in the previous step gets reset. I will create an issue in the public issue tracker.
have you considered something like this...
Prerequsite
- Repository ENV already has `MY_ENV_A=hello' and 'MY_ENV_B=world`
- common steps
- unique step: echo $MY_ENV_A
branch B
- unique step: echo $MY_ENV_B
Hi Martyn
Sorry not being clear.
My env is like the following
KEY: MY_ENV
VALUE: 'www.mysite.com/staging'
Depending on the branch I want to replace the key `MY_ENV` with a different value, not a different key.
If I deploy to `develop`, `MY_ENV` should be `www.mysite.com/develop`.
If I deploy to `staging`, `MY_ENV` should be `www.mysite.com/staging`
The `MY_ENV` is a process env inside my server files.
Thank you Phil, this is exactly what I was looking for.
> Currently Pipelines only supports those 3 deployment environments. However, we are currently working on extending this to more environments.
I am looking forward to this because I have more than 3 deployment environments. I have watched it.
Thanks again!
I would like to add my own take on this as a had to deal with a variation of this. I needed to have environment variables for branches which deployments doesn't quite cover in that you can only set a deployment target for a single step.
I realise this isn't exactly what you are after, but I would like to add it for others who may end here, but this was my solution
definitions: steps: - step: &set-environment name: Set Environment artifacts: - environment.sh - step: &build name: Build script: - source environment.sh - build.py $ENVIRONMENT - step: &test name: Test script: - source environment.sh - test.py $ENVIRONMENT - step: &deploy name: Deploy script: - source environment.sh - deploy.py $ENVIRONMENTpipelines: development: - step: <<: *set-environment script: - echo export ENVIRONMENT=development >> environment.sh - step: *build - step: *test - step: <<: *deploy deployment: Development staging: - step: <<: *set-environment script: - echo export ENVIRONMENT=staging >> environment.sh - step: *build - step: *test - step: <<: *deploy deployment: Staging production: - step: <<: *set-environment script: - echo export ENVIRONMENT=staging >> environment.sh - step: *build - step: *test - step: <<: *deploy deployment: Production
This is a great workaround. I'd just gotten to this blocker with deployment when I came across this!
A good idea, but be careful if thinking of using with credentials as will leave them hanging around as an artifact... So best not used for sensitive details
It looks like you're new here. Sign in or register to get started.