Use variables per branch in gitlab

GitLab CI/CD
,
1

I have set up my GitLab pipeline and I’m using GitLab CI variables to generate my configuration file during the build phase. Now we’ve set up a couple new environments, with each having its own database and other credentials, so I need to generate my configuration file using each environment’s variables based on branch. I’ve already seen:

Some users suggested sourcing environment variables from files but that isn’t really a solution because we want to limit access to these variables. Is there a solution or workaround to this problem in .gitlab-ci.yaml ?

1 Like
2

Hi, I think I have exactly the same issue here. In my case, our developers are using PHP (Laravel) in Kubernetes and the application uses a dotenv file for its configuration to find the mysql database, usernames, passwords etc. You can imagine that the entries in this .env file have different values in different environments (test / prod).

At the moment I have a workarround: Every variable in Gitlab is created twice. Same name, different value and Different environment scope (test/prod).

In the gitlab-ci.yml I use the dirty / low level “sed” command to search/replace placeholder words in a file for the real value (The value of the variable with the environment scope the pipeline job is running in.).

It works and on the test and prod cluster, the entries in the generated doting file have different values!
Of course I have mixed feelings about this solution/workarround. I think it would be better if we are able to use a templating engine in gitlab-ci.yml: Refer to a templatefile, add variables to the file and the result should be an artefact or a file with a specific name which can be used with the right content/values in the right environment/cluster/server.

Tools like Ansible use Jinja2 as a templating mechanism. This or an alternative should not be so hard to implement and can be very useful!

A few months ago, I also filed an issue about this:

Unfortunately there is no response yet.

3

@geurt.hakfoort I ended up doing the following

before_script:

  • source variables/.${CI_COMMIT_REF_NAME}.env

And under variables directory I created an env file like .prod.env

export USERS_USERNAME="$PRODUCTION_USERS_DB_USERNAME"
export USERS_PASSWORD="$PRODUCTION_USERS_DB_PASSWORD"

And in .dev.env

export USERS_USERNAME="$DEV_USERS_DB_USERNAME"
export USERS_PASSWORD="$DEV_USERS_DB_PASSWORD"

And using $USERS_USERNAME and $USERS_PASSWORD in .gitlab-ci.yaml

And finally ditched up everything and used the variables during runtime. But it’s still useful for build time variables that you use to talk to a third party during Docker image build.

1 Like
4

Hi @alterEgo123

did you look into enviroinment scoped variables in the end?

5

Hi,

I had the same issue here, I did the following and worked fine:

  parallel:
    matrix:
      - LOCATION: dev
        BRANCH: develop
      - LOCATION: prod
        BRANCH: main
  rules:
    - if: $CI_COMMIT_REF_NAME == $BRANCH

In this case I used the variables hardcoded in the matrix, but it’s possible to use CI variables as well.

6

Quite an old topic but with the same problem I found a solution. It can help if someone does a google search.
Create your CI variables with scope environment (Example dev and prod)
In your gitlab-ci.yml:

variables:
  GITLAB_ENV: dev

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == "main"
      variables:
        GITLAB_ENV: prod
    - when: always

my-deploy-job:
  environment: $GITLAB_ENV
  stage: deploy