Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-65758

Job not triggered on change in GIT, because of "No workspace is available" - no error indication

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core, git-plugin
    • 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:

      1. Set up a job, which uses "Poll SCM" and "Source Code Management" "GIT to trigger"
      2. Configure to check on an existing branch in the GIT repo
      3. Enable the job
        => The job gets triggered, due to the present changes on the branch and no job run at all (fine)
      4. Delete the workspace of the job
      5. 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,

          [JENKINS-65758] Job not triggered on change in GIT, because of "No workspace is available" - no error indication

          Martin Jost added a comment -

          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)

          Martin Jost added a comment - 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)

          Martin Jost added a comment -

          I had a look at all FB branches, where we had a run since the move.

          In all these cases, we triggered the relevant job by hand once. I knew, that I had seen that problem from the corner of my eye, but there I considered it some crazy exception, not a systematic problem, as I see it now.

          Martin Jost added a comment - I had a look at all FB branches, where we had a run since the move. In all these cases, we triggered the relevant job by hand once. I knew, that I had seen that problem from the corner of my eye, but there I considered it some crazy exception, not a systematic problem, as I see it now.

          Mark Waite added a comment -

          Agreed that an administrative monitor would be a good place to show issues with polling. An administrative monitor already reports if there are an unexpected number of polling threads.

          Mark Waite added a comment - Agreed that an administrative monitor would be a good place to show issues with polling. An administrative monitor already reports if there are an unexpected number of polling threads.

            Unassigned Unassigned
            martinjost Martin Jost
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: