Skip to content

Deprecation: Change in protected variables behavior/expansion in multi-project pipelines

Deprecation Summary

Currently users are able to expand and pass down protected variables in multi-project pipelines. This is a security concern as it can lead to the leak of protected variables intended only to be used in pipelines within the group. This change ensures protected variables are only passed to downstream pipelines per out documentation for pipelines that run on protected branches or protected tags, specifically:

  1. The downstream pipeline belongs to the same project.
  2. The downstream pipeline belongs to the project in the same group.

Pipelines triggering jobs from outside the protected variable's group will no longer have access to the protect variable(s). Users will need to adjust their workflows accordingly.

Breaking Change

With this change, users are no longer able to expand and pass down protected variables in multi-project pipelines.

Affected Topology

Both Self-managed and GitLab.com users are affected.

Affected Tier

  • All

Checklists

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

Timeline

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 14.8, 14.9, 14.10, 15.0 – 14.8 is the third milestone preceding the major release):
  • On or before the major milestone: A removal entry has been created so the removal will appear on the removals by milestones page and be announced in the release post.
  • On the major milestone:

Mentions

  • Your stage's stable counterparts have been @mentioned on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
    • To see who the stable counterparts are for a product team visit product categories
      • If there is no stable counterpart listed for Sales/CS please mention @timtams
      • If there is no stable counterpart listed for Support please mention @gitlab-com/support/managers
      • If there is no stable counterpart listed for Marketing please mention @cfoster3
  • Your GPM has been @mentioned so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.

Deprecation Milestone

16.9

Planned Removal Milestone

19.0

Links

Edited by Marcel Amirault