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

1. The label on the Group page view is now Set up shared runner availability
2. There are two toggle switches that will be visible below the label, Enable shared runners for this group and Allow projects/sub-groups to override the group setting
3. 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.
4. Once a user sets the Enable shared runners for this group to the off position, then the Allow projects/sub-groups to override the group setting switch will be visible in the UI.
5. Changing the toggle switch Enable Shared Runners for this group to the off position results in the shared_runners_enabled state to be false. This means that all all sub-groups and projects will not be able to use Shared Runners.
6. 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.

Links / references