Pipeline specific environment variables per branch (Branch variables)

Issue #13474 duplicate
Marc-André Arseneault
created an issue

A lot of us have a branch per environment (development, stage, production).

Presently, the environment variables are set for the complete repository (Repository variables) and for the team or developer account (Team and individual account variables).

Team or individual account variables can be overridden by repository variables.

In the same order of ideas, we should consider to add the Branch variables level to offer a different environment variable values per branch (or environment).

Team or individual account variables can be overridden by repository variables, and repository variables can be overridden by branch variables.

Team/Individual > Repository > Branch.

Eg 1: Branch 1

  • Team/Individual: SECRET=FOO

  • Repository: SECRET=BAR

  • Branch: SECRET=BAZ

  • RESULT: SECRET=BAZ

Eg 2: Branch 2

  • Team/Individual: SECRET=FOO

  • Repository: SECRET=BAR

  • Branch: SECRET is undefined

  • RESULT: SECRET=BAR

Official response

  • Philip Hodder staff

    Hi everyone,

    I'd like to clarify why Matt marked this as a duplicate of #13676.

    As part of deployment permissions, we'll be adding the ability to create environment variables scoped to a particular deployment environment. For example setting up AWS_ACCESS_KEY_ID that is only available when performing a production deployment.

    We'll be starting work on deployment permissions soon. So, we'll be posting updates on that ticket. This will also include when we have deployment scoped variables available.

    That appears to cover the use-cases that have come up in this ticket. If you have a use-case that isn't related to deployment variables, I suggest you open a new ticket with more details of your use-case.

    Thanks,
    Phil

Comments (17)

  1. Joshua Tjhin staff

    Hey Marc,

    Is this so you can have different values for the same variable name for different branches? If so, have you considered setting the variable in your pipeline scripts?

    e.g.

    Repository: SECRET_PROD=BAR

    then in your pipeline scripts for your production branch

    script:
      - export SECRET="$SECRET_PROD"
    
  2. Matt Ryall staff
    • changed status to wontfix
    • edited description

    We're not planning to implement branch variables as described above, but at some point we would like to introduce special deployment-specific variables as part of #12844. This would allow the ability to deploy (and access to deployment authentication credentials) to be restricted to a small set of users.

  3. Kostya Kostyushko

    Using

    script:
      - export SECRET="$SECRET_PROD"
    

    inside bitbucket-pipelines.yaml has a potential security break.

    Let say, I have two different users for CI (USER_PROD and USER_STAGING). USER_STAGING has no write access to USER_PROD and vice versa. But, nobody can stop to define export USER="$USER_PROD" in staging branch, and automatically have access to PRODUCTION environment this way.

  4. Sandy Agafonoff

    I would also like to see this. Specifically for running branch specific pipelines i.e. feature/*

    I would like to add to settings, the values I want to use for branch patterns, owing to the fact, we want to perform basic testing and nearest neighbour integration tests at the branch level, pre merge to say develop (where it can execute a different set of tests). Maybe this is the wrong idea, so I am open to discussion, however, I am not sure what the feature/* usage is going to be useful for. Pretty nice to have it all in the same place though and it's much easier to get going than with jenkins, so good job on pipelines anyway.

  5. Kostya Kostyushko

    The #13676 has no mentions about environment variables. I don't think limiting pipeline execution by roles will resolve issue with variables.

    The issue similar to this one is #12923 and it was already closed (rejected) despite it has 7 votes and this one 17.

    Apart of running pipeline restriction you should count 3rd party sites restrictions.

    In my case for example, I do deploy to AWS using pipeline of bitbucket, and I need to define AWS user (ex: AWS_ACCESS_KEY_ID, etc..) variables according to the branch.

    So, DEV user will not accidentally upload code to PROD and vice versa.

  6. Ben Codner

    There might be a yaml based solution to this. Here is what i've done using anchors:

    image: docker:latest
    
    .dev_env_vars: &dev_env_var_anchor |
      export STAGE=dev
      export AWS_REGION=us-west-2  
    
    .uat_env_vars: &uat_env_var_anchor |
      export STAGE=uat
      export AWS_REGION=us-east-1
    
    .deploy_template: &deploy_template_definition |
      echo "AWS_REGION:${AWS_REGION}"
      apk add --update make jq
      ./deploy.sh
    
    pipelines:
      branches:
        master:
          - step:
              name: build-image
              script:
                - |
                  apk add --update make
                  <login for building and publishing container image>
                  make build
                  make publish
          - step:
              deployment: test
              name: deploy-dev
              trigger: automatic
              image:
                name: <private_registry>
                username: 
                password: 
                email: ""
              script:
                - *dev_env_var_anchor
                - *deploy_template_definition
    clone:
      depth: 1
    
    options:
      docker: true
    
  7. Ben Codner

    @Dmitry Kirilyuk I agree, we recently moved from gitlab and i've been disappointed in the lack of features in bitbucket pipelines (runners, variables etc). I wanted a way to have variables i don't consider secret defined in the pipeline and since there was no DSL way to do this, I used yaml anchors.

  8. Philip Hodder staff

    Hi everyone,

    I'd like to clarify why Matt marked this as a duplicate of #13676.

    As part of deployment permissions, we'll be adding the ability to create environment variables scoped to a particular deployment environment. For example setting up AWS_ACCESS_KEY_ID that is only available when performing a production deployment.

    We'll be starting work on deployment permissions soon. So, we'll be posting updates on that ticket. This will also include when we have deployment scoped variables available.

    That appears to cover the use-cases that have come up in this ticket. If you have a use-case that isn't related to deployment variables, I suggest you open a new ticket with more details of your use-case.

    Thanks,
    Phil

  9. Philip Hodder staff

    @Noah Matovu, as you may have already seen on the other ticket, we have just shipped Deployment Variables. These will allow for you to define deployment specific variables that will only be available inside of the deployment step to that environment. e.g. Deployment keys. You can configure them in the Repository Settings -> Pipelines -> Deployments.

    Thanks,

    Phil

  10. Log in to comment