Decouple the variables available to the upstream job from the ones being passed to downstream pipeline

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem to solve

Currently, making global variables available in a trigger job and controlling whether these variables gets passed to downstream pipelines are both controlled by the same setting - inherit:variables. However, this poses a problem when global variables (either set via global variables keyword, or set via workflow:rules:variables method) are necessary for other parts of the job - like rules (to decide whether to even include the job in a pipeline or not) or needs. Right now, there is no way for a variable to be available for a trigger job's rules and needs sections but not to be passed to downstream pipeline.

For example, in omnibus-gitlab!6228 (merged), Distribution team is trying an approach where the pipeline type is detected using workflow:rules method and a variable PIPELINE_TYPE is set. We then assign jobs to certain pipeline types using their rules. However, this breaks down when we approach trigger jobs. We want the variable PIPELINE_TYPE to available in the rules section of the trigger job, but we don't want the variable to be passed to downstream pipeline.

Proposal

There are two ways to support it

1. Even if inherit:variables is false, make the global variables available for other sections of the job - like rules or needs. Just don't pass them to downstream job.

2. Provide a way to specify the variables to be passed to downstream job, which is not coupled to the variables present on upstream job. Ideally, instead of passing all the variables available to the upstream job and then controlling them with yet another setting of inherit:variables, the trigger keyword should have a variables section of its own to specify the variables to be passed to downstream pipeline. So, something like the following

   1. Make every global variable available to upstream job, but do not pass any variables from upstream job to downstream pipeline

      variables:
         A_RANDOM_VAR: "random_value"
      job1:
        variables:
          FOO: 'BAR'
        trigger:
          project: 'sample/repo'
          branch: 'main'
          strategy: depend
          variables: false     # Both global variables and job variables are available for the upstream job, but neither are passed to downstream job.

   2. Make every global variable available to upstream job, but pass only select variables to downstream pipeline

      variables:
         A_RANDOM_VAR: "random_value"
      job1:
        variables:
          FOO: 'BAR'
        trigger:
          project: 'sample/repo'
          branch: 'main'
          strategy: depend
          variables:
            FOO: ${FOO}            # FOO is defined as a job variable, and hence is available to be passed to downstream pipeline.
            VAR: ${A_RANDOM_VAR}   # Global variables are available for the upstream job, and hence is available to be passed to downstream pipeline.
            ANOTHER_VAR: "value"

   3. Make no global variable available to upstream job, and pass only select variables to downstream pipeline

      variables:
         A_RANDOM_VAR: "random_value"
      job1:
        inherit:
          variables: false    # Global variables are not available either on the upstream job, or to be passed to downstream pipeline.
        variables:
          FOO: 'BAR'
        trigger:
          project: 'sample/repo'
          branch: 'main'
          strategy: depend
          variables:
            FOO: ${FOO}    # FOO is defined as a job variable, and hence is available to be passed to downstream pipeline.
            ANOTHER_VAR: "value"

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.