Shared CI runners for groups

Currently, it's only possible to add CI runners that are project specific or shared globally. However, there also should be an option of adding CI runners that are shared for a group.

In other words, if I'm launching my custom runner that I want to be available for all projects in the group, I need a place to do this centrally, instead of enabling this runner manually for every project.

Design

https://gitlab.com/gitlab-org/gitlab-ce/issues/10244#note_24934429

Added ~19173 label

@kop Thanks for suggestion, we will consider it. /cc @ayufan

Added feature proposal label

Not sure if anyone has a similar use-case, but I think it would be useful if the group runners could be limited to group-only projects and not their user-created forks.

I think that it could be useful. However we don't have plans for now to implement this. If you need it badly I guess it's up to you :)

mentioned in issue #14079 (closed)

If this is to come to be, groups should also have secret variables that are accessible for to any build from a project within the group.

Maybe that should be it's own feature request?

Absolutely need this!

this is very important

+1, definitely need this

I really need this. We have a runner with an SSH key added to it and quite a lot of projects, but we don't want "outside" users to have the runner, hence its locked for specific projects. It is really annoying to add the runner to each project manually.

Mentioned in issue #12729 (closed)

+1 This is currently a huge limitation for us, and is leading us to consider other git solutions.

+1

We need this! It would make GitLab CI much more usable

mentioned in issue #23020 (closed)

added ~423634 label

mentioned in issue #21828 (closed)

mentioned in issue #25525 (moved)

+1

This would really help us out as well. We have groups with a lot of projects which we all would like to run on a limited set of runners.

added ~113220 label

customer requested this via ZD: https://gitlab.zendesk.com/agent/tickets/63625

added ~1071782 label

I definitely want this! Preferably with an option to disable shared runners for a specific group, so that it doesn't have to be done per-project.

mentioned in issue #18261 (closed)

/cc @joshlambert

changed milestone to %Backlog

this is really important :)

+1

Yesterday on the DO meetup in Berlin I had this request twice. Would be nice if we could implement this soon.

assigned to @dimitrieh

added ~19492 label

mentioned in merge request !9646

@dimitrieh I started working on this, see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646.

added ~897282 label

@koffeinfrei @ayufan

I've been thinking about the backend implementation of this MR. And I would actually suggest the following:

Lets split the way we have runners right now, plus this feature in 3 classes, using the same db table

