-
Bug
-
Resolution: Unresolved
-
Major
-
Jenkins 2.277.4
GIT plugin 4.7.1
Git client plugin 3.7.1
Running on Redhat 7; no container
Using openJDK11
We had a feature build branch, where no builds got triggered by updates in GIT, although there had been changes. After a longer search, I found in the GIT polling log of the job:
"No workspace is available, so can’t check for updates. (nonexisting_workspace)"
My problem is, that there is no error indication, besides the note in the polling log, so the problem goes unnoticed. (The workspace probably got lost, when we moved to another server)
How to reproduce the issue:
- Set up a job, which uses "Poll SCM" and "Source Code Management" "GIT to trigger"
- Configure to check on an existing branch in the GIT repo
- Enable the job
=> The job gets triggered, due to the present changes on the branch and no job run at all (fine) - Delete the workspace of the job
- The job doesn't trigger again, although the GIT branch gets new commits.
There is no clearly visible error indication.
The only indication I was able to find, is the error message in the polling log.
When I searched all "scm-polling.log"-files on our master, I found a whole bunch of jobs with the same problem.
Note: I'm not sure what Jenkins should do on this case. E.g. there is no job run to turn red.
Maybe one approach would be, to trigger a job run in this case and make it red,
One place to report, could be an "Administrative Monitor"
(Hopefully one for all the jobs affected - otherwise it could be many of those)
Side-Note:
I just confirmed that we "lost" the workspaces when changing the Jenkins master.
We do an "rsync" to copy the stuff over, but we exclude (on purpose) the workspaces. Once to save time, secondly to "once in a while" start over, in case something got wedged in the workspace. What I don't understand is, why seemingly we didn't had problems for ALL our feature build branches - and there is a bunch of these. I will try to analyze this as next step. (It will be tricky, because for the triggering jobs, I will only see the current SCM polling log and not what happened right after switching)