Can you configure CI variables in a merge request?

GitLab CI/CD
1

Curious if know if its possible to configure CI variables based on an active merge request.

At this time, I have a project which depends on other repositories for some builds. In a .gitlab-ci.yml script, I add some cloning operations in before_script calls to have them available before running a job. For example:

...

variables:
    MYDEP_REVISION:
        value: "main"
        description: "Revision for my dependency"

default:
    before_script:
        - git clone --branch ${MYDEP_REVISION} http://gitlab-ci-token:${CI_JOB_TOKEN}@...
...

With this setup, I can perform the most recent development builds based on my projects. In the situation where I would like to test a pipeline against a different branch/version of my dependency, I can go into the web user interface, select the pipeline and adjust MYDEP_REVISION to a desired revision.

An issue I have with this workflow is if I have a active branch on my main repository which is dependent on another active branch of my project dependency. If a merge request event is triggered (e.g. new commits), it will attempt to build of the main revision of my dependency and fail. I could then manually restart a new pipeline with a modified revision variable and the job would build as expected. I am wondering if there is a way to:

  • Configure CI variable overrides for a specific merge request (without editing the Git repository source)
  • If there is an easy way to see applied CI variables for a job (current “workaround” is to just print their contents at the start of a job)

I have tried seeing if there is a way to use merge request dependencies, but it didn’t look to me that there was a way to interpret merge request dependency information from the existing merge request CI variables (assuming there was a way to setup a hint to what dependency revision to use based off an assigned merge request dependency).

Thoughts? Or any other suggested approaches?

2

Hi @jdknight

I’m curious to see what other folks come up with for this.

In the past I’ve written environment variables into files, which are then checked into source in the MR. Then in the relevant script section of the CI job, I read it in via Bash:

job:
    ...
    script:
        - MY_VARIABLE="$(cat myvariable_file.txt)"
        - ... # Use MY_VARIABLE

That does have the advantage that every branch can have its own “variables”, which are recorded in the source and can be seen by all developers, but it is very messy!