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

Git Plugin: Fast-Remote Polling Does not Filter Branch Name

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None

      Given a build which has an scm trigger, fast remote polling and a branch which is specified via build parameter, then the git-plugin polling will continue to trigger builds even no changes have been made.

      When debugging with both git url and branch as build parameters, it appears the url is able to be resolved correctly, but the branch is not. This appears to affect polling only as the correct branch is able to be built without an scm trigger.

          [JENKINS-17348] Git Plugin: Fast-Remote Polling Does not Filter Branch Name

          Debugging has shown the problem in and about in compareRemoteRevisionWithImpl(..) in GitSCM:

          final String singleBranch = getSingleBranch(lastBuild);
          ...
            String gitRepo = getParamExpandedRepos(lastBuild).get(0).getURIs().get(0).toString();
            ObjectId head = git.getHeadRev(gitRepo, getBranches().get(0).getName());
          
            if (head != null && buildData.lastBuild.getRevision().getSha1().name().equals(head.name())) {
          

          Here singleBranch is able to resolve the branch as a build parameter (in the getSingleBranch(..)), but head always will resolve to null as the branch name is given as a parameter which obviously won't exist in the remote git repo.

          It looks like the branch name for head just needs to be filtered in the same ways getSingleBranch(..) does to accept build parameters.

          Andrew Schurman added a comment - Debugging has shown the problem in and about in compareRemoteRevisionWithImpl(..) in GitSCM : final String singleBranch = getSingleBranch(lastBuild); ... String gitRepo = getParamExpandedRepos(lastBuild).get(0).getURIs().get(0).toString(); ObjectId head = git.getHeadRev(gitRepo, getBranches().get(0).getName()); if (head != null && buildData.lastBuild.getRevision().getSha1().name().equals(head.name())) { Here singleBranch is able to resolve the branch as a build parameter (in the getSingleBranch(..) ), but head always will resolve to null as the branch name is given as a parameter which obviously won't exist in the remote git repo. It looks like the branch name for head just needs to be filtered in the same ways getSingleBranch(..) does to accept build parameters.

          Attached 2 different approaches:

          1. use build parameters from the last build
          2. use default build parameters

          (1) is consistent with the way the scm url are retrieved, but its debatable whether to use the last build parameters when polling.

          Andrew Schurman added a comment - Attached 2 different approaches: use build parameters from the last build use default build parameters (1) is consistent with the way the scm url are retrieved, but its debatable whether to use the last build parameters when polling.

          Chris Nogradi added a comment -

          I would much prefer the default parameter be used for this as this consistent with other SCM parameterized fields.

          Chris Nogradi added a comment - I would much prefer the default parameter be used for this as this consistent with other SCM parameterized fields.

          Don Ross added a comment -

          Seconded... I use the 'default parameter' capability to create a variable which is used in multiple places, including SCM polling, email notification, and some build steps. I have to flag the parameter as 'DO NOT MODIFY' so my users don't screw me up, but it works otherwise.

          Don Ross added a comment - Seconded... I use the 'default parameter' capability to create a variable which is used in multiple places, including SCM polling, email notification, and some build steps. I have to flag the parameter as 'DO NOT MODIFY' so my users don't screw me up, but it works otherwise.

          Mark Waite added a comment -

          Fix included in git plugin 2.4.0 released 18 July 2015

          Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015

            ndeloof Nicolas De Loof
            aschurman Andrew Schurman
            Votes:
            6 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: