master-osmo-gsm-manuals job fails to build
For some strange reason, the job https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-gsm-manuals/ failed to build from June 3rd onwards.
The failure is:
java.io.IOException: [ssh-agent] Could not find specified credentials
But what's even more odd than this: It wants to start the job on a deprecated debian8 slave:
Building remotely on @build2-deb8build-ansible@ (linux_amd64_debian8) in workspace /home/osmocom-build/jenkins/workspace/master-osmo-gsm-manuals
Where the job configuration clearly states it should be built on an "osmocom-master-debian9" label. The
build2-deb8build-ansible node clearly doesn't have that label ?!? I'm a bit lost here.
for matrix builds jenkins often start the coordinating build on a completely unrelated build slave. That got me completely confused more than once, e.g. some gerrit verification builds being started on the osmo-gsm-tester APU. But it's only the orchestrator of the individual matrix builds which then again adhere to the slave selection. Since our jjb have this slave-axis thing, all of our builds are like this, IIUC.
#2 Updated by laforge about 2 months ago
- Priority changed from Normal to Urgent
lynxis well, it's nice to know that those jobs might start on other slaves. the problem persists though, and we're not building osmo-gsm-manuals for 25 days it seems. This means that users will received outdated manuals, and it should be investigated rather urgently.
#3 Updated by laforge about 2 months ago
- Assignee changed from lynxis to daniel
#4 Updated by daniel about 2 months ago
I changed the upload url to point to the old server, but that doesn't fix the issue reported here.
I did have some luck setting the "Restrict where this project can be run" option to "osmocom-master-debian9". For matrix builds this restricts also where the parent build can be run.