GitLab Next

Release notes

Pipeline variables (such as variables defined in the UI or API) based on https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence hold the highest priority, however, this is not the case when using a downstream pipeline (such as parent-child or multi-project pipeline), in this release we've added the ability to for a downstream pipeline to inherit pipeline variables from upstream.

Problem to solve

In a parent pipeline, with child pipelines in the same project (not multi-project pipeline), variable values defined for this pipeline in the manual trigger UI should be transmitted to children as-well.

However, this is not the case today, as can be seen with the following reproducer:

.gitlab-ci.yml

#UI_DEFINED_VARIABLE is to be define in pipeline UI (local to one pipeline manually triggered)

parent:
  script:
    - echo "UI_DEFINED_VARIABLE is ${UI_DEFINED_VARIABLE}"

trigger-child:
  trigger:
    include: child-ci.yml
    strategy: depend

child-ci.yml

child:
  script:
    - echo "UI_DEFINED_VARIABLE is ${UI_DEFINED_VARIABLE}"

I think this makes sense because the intent of parent/child pipeline (per documentation) is to enhance readability of one large pipeline, not to divide them in small independent ones.

Intended users

Anyone using manual trigger to test their pipeline with specific configuration.

As an example, when creating a rule for a specific branch, I always create a corresponding test rule with a variable so that I can emulate the behavior on a different branch (e.g. for debugging purpose).

Note

This probably apply to API triggered pipelines.

@thaoyeager I think this should be placed in the parent/child epic

Workaround

https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#passing-variables-to-a-downstream-pipeline

trigger-child:
  trigger:
    include: child-ci.yml
  variables:
    UI_DEFINED_VARIABLE: $UI_DEFINED_VARIABLE

in case you would like to transmit a non-existent variables to be evaluated literally in the child if they don't exist on the parent.

The workaround above will not work if the variable to be propagated is not defined in the parent (e.g. only provided when triggering the pipeline manually).

In that case the parent should specify the variable top-level:

Parent .gitlab-ci.yml:

image: alpine

variables:
  VAR_TO_PROPAGATE: ""
child:
  trigger:
    include: child.yml
  variables:
    VAR_IN_CHILD: $VAR_TO_PROPAGATE

Child child.yml:

if-var:
  script: echo $VAR_IN_CHILD
  rules:
    - if: $VAR_IN_CHILD != ""

if-not-var:
  script: echo
  rules:
    - if: $VAR_IN_CHILD == ""

This runs the job if-not-var by default and when I define VAR_TO_PROPAGATE when running the pipeline manually, it runs the job if-var

Proposal

Add a forward keyword nested under trigger with 2 nested value

• yaml_variables: true - will represent the current/default behavior
• pipeline_variables: true - with this, pipeline UI variables are passed

variables:
  BAR: bar

trigger-downstream:
  variables:
    FOO: foo
  trigger:
    include: child.yml
    forward: # I nested this keyword under trigger
      yaml_variables: true # this is the current/default behavior
      pipeline_variables: true # with this, pipeline UI variables are passed

trigger-downstream:
  trigger:
    project: namespace/project-2
    forward: # I nested this keyword under trigger
      yaml_variables: true # this is the current/default behavior
      pipeline_variables: true # with this, pipeline UI variables are passed

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.