GitLab-CI: Use a job-variable in release section

Question

In my CI-Pipeline of Gitlab I try to set a tag-name for a release.

The tag-name should be set by a Job-Variable, but it will always use the "default" value. But it should use the "overwritten" variable value from by script section.

In the GitLab-CI.yml I set the default value of the var VERSION_TAG to v0.0.0, in the script section the value is overwritten with v1.2.3. In the echo command the right version-tag is printed correct. In the release section the variable is then again the default value v0.0.0, so the tag of the release will be wrong. The v1.2.3 will be set by a script and not hard-coded in future.

Here my GitLab-CI.yml, important is the job add_version_tag (I removed some rules, to improve the readability)

image: mcr.microsoft.com/dotnet/sdk:8.0

stages:
  - build
  - release

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "push"'

variables:
  DOTNET_CLI_TELEMETRY_OPTOUT: "true"
  DOTNET_NOLOGO: "true"

building:
  stage: build
  script:
    - echo "Start Pseudo Build Job ..."
    # - dotnet build

add_version_tag:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  variables:
    VERSION_TAG: "v0.0.0"
  script:
    - VERSION_TAG=v1.2.3
    - echo "Create tag $VERSION_TAG"
  release:
    tag_name: $VERSION_TAG
    tag_message: "Release $VERSION_TAG"
    name: "Release $VERSION_TAG of $CI_PROJECT_NAME"
    description: "Release $VERSION_TAG at $CI_PIPELINE_CREATED_AT based on $CI_COMMIT_SHORT_SHA"

The output from the logs of the ci-pipeline

...
$ echo "Create tag $VERSION_TAG"
Create tag v1.2.3
...
$ release-cli create --name "Release v0.0.0 of version-handling" --description "Release v0.0.0 at 2024-01-29T11:44:34Z based on xxxxxxxx" --tag-name "v0.0.0" --tag-message "Release v0.0.0"
...

How can I use a "job-variable" in a release job section?

Answer 1

Many thanks @mpolitze for the hint out of the ducumentation

Environment variables set in before_script or script are not available for expanding in the same job. Read more about potentially making variables available for expanding.

I was not aware of that before. By reading the workaround with the .env file, I came up with the solution below.

I was able to solve the "hand over of variables" by using a file VERSION_TAG_FILE, and still stay a inside a single job. Staying in one single job, without artifacts, was one of my goals.

I use echo to file and cat to read from the file

image: mcr.microsoft.com/dotnet/sdk:8.0

stages:
  - build
  - release

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "push"'

variables:
  DOTNET_CLI_TELEMETRY_OPTOUT: "true"
  DOTNET_NOLOGO: "true"

building:
  stage: build
  script:
    - echo "Start Pseudo Build Job ..."
    # - dotnet build

add_version_tag:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  variables:
    VERSION_TAG: "v0.0.0"
+   VERSION_TAG_FILE: "version.txt"
  script:
    - VERSION_TAG=v1.2.3
    - echo "Create tag $VERSION_TAG"
+   - echo $VERSION_TAG > $VERSION_TAG_FILE
  release:
+    tag_name: $(cat $VERSION_TAG_FILE)
+    tag_message: "Release $(cat $VERSION_TAG_FILE)"
+    name: "Release $(cat $VERSION_TAG_FILE) of $CI_PROJECT_NAME"
+    description: "Release $(cat $VERSION_TAG_FILE) at $CI_PIPELINE_CREATED_AT based on $CI_COMMIT_SHORT_SHA"

Answer 2

As per the documentation variables are not passed from script or before_script to release.

The solution documented below states to create a variables.env file as an artifact and pass that to the next job doin the release.