Niels Möller <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
