'Exporting environment variables from one stage to the next in GitLab CI

Is there a way to export environment variables from one stage to the next in GitLab CI? I'm looking for something similar to the job artifacts feature, only for environment variables instead of files.

Let's say I'm configuring the build in a configure stage and want to store the results as (secret, protected) environment variables for the next stages to use. I could safe the configuration in files and store them as job artifacts but I'm concerned about secrets being made available in files than can be downloaded by everyone.



Solution 1:[1]

Since Gitlab 13 you can inherit environment variables like this:

build:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  script:
    - echo $BUILD_VERSION # => hello
  dependencies:
    - build

Note: for GitLab < 13.1 you should enable this first in Gitlab Rails console:

Feature.enable(:ci_dependency_variables)

Solution 2:[2]

No this feature is not here yet, but there is already an issue for this topic.

My suggestion would be that you are saving the variables in a files and cache them, as these will be not downloadable and will be removed on finish of the job. If you want to be 100% sure you can delete it manually. See the clean_up stage.

e.g.

cache:
 paths:
  - save_file

stages: 
 - job_name_1
 - job_name_2
 - clean_up

job_name_1:
 script:
  - (your_task) >> save_file

job_name_2:
 script:
  - cat save_file | do_something_with_content

clean_up:
 script:
  - rm save_file
 when: always 

Solution 3:[3]

Although not exactly what you wanted since it uses artifacts:reports:dotenv artifacts, GitLab recommends doing the below in their guide: 'Pass an environment variable to another job':

build:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is: 'hello'
  needs:
    - job: build
      artifacts: true

I believe using the needs keyword is preferable over the dependencies keyword (as used in hd-deman`'s top answer) since:

When a job uses needs, it no longer downloads all artifacts from previous stages by default, because jobs with needs can start before earlier stages complete. With needs you can only download artifacts from the jobs listed in the needs: configuration.

Furthermore, you could minimise the risk by setting the build's artifacts:expire_in time to be very small.

Solution 4:[4]

You want to use Artefacts for this.

stages: 
 - job_name_1
 - job_name_2
 - clean_up

job_name_1:
 script:
  - (your_task) >> save_file
 artifacts:
  paths:
   - save_file
# Hint: You can set an expiration for them too.

job_name_2:
 needs:
  - job: job_name_1
    artifacts: true
 script:
  - cat save_file | do_something_with_content

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Cometchaser
Solution 3 followingell
Solution 4 WhyNotHugo