## Summary I want to summarize the problem of passing variables to downstream pipelines in this epic. There are now 4 issues related to this problem. For this problem, we may have a few bugs, missing documentation, and wrong usages. ## Variable Passing Options ### `variables` in `trigger` job This usage is documented here: https://docs.gitlab.com/13.4/ee/ci/multi_project_pipelines.html#passing-variables-to-a-downstream-pipeline (~documentation => we may need this info also in [the parent-child docs](https://docs.gitlab.com/13.4/ee/ci/parent_child_pipelines.html)) It has some problems though. Here is an example: - `.gitlab-ci.yml` => https://gitlab.com/furkanayhan/test-project/-/blob/255b1aed61383c897f296c23bd122f3f052c88a8/.gitlab-ci.yml - initializes a var `TEST1` with the value `initial-var` - triggers 3 child pipelines with passing variables via bridge jobs `variables` keyword. - `.child-pipeline.yml` => https://gitlab.com/furkanayhan/test-project/-/blob/255b1aed61383c897f296c23bd122f3f052c88a8/.child-pipeline.yml - prints some variables --- - Child job 1: https://gitlab.com/furkanayhan/test-project/-/jobs/771100092 - something wrong here, when we use the same name of an existing variable, it just does not work - Child job 2: https://gitlab.com/furkanayhan/test-project/-/jobs/771100091 - similar to above, but much more complicated - Child job 3: https://gitlab.com/furkanayhan/test-project/-/jobs/771100090 - everything looks good when we use different var names. - but strangely, it also was able to read the `$TEST1` even we did not pass it. Is this normal? - Update: Yes it is normal, according to [the doc](https://docs.gitlab.com/13.4/ee/ci/multi_project_pipelines.html#passing-variables-to-a-downstream-pipeline). - > This is because trigger-downstream job inherits variables declared in global variables blocks, and then we pass these variables to a downstream pipeline. Another problem in this usage is to use [predefined variables](https://docs.gitlab.com/13.4/ee/ci/variables/predefined_variables.html). As you can see the examples above, `$PARENT_JOB_ID` could not be read, but `$PARENT_JOB_NAME` could be read. Why? That's because we [assign some variables only for builds](https://gitlab.com/gitlab-org/gitlab/-/blob/6b19d50572778f0ea19905ded6061ae133259cea/app/models/ci/build.rb#L522-582). - `CI_JOB_ID` is [assigned](https://gitlab.com/gitlab-org/gitlab/-/blob/6b19d50572778f0ea19905ded6061ae133259cea/app/models/ci/build.rb#L541) in `Ci::Build` class. - `CI_JOB_NAME` is [assigned](https://gitlab.com/gitlab-org/gitlab/-/blob/6b19d50572778f0ea19905ded6061ae133259cea/app/models/concerns/ci/contextable.rb#L67) in `Ci::Contextable` module, which is used for both `Ci::Build` and `Ci::Bridge`. ### `dotenv` files This usage is documented here: https://docs.gitlab.com/13.4/ee/ci/yaml/README.html#artifact-downloads-between-pipelines-in-the-same-project (~documentation we may need to document `dotenv` usage explicitly) It works as expected. Here is an example: - `.gitlab-ci.yml` => https://gitlab.com/furkanayhan/test-project/-/blob/6fc9edaf7df8265b10568c043ba103dcff443df7/.gitlab-ci.yml - initializes a var `TEST1` with the value `initial-var` - creates vars with `dotenv` - triggers a child pipeline - `.child-pipeline.yml` => https://gitlab.com/furkanayhan/test-project/-/blob/6fc9edaf7df8265b10568c043ba103dcff443df7/.child-pipeline.yml - needs parent artifacts and prints some variables Job: https://gitlab.com/furkanayhan/test-project/-/jobs/771117122 ## Conclusion: As it seems, for the `variables:` option, we have some problems. For the `dotenv` option, we just need some ~documentation. Edit: we have one problem with the `dotenv` syntax; the variables defined with `dotenv` are not available in `bridge` jobs, so bridge jobs cannot use them in `variables` keyword. Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/233289