Allow a group runner to be shared between multiple groups
Problem to solve
I have multiple GitLab groups which are not subgroups of each other. I now can register a runner at the group level for one specific group. I now would like to be able to share this runner with another group.
Related research/use cases
Inconsistent permission models for runners vs. other GitLab features:
I think if Group runners would just respect the project sharing permissions in Gitlab it could simplify a lot of things for us by being able to just register the same runner with both groups.
Runner types don't allow for enough flexibility today:
We need this feature to be able to share our MacOS infrastructure between projects. We provide shared instance level linux runners that are needed for most jobs in the organisation but for IOS builds we need custim runners. We can't share them as instance level runners because any tag misconfiguration on the user part will result in failed job due to assignment of this job. We also can't group all the mobile teams inside one Gitlab Group with group specific runners.
a GitLab.com customer just started a trial on GitLab.com on a new namespace to test out SAST and Dependency Scanning. They currently host their runners in their Kubernetes cluster (2 for build, 1 for deploy). They are unsure how to point the trial namespace to those exact runners (in a shared capacity since they can’t take down/affect their production namespace).
Management burden of creating the same runner which increases infrastructure costs:
Not having this control mechanism built in to GitLab has forced customizations to be built out to manage access to runners. Ideally they would like to see a solution where administrators control the access controls for the runners and not allow group owners to over-ride settings on these shared resources.
We have a group that does occasional development and it would be helpful if its members could just use the same runners that our group is using - to avoid admin burden and also infrastructure costs.
As described above, different groups have needs to access the same runners, and the re-registering of the runners takes additional administrative time.
I have the problem to run multiple runners on a single machine with the virtualbox runner. Unfortunately the virtualbox runner neither supports to pull the used image from a registry not to specify the image used in the gitlab-ci.yml file, like it is possible with the docker runner. Therefore I have to register multiple runners on the same machine. E.g. the following runners are currently registered: visual_studio_2008, visual_studio_2013, visual_studio_2015, visual_studio_2017. In addition I have 5 build machines. Now I already have 20 runners. Everything was working happily until a new group was created in GitLab due to different permissions. Now the same build machines should be reused. Best would be to just share the runners between the groups. But under the current system I have to register every runner again. Now I have already 40 runners to administer...
Customer has created top level groups that are federated and would like to share runners across them. Customer has to spin up, manage, and pay for more compute/runners than they need...We could accomplish this by creating instance level runners where we add all the projects of a respective team's groups to that runner. However to do this, we'd have to keep those projects for the various groups in sync with that instance runner's list of permitted projects. Automating that would be straightforward but then we (the team that owns our internal Gitlab instance) would still ultimately be the owner of those runners and have to manage permissions rather than the groups that actually want to create and manage them.
Proposal
If a group runner is not locked to a specific group, it should be possible to activate it in another group.