Lifecycle of a Variable vs Multiple Pipelines

Hi community,
I find the documentation of Gitlab CI a bit vague on the topic of env variable’s lifecycle.

Scenario:

Pipeline 1 runs: stage A -> stage B -> if you tag, stage C (say we’ve tagged with v 1.1.1)-> deploy to manual testing env -> stage, deploy to production

Requirement:
The “deploy-to-production” stage needs to be able to read the exact same tag as seen by stage C.

Manual testing can take long, and in that time period a second pipeline - pipeline 2 - runs, all the way to stage C, triggered by another tagging. Hence, now CI_COMMIT_TAG = 1.1.2.
At that stage we decide to execute the jobs in the deploy-to-production stage in pipeline 1. Reminder, it needs to see the tag it was triggered by - 1.1.1.

Questions:
Is that guaranteed by Gitlab CI or newer events globally overwrite such default variables, hence pipeline 1 would see the tag that triggered pipeline 2?

Would be nice if the answer to that question is more explicitly state on the official documentation.

Excuse me if it is my bad that I have not understood but I read a few times the env vars’ page and could not assemble a precise answer.

Kind regards,
Me :slight_smile:

I always prefer the “let’s just test it to see what happens” method of determining things that are not fully documented.

From my understanding, any job within the same singular pipeline will use the same “pre-defined environment variables” for every job/stage in that specific pipeline.

Each pipeline is tied to a specific commit and so all of the CI_xxx variables will remain constant through a single pipeline (even if another pipeline gets started).

You may run into issues where a pipeline is running on a commit, but then you rebase and force push to your repository which ends up deleting the commit that the 1st pipeline was running on. If a job hadn’t started yet, when it tries to clone/checkout to the specific commit, the job will fail because you deleted/overwrote that commit from the repository’s history.

As long as you aren’t tagging the same commit with a different tag (and running a new pipeline) you should not have an issue.