Re-enable shared runners for sub-groups and projects
Problem to solve
Once turned off, the enable-shared runners for this group option disables the use of shared runners for all sub-groups or projects under the parent group. To re-enable shared runners for any sub-group or project, a user with the Owner or Maintainer role must explicitly change this setting for each sub-group or project.
For the MVC of this feature, there was no mechanism to recursively re-enable shared runners on sub-groups or projects after shared runners had been disabled. At that time, we found a significant negative performance impact of a recursive tree walk to re-enable Shared runners on GitLab environments with many layers of sub-groups.
As the adoption of this feature has grown, the lack of this revert
type capability has become more problematic for large organizations. For example, if the parent group has 100 sub-groups, re-enabling the shared runners' settings at the top-level group is not applied to the sub-groups. The user must manually enable the shared runners for each sub-group.
Steps to test
- Create a group on Gitlab.com
- Create multiple sub-groups under the parent group
- Go to the parent group's
Settings > CI/CD
and expand the Runners section. In the Shared runners area, toggle off theEnable shared runners for this group
button (this disables all the shared runners recursively for the entire group) - Re-enable the
shared runners at the parent group level
- this setting is applied only to the parent group and it's not recursively applied to the sub-groups/projects.
Example Project
Proposal (revised 2022-07-05)
Implement a mechanism to turn on the use of shared runners for all nested sub-groups and projects after a user with the Owner or Maintainer role toggles the Enable shared runners for this group
toggle switch back to the on position.
Implementation notes
- If we look at the nested groups (assuming it won’t be many) and retrieve settings, we could cache the setting with a relatively short expiry interval.