Tags for GitLab CI and tags for Git are two different concepts.
When you write your .gitlab-ci.yml, you can specify some jobs with the tag testing. If a runner with this tag associated is available, it will pickup the job.
In Git, within your repository, tags are used to mark a specific commit. It is often used to tag a version.
The two concepts can be mixed up when you use tags (in Git) to start your pipeline in GitLab CI. In your .gitlab-ci.yml, you can specify the section only with tags.
Refer to GitLab documentation for tags and only.
An example is when you push a tag with git:
$ git tag -a 1.0.0 -m "1.0.0"
$ git push origin 1.0.0
And a job in .gitlab-ci.yml like this:
compile:
stage: build
only: [tags]
script:
- echo Working...
tags: [testing]
would start using a runner with the testing tag.
By my understanding, what is missing in your steps is to specify the tag testing to your runner. To do this, go in GitLab into your project. Next to
Wiki, click on Settings. Go to CI/CD Pipelines and there you have your runner(s). Next to its Guid, click on the pen icon. On next page the tags can be modified.
I was tasked with upgrading old runners (Win7 yikes!) and found our tag practices a but uncoordinated. The way things are setup I often had to pause a runner and unpause the new runner hoping to catch my test job. Untagged jobs, a crazy mix of instance/project runners with overlapping configurations, tags like "win" and "win_new".. made it difficult to figure out what will run where.
So I thought I would try to propose some best practices, and figured this would be a good place for feedback.
Broad tag categories and examples
-
Base Functionality, OS information. As much detail as necessary:
-
win_server_2019
-
win_desktop_10
-
linux
-
aix
-
-
Software installed, with version (in the case of msvs, workloads supported):
-
InstallShield9
-
msvs2019_c#_c++_vb
-
msvs2017_vb
-
python2.7
-
-
Security Scope - define capabilities that have security implications:
-
public_internet
-
local_network
-
external_wan_to_other_business_unit
-
code_signing
-
-
Arbitrary tags to assist runner migrations. This is purely self serving, if every job and runner had a gen_1 tag it would pin the jobs to 'gen_1' runners. When I need to migrate a runner, stand up a copy incrementing the gen_x tag and I can start migrating/testing jobs in a very controlled manner:
-
gen_1
-
gen_2
-
you get the idea.
-
Hope that all makes sense. We have a lot of small teams scattered all over the world, 142 projects in a single GitLab instance and no standards ;-)
Thanks for any feedback...
git - Understanding Gitlab CI tags - Stack Overflow
How to use tags to use a specific runner?
How to set tags on Gitlab runner instances? - Stack Overflow
GitLab runner tags
Tags for GitLab CI and tags for Git are two different concepts.
When you write your .gitlab-ci.yml, you can specify some jobs with the tag testing. If a runner with this tag associated is available, it will pickup the job.
In Git, within your repository, tags are used to mark a specific commit. It is often used to tag a version.
The two concepts can be mixed up when you use tags (in Git) to start your pipeline in GitLab CI. In your .gitlab-ci.yml, you can specify the section only with tags.
Refer to GitLab documentation for tags and only.
An example is when you push a tag with git:
$ git tag -a 1.0.0 -m "1.0.0"
$ git push origin 1.0.0
And a job in .gitlab-ci.yml like this:
compile:
stage: build
only: [tags]
script:
- echo Working...
tags: [testing]
would start using a runner with the testing tag.
By my understanding, what is missing in your steps is to specify the tag testing to your runner. To do this, go in GitLab into your project. Next to
Wiki, click on Settings. Go to CI/CD Pipelines and there you have your runner(s). Next to its Guid, click on the pen icon. On next page the tags can be modified.
Are all these operations necessary?
No, if all you have is one runner, or if you have many but do not care which runner runs your job, then there is no point in tagging runners/jobs.
So what if I want to run build only when I define a version in a commit?
job:
only:
- tags
All these years we were setting:
gitlab-runner:
runners:
tags: "my-tag"
In the values.yaml file of the Helm chart. However, I'm in chart version 8.3.2 currently and this value is not respected anymore. Whenever I update it, or upgrade it, it doesn't respect whatever values are set there, and the runner is created without the tag.
Why is that? I have searched for a new way, in case there is one, and couldn't find it. Or maybe it's a bug.
I'm not sure what you want to do with this, but you can solve it this way using the extend function:
.test-prod:
stage: test
script:
- <do your stuff>
test-prod:vm1:
extends: .test-prod
tags:
- vm1
test-prod:vm2:
extends: .test-prod
tags:
- vm2
test-prod:vm3:
extends: .test-prod
tags:
- vm3
If you have separate runners tagged as vm1, vm2, vm3, etc., and you want a job to run on each runner separately without copying and pasting multiple job definitions, the simplest approach would be to use a script to generate the .gitlab-ci.yml file.
tags = ["vm1", "vm2", "vm3"]
with open(".gitlab-ci.yml", "w") as f:
for tag in tags:
f.write(f"""
test-prod-{tag}:
stage: test
tags:
- {tag}
script:
- pwd
""")
Execute this script every time you wish to update the CI/CD pipeline.