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

Job polling hangs while a build is running - only when branch specifier contains wildcard

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      I have just discovered that if we configure the Jenkins job to contain wildcards in the Branch Specifier field, e.g. origin/personal/**, then the polling of the job would just hang after the first line:

      Git Polling Log

      Started on Oct 24, 2014 4:37:58 PM

      This would stay like that until the currently running build of this job completes. Then polling would go through in sub-seconds. I tried specifying a fully spelt-out branch specifier, and this problem goes away.

      Normally this would not be a problem, but we are now trying to enable concurrent builds for this job. That means, as long as there's one build in progress for this job, no additional builds can start (since polling is hanging) until the current build finishes. So this bug effectively breaks concurrent jobs that relies on polling.

      We are on Jenkins 1.578, and Git plugin 2.2.7.

          [JENKINS-25304] Job polling hangs while a build is running - only when branch specifier contains wildcard

          Mark Waite added a comment -

          I can reproduce this bug. Whether I use command line git or JGit as the git implementation, if a wildcard character is in the branch name portion of the "Branches to build" field, the polling will block while the job is running.

          Steps I took include:

          1. Define a new freestyle project
          2. Use git as the SCM, with a convenient repository as the source
          3. Define "Branches to build" as "/master" or "/m*r" or "/*"
          4. Enable polling once a minute
          5. Add a build step which sleeps for 2 minutes
          6. Wait for the job to poll, or use a hook to force polling
          7. While the job is sleeping, either use the hook to force another poll, or wait for the next polling cycle
          8. Open the git polling log to see that polling has started but not finished

          With those steps, the polling blocked until the job completed

          A wildcard in the remote name portion does not have the same impact. Thus, I can use "/master" successfully, but not "/master*"

          Mark Waite added a comment - I can reproduce this bug. Whether I use command line git or JGit as the git implementation, if a wildcard character is in the branch name portion of the "Branches to build" field, the polling will block while the job is running. Steps I took include: Define a new freestyle project Use git as the SCM, with a convenient repository as the source Define "Branches to build" as " /master " or " /m*r" or " /*" Enable polling once a minute Add a build step which sleeps for 2 minutes Wait for the job to poll, or use a hook to force polling While the job is sleeping, either use the hook to force another poll, or wait for the next polling cycle Open the git polling log to see that polling has started but not finished With those steps, the polling blocked until the job completed A wildcard in the remote name portion does not have the same impact. Thus, I can use " /master" successfully, but not " /master*"

          Wannes Sels added a comment -

          The issue is in the logic that decides how to do polling, see GitSCM.requiresWorkspaceForPolling().
          If you specify one repository and one branch, the wildcard in the branchname before "/" can only be expanded to the single repository.
          If however you specify a wildcard in the branch name, GitAPI.getHeadRev(remoteRepoUrl, branchSpec) would return the first matching branchName instead of all matching branches.

          I suppose you could change GitSCM.compareRemoteRevisionWithImpl to get all branches with GitAPI.getHeadRev(remoteRepoUrl), and check each one if it has been built.

          Wannes Sels added a comment - The issue is in the logic that decides how to do polling, see GitSCM.requiresWorkspaceForPolling(). If you specify one repository and one branch, the wildcard in the branchname before "/" can only be expanded to the single repository. If however you specify a wildcard in the branch name, GitAPI.getHeadRev(remoteRepoUrl, branchSpec) would return the first matching branchName instead of all matching branches. I suppose you could change GitSCM.compareRemoteRevisionWithImpl to get all branches with GitAPI.getHeadRev(remoteRepoUrl), and check each one if it has been built.

          I am having same problem with Git polling hanging, and guess what, it's with "/release/" branch specifier.

          No fix at the following link, but here are my details to reproduce the problem similar to Mark's comment's above.

          https://issues.jenkins-ci.org/browse/JENKINS-14752?focusedCommentId=215400&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-215400

          Jason Kushmaul added a comment - I am having same problem with Git polling hanging, and guess what, it's with " /release/ " branch specifier. No fix at the following link, but here are my details to reproduce the problem similar to Mark's comment's above. https://issues.jenkins-ci.org/browse/JENKINS-14752?focusedCommentId=215400&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-215400

          Mark Waite added a comment -

          jkush, I think the details described at that link are different than this case.

          In this case, the polling is performed with "git ls-remote" and the polling blocks until the job completes, then continues and runs successfully to completion. In JENKINS-14752, the polling seems to hang indefinitely and leave orphan processes on the computer hosting the job.

          As far as I can tell, there is no indication that this problem leaves orphan processes behind. The "git fetch" that you see hanging is not a polling activity, that is pulling in the changes which were detected by the earlier polling.

          Mark Waite added a comment - jkush , I think the details described at that link are different than this case. In this case, the polling is performed with "git ls-remote" and the polling blocks until the job completes, then continues and runs successfully to completion. In JENKINS-14752 , the polling seems to hang indefinitely and leave orphan processes on the computer hosting the job. As far as I can tell, there is no indication that this problem leaves orphan processes behind. The "git fetch" that you see hanging is not a polling activity, that is pulling in the changes which were detected by the earlier polling.

          X Chen added a comment -

          I have this problem even if branch is not wildcard. Branch is "origin/master"

          X Chen added a comment - I have this problem even if branch is not wildcard. Branch is "origin/master"

          X Chen added a comment -

          Alright. If I specify one branch that is not wildcard, it is fine.

          If wildcard branch or more than one branches specified. This issue occurs.

          X Chen added a comment - Alright. If I specify one branch that is not wildcard, it is fine. If wildcard branch or more than one branches specified. This issue occurs.

          Arno Moonen added a comment -

          I also experience similar behavior with other SCM configurations, like AccuRev for example.

          Arno Moonen added a comment - I also experience similar behavior with other SCM configurations, like AccuRev for example.

          Alexey Bychko added a comment -

          I faced the same issue with wildcard in branch name

          Alexey Bychko added a comment - I faced the same issue with wildcard in branch name

            Unassigned Unassigned
            aqian Alan Qian
            Votes:
            4 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: