jenkins: master-osmo-ggsn is failing since October 1st
For some reason, the master-osmo-ggsn job is always building on the osmo-gsm-tester-rnd slave, instead of host2-deb9build-ansible like all other master builds. This is not intended and probably caused by a bug in jenkins, because this job is generated just like all others from master-builds.yml in osmo-ci.git, with the default "slave_axis" and without overriding it:
slave_axis: !!python/tuple [osmocom-master-debian9]
I've also looked at the job configuration with the jenkins UI, and the slaves are configured exactly the same, as with other master jobs, with just one label that is "osmocom-master-debian9". The build slave, where it always tries to run, osmo-gsm-tester-rnd, is not attached to that label, so this should not happen.
The job started to fail on October 1st, because then osmo-gsm-tester-rnd was not able to resolve git.osmocom.org anymore, therefore failed to clone the source of osmo-ggsn.
I've deleted the workspace on osmo-gsm-tester-rnd, maybe this resolves the problem already.
Right now I can't test whether it worked, because "Jenkins is going to shut down".
#1 Updated by osmith about 1 month ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
After deleting the workspace (and jenkins restart after upgrade), the build is running on the right slave again, and passing \o/
#2 Updated by osmith about 1 month ago
- Status changed from Resolved to In Progress
- % Done changed from 100 to 10
It had worked for exactly one build, then jenkins decided to run the job on osmo-gsm-tester-rnd again for some reason :\
#3 Updated by osmith about 1 month ago
I have changed the slave axis parameter a few times in the jenkins web UI to see if it acts differently, but it does not. I've reset it again to the config generated by the jenkins job builder.
But I found an old upstream issue and replied there, that this is still a problem: https://issues.jenkins-ci.org/browse/JENKINS-15864