diff options
Diffstat (limited to 'doc/ci/multi_project_pipelines.md')
| -rw-r--r-- | doc/ci/multi_project_pipelines.md | 53 |
1 files changed, 51 insertions, 2 deletions
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md index 3f9a00b6cc8..378adcd35e9 100644 --- a/doc/ci/multi_project_pipelines.md +++ b/doc/ci/multi_project_pipelines.md @@ -163,6 +163,8 @@ have permission to run CI/CD pipelines against the protected branch, the pipelin ### Passing variables to a downstream pipeline +#### With the `variables` keyword + Sometimes you might want to pass variables to a downstream pipeline. You can do that using the `variables` keyword, just like you would when defining a regular job. @@ -211,10 +213,49 @@ In this scenario, the `UPSTREAM_BRANCH` variable with a value related to the upstream pipeline will be passed to the `downstream-job` job, and will be available within the context of all downstream builds. -NOTE: **Tip:** Upstream pipelines take precedence over downstream ones. If there are two variables with the same name defined in both upstream and downstream projects, -the ones defined in the upstream project will take precedence. +the ones defined in the upstream project take precedence. + +#### With variable inheritance + +You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#inherit-environment-variables) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs). + +In the upstream pipeline: + +1. Save the variables in a `.env` file. +1. Save the `.env` file as a `dotenv` report. +1. Trigger the downstream pipeline. + +```yaml +build_vars: + stage: build + script: + - echo "BUILD_VERSION=hello" >> build.env + artifacts: + reports: + dotenv: build.env + +deploy: + stage: deploy + trigger: my/downstream_project +``` + +Set the `test` job in the downstream pipeline to inherit the variables from the `build_vars` +job in the upstream project with `needs:`. The `test` job inherits the variables in the +`dotenv` report and it can access `BUILD_VERSION` in the script: + +```yaml +test: + stage: test + script: + - echo $BUILD_VERSION + needs: + - project: my/upstream_project + job: build_vars + ref: master + artifacts: true +``` ### Mirroring status from triggered pipeline @@ -280,3 +321,11 @@ Any pipelines that complete successfully for new tags in the subscribed project will now trigger a pipeline on the current project's default branch. The maximum number of upstream pipeline subscriptions is 2 by default, for both the upstream and downstream projects. This [application limit](../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) can be changed on self-managed instances by a GitLab administrator. + +## Downstream private projects confidentiality concern + +If you trigger a pipeline in a downstream private project, the name of the project +and the status of the pipeline is visible in the upstream project's pipelines page. + +If you have a public project that can trigger downstream pipelines in a private +project, make sure to check that there are no confidentiality problems. |