Labeled runners should not build unlabeled jobs

At our company we created a pool of generic shared-runners (unlabeled) where recently we added a docker-runner to (labeled 'docker'). It turns out this runner is also building unlabeled jobs, resulting in intermittent failures.

As we didn't want to bother project-owners with looking up tags as part of the CI-setup, we never instructed them to tag jobs. With the new docker-runner though we are forced to ask all of them to update their current jobs with a tag like 'shared' or whatever; which is a pain and feels kinda stupid.

The flow to make the CI 'just work' for projects became much easier recently (add .gitlab-ci.yml to enable, shared-runners enabled by default). Above behavior though would mean adding tags should be a necessary step to prevent failure when an odd-runner is added to the pool sometime in the future.

Please consider changing this.

Would love some ideas on this one. Is the above intended beheavior? /cc @ayufan @JobV @dzaporozhets

I kind of agree with you that this can be problematic, but also I'm not sure how to resolve this. Maybe @JobV @dzaporozhets have some ideas.

Maybe this:

Unlabeled jobs should be build by unlabeled runners => 'General' Runners that are able to build most projects. Doesn't work? Just add the appropriate label to your project.

Labeled jobs should be build by labeled runners => 'Specific' Runners that are only intended to build the projects they have a label for.

Solution for CI: suggest to add a label for your project if it has non-standard requirements.

On GitLab.com we can make unlabeled support as much as possible and make sure the documentation specifies what is / isn't supported.

@JobV it makes it even harder to understand, since we already have Shared and Specific runners.

Maybe we can just introduce the runner option to fine tune them: Use for unlabelled builds. Default: true.

OOB: This would also open us possibility to introduce the second option that I'm thinking for sometime: Use for protected builds only (the protected are the ones that are created from protected branch).

@ayufan yes, that's what I mean. I think we shouldn't actually give them names, it's just the behavior that I meant that it should have.

To your other points: love it

Milestone changed to 8.4

Reassigned to @ayufan

Added ~19173 label

Milestone changed to 8.6

I hit this today and would like to see this feature added. I'd be happy with either a per-runner boolean option that said "use this runner for untagged builds" or "only use this runner for builds with a matching tag". Both mean the same, but with a different perspective.

Alternatively, I suppose a GitLab wide option could exist that says what happens to untagged builds. Do they run anywhere, run on runners with no tags, or even run on runners with a specific tag of the admin's choice?

Whatever is easier, any of the above would work for me :-)

Milestone changed to 8.7

Milestone changed to 8.8

mentioned in issue #17202 (closed)

My preference is a per-runner boolean option named "allow this runner to build untagged jobs" that defaults to checked. If the runner has no tags, the option is checked and greyed out (it's not possible to uncheck it). (This is the same as the suggestion by @ayufan but with some slight tweaks.)

Reassigned to @grzesiek

mentioned in merge request !4039 (merged)

Status changed to closed by merge request !4039 (merged)

mentioned in commit f26389a0

Mentioned in commit pfjason/gitlab-ce@f26389a0