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

  1. Create a group on Gitlab.com
  2. Create multiple sub-groups under the parent group
  3. Go to the parent group's Settings > CI/CD and expand the Runners section. In the Shared runners area, toggle off the Enable shared runners for this group button (this disables all the shared runners recursively for the entire group)
  4. 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

  • https://gitlab.com/runner_ui

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.

Screen_Shot_2022-07-05_at_3.19.16_PM

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.
Edited Jul 13, 2022 by Darren Eastman
Assignee Loading
Time tracking Loading