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.