Branch-Specific Environment Variables

Issue #12923 wontfix
Chris Brantley
created an issue

We deploy to different Elastic Beanstalk environments depending on the branch. For example, we have a dev branch that gets deployed to a dev environment.

The global environment variables are very helpful but it would be extremely helpful to specify environment variables that apply ONLY for certain branches. The same logic used to match the pipelines branch could apply. So for example I could specify that APPLICATION_ENVIRONMENT should be "my_dev_environment" only if the branch starts with "dev".

BTW, we are working around this by overriding the ENV variables in the build script but it would be cleaner to maintain all ENV variables in the pipelines interface.


Comments (9)

  1. Joshua Tjhin

    Thanks Chris for the feedback. Indeed the workaround is to set the environment variables inside your configuration. This has additional benefits that it is versioned with your repository. Given that we have variables at the team and repository-level, adding branch-level variables might make it harder for other users to workout the actual variable used by the pipeline and therefore I'll close it as we are unlikely to add it for this use case.

  2. Kenny DiFiore

    It would be nice to have a solution for branch-specific variables that are sensitive, so they aren't committed to the repo and available for all who have access to the repo to see.

  3. Kostya Kostyushko

    We also need environment variables per branch! it is very common to have pipelines branch dependent and having the same env variables in DEV, STAGING and PROD doesn't make any sense! and it is even dangerous, nobody wants by error upload code to production that expected to go to DEV. Workaround proposed by Joshua may work, but makes it more complex than Just having variables per branch.

  4. Will Selway

    +1 for this as a feature, it would make pipelines so much better.

    I think this would be a lot more powerful than being able to set them per 'Deployment'.

    It would be easier to Just have Staging -> AWS_ACCESS_KEY, instead of an endless list of STAGING_AWS_ACCESS_KEY, PRODUCTION_AWS_ACCESS_KEY, UAT_AWS_ACCESS_KEY. There would also be no way to accidentally use the wrong access key in the wrong environment.

  5. Log in to comment