Please configure trusted runners on https://gitlab.wikimedia.org/repos/mediawiki/services/smokepy/ so I can publish images. these images iwll be used to perform system tests during API gateway deployments.
Description
Description
Details
Details
Related Changes in GitLab:
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| add repos/mediawiki/services/smokepy to projects.json | repos/releng/gitlab-trusted-runner!172 | jnuche | T426665 | main |
Event Timeline
Comment Actions
IIUC from this commit message, the code in this repo may have been extracted from the operations/deployment-charts Gerrit repo; in which case I guess the code may be licensed under GPLv3?
(To be clear, the repo should probably still have a LICENSE file, but just saying this in case it helps to clear up which license the code may already be released under)
Comment Actions
jnuche opened https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/172
add repos/mediawiki/services/smokepy to projects.json
Comment Actions
jnuche merged https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/172
add repos/mediawiki/services/smokepy to projects.json
Comment Actions
Re-opening, because this still doesn't seem to be working. I do see the trusted runner, but the publish-canidate job still gets stuck with the message "This job is stuck because of one of the following problems. There are no active runners online, no runners for the protected branch , or no runners that match all of the job's tags: trusted".
There seems to be some bit missing, but I don't understand what exactly.
Comment Actions
Fixed now, public-candidate job ran successfully: https://gitlab.wikimedia.org/repos/mediawiki/services/smokepy/-/jobs/828344
There were no protected tags at https://gitlab.wikimedia.org/repos/mediawiki/services/smokepy/-/settings/repository#js-protected-tags-settings so I added them. A similar problem actually happened recently for another GitLab trusted runners request. The protected tags config is actually a requirement mentioned here, so it seems we need to remember to double check that as part of servicing these access tickets.
@dancy saw the issue recently, I'm pinging him in case he has more useful context
Comment Actions
Thank you @jnuche! I see the requirements mention the job must specify the trusted tag, but as someone with limited gitlab experience, it don't know how to do that... I don't even know what "tag" refers to in this context. It's not a git tag, right?... That's confusing, since I'm indeed using git tags to trigger the job, and "protected tags" is part of the setup...
Comment Actions
Yep, we are indeed talking about regular git tags We are using two kinds of "tags" in this context. There is indeed the regular git tags:
jnuche@erebor:/tmp $ git ls-remote --tags git@gitlab.wikimedia.org:repos/mediawiki/services/smokepy.git 3e44029565f20d5e015196e8812750e98f93a177 refs/tags/v0.1-dev 2d29db32cd602fea6c31512d5c6f26fca16d2b8c refs/tags/v0.2-dev
"Protected tags" however are a GitLab concept, you would typically configure them via the GitLab web UI.
The three pieces are:
- Access to Trusted Runners: Requires entry in https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/blob/main/projects.json
- Job must be tagged (GitLab job tag, no relation to git) with trusted. You already had that in your .gitlab-ci.yml
- Your (git) tags must be marked as protected by GitLab. You can do that at https://gitlab.wikimedia.org/repos/mediawiki/services/smokepy/-/settings/repository#js-protected-tags-settings. The usual approach is to specify the pattern v* so all your tags, present and future, get protected
Comment Actions
And what was the bit I was missing?
The protected tags at https://gitlab.wikimedia.org/repos/mediawiki/services/smokepy/-/settings/repository#js-protected-tags-settings
But as mentioned it seems to me the person servicing the access request (in this case, me) should be verifying that configuration as part of completing the ticket. Someone may correct me on this point though.