### 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** 1. 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` 1. 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. 1. 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. 1. 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. 1. 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