dotenv variables are not available in bridge jobs
Summary
As a user of GitLab CI, I can define a dotenv
artifact and jobs in subsequent stages can use the environment variables defined.
As a user of GitLab CI, I can create child pipelines using the Trigger Syntax and pass variables to the child pipeline.
I, however, cannot reference an environment variable created by the dotenv
artifact and pass the value of that variable downstream to a child pipeline.
the variables defined with
dotenv
are not available inbridge
jobs, so bridge jobs cannot use them invariables
keyword.
Steps to reproduce
- Create a CI YAML with
dotenv:
andtrigger:
syntax. - Watch the
dotenv:
variables not be sent downstream.
Example Project
What is the current bug behavior?
The environment variables appear to not be passed but either show up empty, or if you attempt to explicitly include them, the variable reference is passed without being evaluated.
(source)
What is the expected correct behavior?
The dotenv
-defined environment variables would be passed downstream and made available to the child job.
Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
(If you can, link to the line of code that might be responsible for the problem)