Allow user to enable/disable instance level Shared Runners on the group level
Problem to solve
When GitLab is hosted as a PaaS, such as on GitLab.com, some groups may not want code to run on Shared Runners - these are runners that are available to all groups and projects in a GitLab instance. Organizations that need to disable the use of Shared Runners have to do so for each project in a GitLab instance. Also, an administrator may forget to disable Shared Runners for a project.
Some customers cannot use Shared Runners on GitLab SaaS due to security and compliance policies. "If we forget to disable them, we violate internal security regulations.".
Proposal
Create a group setting where you can disable shared runners by default.
Implementation details
- The label on the Group page view is now Set up shared runner availability
- There are two toggle switches that will be visible below the label,
Enable shared runners for this group
andAllow projects/sub-groups to override the group setting
- The
Enable shared runners for this group
toggle switch will always be visible. The default value is for the switch to be in the on position. - Once a user sets the
Enable shared runners for this group
to the off position, then theAllow projects/sub-groups to override the group setting
switch will be visible in the UI. - Changing the toggle switch
Enable Shared Runners for this group
to the off position results in theshared_runners_enabled
state to be false. This means that all all sub-groups and projects will not be able to use Shared Runners. - If the user sets the
Allow projects/sub-groups to override the group setting
toggle switch to on, then this enables a project owner or maintainer to enable Shared Runners for a project.
Not Doing
Even better, create another group setting that disallows enabling shared runners.