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

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

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite 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*"

            Show
            markewaite 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*"
            Hide
            wannessels 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.

            Show
            wannessels 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.
            Hide
            jkush 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

            Show
            jkush 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
            Hide
            markewaite Mark Waite added a comment -

            Jason Kushmaul, 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.

            Show
            markewaite Mark Waite added a comment - Jason Kushmaul , 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.
            Hide
            cxmcc X Chen added a comment -

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

            Show
            cxmcc X Chen added a comment - I have this problem even if branch is not wildcard. Branch is "origin/master"
            Hide
            cxmcc 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.

            Show
            cxmcc 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.
            Hide
            arnom Arno Moonen added a comment -

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

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

              People

              • Assignee:
                Unassigned
                Reporter:
                aqian Alan Qian
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: