Niels Möller nisse@lysator.liu.se writes:
I must admit I forgot what you were using my amd64 runner for,
I use if for a dozen build jobs, both native builds in various configurations, and cross builds with qemu tests. And then the special s390x job that uses ssh to my IBM test vm.
Is this still true now? I see
https://git.lysator.liu.se/nettle/nettle/-/jobs/4086
that lysator's shared runners appears to be used. I don't know their availability, no problem keeping my runner in the configuration.
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.
That would be nice!
I'm still waiting for the VM, but at they confirmed I was eligble.
I've now tried adding the "Run untagged jobs" for the runner. So if I understand it correctly, the tags don't belong to the runner machinery itself, they are attached on the association between runner machines and gitlab projects?
Yes. In earlier times the tags came from the runner, not the gitlab project configuration. I think this is still somewhat confused area.
I see that I now get jobs started at gitlab.com, but they fail because
BUILDENV_NATIVE_IMAGE: nettle/build-images:buildenv-native
image: $CI_REGISTRY/$BUILDENV_NATIVE_IMAGE
I've pushed another change to that branch, replacing $CI_REGISTRY with a reference to git.lysator.liu.se:5050/. I wonder if there are any potential problems with having gitlab.com (and any other mirrors) pull images from that server? One would hope gitlab runners cache images, but I don't know. The server should have plenty of bandwidth, connected to the university network.
Runners cache images, but gitlab.com has many runners so in practice the end result vary. I wouldn't worry about this traffic.
And now ci it gitlab.com is working too for this branch, see https://gitlab.com/gnutls/nettle/-/pipelines/2268610930. If I look at a random job, it is picked up by the runner "#12270845 (JLgUopmM) 1-green.saas-linux-small-amd64.runners-manager.gitlab.com/default". So it seems no tagging is required.
All jobs at gitlab.com succeeded except remote/s390x, which failed because I still had CI-variables set with a revoked ssh key. I've now deleted those variables, and job should hopefully be skipped based on job rules on next attempt.
And I also checked that the github mirror appears up-to-date, https://github.com/gnutls/nettle.
The pipeline for the mirror I added is green, without me doing anything - so I think your configuration is good:
https://gitlab.com/gsasl/nettle/-/pipelines
Given that gitlab.com/gnutls finally approved for the OSS Ultimate plan, I suspect there is no point in having a gitlab.com/gsasl/nettle mirror for pipelines, so I will remove the gsasl one.
/Simon