Niels Möller <[email protected]> writes: > Replying to an old thread: > > Niels Möller <[email protected]> writes: > >> [email protected] writes: >> >>> Hi, it seems both the GitLab and GitHub mirrors are working now. >>> Will the Nettle CI move back to GitLab or stay at git.lysator.liu.se? >> >> I think I'd prefer to keep some or all at lysator, to not have to store >> the secret key needed for the s390x remote job at gitlab.com, and not >> have the mirroring delay. But it would be nice to run at both places, if >> I can figure out what tag(s) to set to make that work. > > I'm not that familiar with how tags work in gitlab (and at the > gitlab.com instance in particular). Previously, jobs in nettle's > .gitlab-ci.yml used the tag "saas-linux-small-amd64". To work on the > runner set up by Simon, which gets jobs from git.lysator.liu.se, I > changed that to just "amd64". > > Can I add multiple tags (and get jobs to be picked up by runners > recognizing any of those tags)? And what is the right tag to have jobs > running on .gitlab.com under the umbrella of the gnutls project?
Runner tags is a bit inflexible in GitLab CI/CD. When specified, the .gitlab-ci.yml tags must all be met by the runner. I don't think it is possible to express "run this job on tag X or tag Y". (I would be happy if proven wrong on this!) I think the GitLab way to deal with this is to add multiple jobs, one for each tag, and enable/disable each of them using a 'rules:' mechanism to figure out if it should run or not. This is complex so I dislike it. I think you could edit the Runner definition and just add 'saas-linux-small-amd64' to my runner, for your project, and then change .gitlab-ci.yml to use that tag. The tags for a runner can be modified per project or per group. However this may not do the right thing for other jobs, and it is really confusing to steal someone else's tag... You could also remove any 'tags: ' line and then enable 'Run untagged jobs' for my runner. I must admit I forgot what you were using my amd64 runner for, but I just got approved for a permenant s390x virtual machine from IBM (the community VM's I had seems to expire after a couple of weeks...) and I will setup a proper GitLab runner on it. Assuming I'm successful with this, I'm happy for nettle to use it too. Then you don't have to store the SSH key at any gitlab site (although they still store runner secrets, which pretty much have the same capabilities, so I'm not sure if this really makes a difference). I also have a paid GitLab.com subscription on gitlab.com/gsasl/ that I use to mirror some projects for CI. Adding a nettle mirror there would be simple, and then CI would just appear automatically without you doing anything. In fact, I'll see if this works now... yes it works, but stuck because of the tags: https://gitlab.com/gsasl/nettle/-/pipelines/2264710712 Thus I would recommend to just remove the 'tag: amd64' from your .gitlab-ci.yml, enable 'Run untagged jobs' for my amd64 runner if you want to keep it, and things should work everywhere? /Simon
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