1. Instance Runners (previously shared)
2. Namespace Runners (maybe called group runners?)
3. Project Runners (previously shared) Runners would still have associated projects as they can thus be enabled for more projects. I hope/believe that we would keep cleaner separations between types of runners. Also allowing interfaces like runner.next_build I hope (this one I'm not sure about, yet). Also, I believe that if we don't got the route we did with supporting multiple objects we can save a few joins each time the runner asks for other job to run. On gitlab.com scale this is very important to optimise for.

Please let me know what you think!

@zj mmh i think group and instance runners can both be considered "shared runners" from a project UI perspective. I do agree with naming them instance and group runners though, but UI wise they should end up in the same category. Although we'd want a way to deactivate based on either category.

It seems almost easier to me, that we should switch to the new layout for runners based on https://gitlab.com/gitlab-org/gitlab-ce/issues/24141. However to keep these things separate let's go with the simplest solution.

---

@zj @koffeinfrei Shared group runners setting page will have a similar page as to the shared instance runners setting page. It will not show shared instance runners, though.

Also as an additional note to this, as we support nested groups. We will not show upper level group runners in a sub group view. All available runners will only be visible in the project runners settings view.

The project runners settings page will include button to disable based on instance/group based shared runners.. this will be done with a dropdown.

This results in:

• Instance shared runners page:
  • changed the runner tag & added title
• Group navigation will get a runners setting page:
• Group shared runners page:
  • same as instance shared runners page
• Project runners page:
  • Adjusted shared runners text and added table to disable shared runners from group and/or subgroups

Prob there will be things missing still, but i think its a good start without any pre-optimalisation

Please relabel UX and assign back to me if there needs be done additional UX work @zj

removed ~19492 label

assigned to @koffeinfrei

@zj

Lets split the way we have runners right now, plus this feature in 3 classes, using the same db table

That's conceptually essentially the same solution as what I did, only that you suggest using STI instead of an enum field. Or did I miss the gist of your solution?

This works for me as well. One downside of this solution is that it requires a data migration of the existing runners. And STI is a bit a polarizing construct, although it may be an accepted solution in Gitlab (in which case it's totally fine with me).

I hope/believe that we would keep cleaner separations between types of runners. Also allowing interfaces like runner.next_build I hope (this one I'm not sure about, yet).

I agree about the cleaner separation from an OO perspective, although for runner.next_build I'm not sure if the query will get any simpler. We still need to load up the associated groups and projects in some way. As far as I understand, choosing the next available runner is not specific to the runner type, but requires querying across all the runners.

Also, I believe that if we don't got the route we did with supporting multiple objects we can save a few joins each time the runner asks for other job to run. On gitlab.com scale this is very important to optimise for.

Is that actually the case? I lack the experience with something the scale of gitlab.com, but I'm surprised that joins should be a problem for a relational database or at least something to optimize away from. Apart from that, as I mentioned above, I'm not sure if we can actually fundamentally reduce the number of joins with your solution anyway.

In summary:

Overall I agree with your solution from an OO standpoint. Concerning data migration and required changes to the existing system your solution is more disruptive.

I was proposing STI indeed,

One downside of this solution is that it requires a data migration of the existing runners.

True, but I've heard talks/whispers about more specific runners, so we are probably going to do this anyway. I understand that its polorising, but using the enum here seems off, plus, within GitLab its OK to use STI when needed.

although for runner.next_build I'm not sure if the query will get any simpler.

In my head this was a beautiful query, but you might be right. I also hoped there would be a great solution on how not to add a new associations groups on the runners, but it seems unavoidable. Only advantage I see is that this might allow anyone to register a personal runner, tied to the User namespace. Thanks for being so thorough in you answer btw. :)

On queries, joins perse are not at all the problem, but the current situation is that about 5k runners are polling for work, IIRC each 3 seconds. So reducing the runtime of a query would be greatly appreciated by the ops team. If its not possible, thats too bad. If we can, we certainly should.

Once again, thanks for your thoughtful reply. Sorry I underestimated you a bit

Sorry I underestimated you a bit

Let's not jump to conclusions here...

@zj One more thing concerning your solution: This adds breaking changes which affect the API. How should this be handled?

@zj One more thing concerning your solution: This adds breaking changes which affect the API. How should this be handled?

This is an endpoint only used by the runner, so I think this is fine. But @ayufan should probably approve.

mentioned in issue #29205 (closed)

This is an endpoint only used by the runner, so I think this is fine. But @ayufan should probably approve.

@ayufan What about the breaking changes on the API? There's already an v3 api endpoint (lib/api/v3/runners.rb and lib/api/runners.rb). Does this mean we should maintain the legacy apis and create a v4 for this? Or just keep the legacy for now, and keep the model backwards compatible?

@koffeinfrei Could you describe in short what you want to do?

@ayufan The way runners are handled changed. Basically the is_shared flag on the Ci::Runner model was replaced by STI models Ci::InstanceRunner and Ci::ProjectRunner.

• Shared runners are now instance runners
• Specific runners are now project runners

For now the API is kept backwards compatible, as the functionality hasn't changed. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646 will add a new runner type Ci::GroupRunner which is a runner shared on the group level though.

The question now is how this should be handled on the API level.

/cc @markpundsack @joshlambert for product discussion. We have a community contribution at !9646

@dimitrieh The mockups make me wonder if people need to be able to disable at that granular a level. I imagine they do, but it sure feels a bit overcomplex. Like people should just enable/disable all shared runners (instance and group). But for security, you probably want to be able to disable instance runners, while keeping group runners enabled. Not sure why you'd ever want to disable group runners but leave instance runners active.

Also brings up an interesting question of priority. Are instance and group runners peers and distributed randomly? Do people need to set priorities so they use group-level runners first, for example, and only if they're not available, they use instance runners? Out of scope for now, but I wonder if that will come up.

@dimitrieh Should the group-level settings parallel the project-level settings? i.e. have the page called CI/CD Pipelines, in which there will only be a single section for Runners.

changed milestone to %Next 2-3 months

Based on the new announcement about gitlab.com supporting payed plans, this is the blocker that would prevent me from going to gitlab.com.

I really like the idea of using gitlab.com, but without this feature, its not viable for my org.

mentioned in issue #31218 (moved)

Multiple customers interested in this feature. Initial customer tag was added for @mbell account: https://na34.salesforce.com/00161000004xUPr?srPos=0&srKp=006

Additional request now from: https://na34.salesforce.com/00161000006fyqb

@aolson We're interested in this as well

Thx @drumrigj Customer: https://na34.salesforce.com/0016100000W3J3M Product Management contact me if you need more information on the Enterprise Premium customer.

This is something we are definitely needing:

https://na34.salesforce.com/00161000006g08Q

@bikebilly @joshlambert @markpundsack @JobV Can we please get an update from Product Management on the timeline for this feature proposal? The last update was 2-3 months, 3 months ago.

4 GitLab Enterprise customers have asked for this feature. Contact me if you have questions.

@bikebilly thank you for the rapid response. And sorry for missing the next 2-3 months was set on June 2nd; I defaulted to @markpundsack comments 3 months ago, but you are correct he updated it on June 2nd.

Adding another interested customer: https://na34.salesforce.com/00161000004bZPD

Just want to say this feature would be extremely helpful for my CD plans on multiple personal and professional projects. Very glad to see someone suggested it a long while before I realized how much I need this and that it is on the next 2-3 months roadmap.

+1

+1

Need this

mentioned in issue #18178 (moved)

This will be very useful :)

Yay! Awesome.

moved to gitlab#4152

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue