Is this possible to configure a runner to require that is only used if all its tags are specified in the .gitlab-ci.yml?
Ideally both the runner and the .gitlab-ci.yml should be able to specify for each tag whether the tag is mandatory in the other.
I have a (Windows) runner that I only want to use when my .gitlab-ci.yml contains both the tags “myproject” and “windows”.
I have other (Linux, x64, Docker -based) runners that should be used when my .gitlab-ci.yml contains only the tags “myproject”. These runners therefore have only the tag “myproject”.
My ordinary .gitlab-ci.yml only has the tag “myproject”, but I do not want it to use the Windows runner.
A workaround would be to change all my “usual” runners to have both the tag “myproject” and some new tag, like “docker-linux-x64”, but I would like to avoid that since most branches only care about the default behavior.
I’m a bit confused by the question. Most repos only use a single
.gitlab-ci.yml file (or sometimes they use
includes to factor out some complex jobs), but it sounds like you want to use more than one file, but only sometimes? Is that right?
If you just want to run some jobs, on some branches, or under some conditions on the Windows runner, I would do something like this:
I’ve just used YAML syntax here, but you could do the same sort of thing with extends.
This probably isn’t quite your whole solution, but with careful use of rules and tags, you can usually get any combination of branches / variables / … / runners working together.
Does that help?
Thanks for the feedback.
Something like what you show is what I tried to use, except I did no use any rules.
However, I do not see how your suggestion would prevent the
build:linux64docker (that has tags
myproject) build from using the Windows runner (that has tags
windows) since, in this case, the unwanted runner has all the tags (i.e.
myproject) specified by the
Is there some magic in the elided
rules: that would make it possible to prevent
build:linux64docker from using my Windows runner?
(I have many branches in the repo, they do not all have identical
gitlab-ci.yml. Also, I have more than one repo.)
Ah, sorry, no. If I were you I would add a new tag to the Linux runners, so you can say:
Yes, thanks, adding extra tags to the Linux runners is the workaround I alluded to in my question.
I really would like to avoid adding new tags to all existing “ordinary”
.gitlab-ci.yml files, and to the “ordinary” Linux runners.
Unfortunately I think you’re going to have to make some change somewhere, and you probably only need one extra tag (or to remove the
Just one thing I notice: it sounds like you are using the same runners for multiple repos. There’s nothing wrong with that, but I think most people would choose to have different runners for different projects. It is a bit more overhead to maintain, but it does mean that when you make changes to one runner / project it doesn’t affect the rest. Of course, YMMV!
About the runners: You may be right. The reason we do it this way is to limit how much resources all of our team’s projects/repos use in our organization’s gitlab infrastructure. Also, our team does not manage the gitlab installation.