Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,137
    • Issues 43,137
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,356
    • Merge requests 1,356
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab 15.0 has launched! Please visit Breaking changes in 15.0 and 15.0 Removals to see which breaking changes may impact your workflow.

  • GitLab.org
  • GitLabGitLab
  • Issues
  • #2874
Closed
Open
Created Jul 07, 2017 by Shinya Maeda@shinya.maeda💡Maintainer

Environment-specific variables at the group level

Release post candidate

Many organisations prefer to specify secrets and other environment variables at the group level, as it aligns well with team boundaries or trust levels. Until now, the group level environment variables affected all the environments, and this limited their usability in a lot of use cases. Today, we are releasing environment-specific variables at the group level.

This change complements the similar functionality from the project level. From now on, group maintainers can specify the environments where a given variable is to be applied.

https://docs.gitlab.com/ee/ci/variables/README.html#group-cicd-variables

Description

We implemented https://gitlab.com/gitlab-org/gitlab-ee/issues/2302 for Project-level variables, we should support Group-level variables as well

Proposal

Implement Environment-specific variables for Group-level variables. Because environments only exist at the project level, matching will need to be something creative.

Downgrade handling

  • Environment filtering logic should exist in FOSS.
  • Assigning a custom environment scope to a group-level variable should exist in EE.
  • At downgrade, we don't change any group-level environment variables including scopes. No effect on the existing CI/CD pipelines.
  • After downgrade, users can add a group-level variable with wildcard scope only.
  • After downgrade, users can change a group-level variable's scope to a wildcard scope.
  • After downgrade, users can't change a group-level variable's scope to a custom scope.
  • After downgrade, users can delete a group-level variable's scope with any scopes.
  • In FOSS, show * as the environment scope as disabled to provide a "hint" that upgrading will provide this feature.

Links / references

  • https://gitlab.com/gitlab-org/gitlab-ee/issues/2302
  • https://gitlab.com/gitlab-org/gitlab-ce/issues/12729

/cc @ayufan @godfat

Edited Apr 08, 2021 by Viktor Nagy (GitLab)
Assignee
Assign to
Time tracking