Search code examples
gitlabgitlab-cigitlab-ci-runnercicd

How to pass values to gitlab pipeline variable sourced from a file


For example the file that I have is test.env

test.env has the content

export SAMPLE="true"

I want the variable SAMPLE to be set as a pipeline variable before running the pipeline

I am trying the below mentioned solution but it is not really helping

before_script:
  - git clone test.env
  - source test.env

stages:
  - publish

test:
  stage: publish
  trigger:
    project: test_pipeline
    branch: master
    strategy: depend
  only:
   variables:      
      - $SAMPLE == 'True'

Is there any way to source the variables in the before hand and then set the pipeline variables so that execution can happen based on those pipeline variables


Solution

  • Currently with Gitlab CI there's no way to provide a file to use as environment variables, at least not in the way you stated. There are a couple of other options however.

    First is take all the individual variables you would have in your test.env file and store them as separate Secret Variables. You can set these by going to your project's settings, -> CI/CD, -> Variables. Environment Variables defined here will automatically be available in every pipeline job for this project (although you can select the Protect Variable checkbox, which will only make the variable available for pipelines on Protected Branches).

    The next option is to copy the entire test.env file contents, go back to your project’s Secret Variables (as described above), but this time change the Variable Type to "File", and paste the file contents as the value. When you use a "File" type variable, Gitlab will create a temporary file in each of your pipeline jobs (again, unless you check the Protect Variable option). Then the path to that file will be stored as the env variable with the key you selected. This would allow you to do things like cat $my_file_variable, which would evaluate as cat /path/to/temporary/file, then cat the contents.

    A final option which is closest to your original request, is to add a job before all your other jobs that would require the test.env file that looks like this:

    stage: env_setup # or whatever
      script:
        - : # this is the bash Null Command that does nothing and always succeeds
      artifacts:
        reports:
          dotenv: test.env
    

    For this job, the only purpose is to turn your test.env file into environment variables. We don't need to do anything else with it, so we use the Null Command for the script section (since a job without at least the script section will fail). The artifacts part is the important stuff here. Gitlab supports a special Report type called dotenv that takes a single argument: a path to a file. The file will get uploaded as an artifact like any other, but for subsequent jobs (or those that use the dependencies keyword with this job name) instead of pulling down the artifact as a file, each item in test.env will be turned into an environment variable, so you can use it like $SAMPLE, etc.

    Personally I prefer the first two options over the third, and of the first 2, the 2nd is the easiest as you just have to copy and paste the file you have now into a variable. The reason the third option isn't ideal is that it still allows you to have sensitive variables (like passwords) in your git repository, which isn't ideal from a security standpoint. Either of the first two options eliminate that problem.