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

When specifying the branch to poll as part of a parameterized build, git-plugin uses last polled branch instead

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • jenkins version: 2.89.3
      git plugin: 3.8.0
      git client plugin version: 2.7.1

      I have the following Jenkins Pipeline job:

      • Build Trigger: "Poll SCM"
      • Parametrized with String parameter "BRANCH", default value "master"
      • Definition is "Pipeline script from SCM" with Branch Specifier "$BRANCH", "Lightweight checkout" unchecked

      Expected behaviour:
      The job polls SCM. When changes are detected in the branch specified in the default value of the BRANCH parameter ("master" in this case), the job is triggered.

      Actual behaviour:
      The job polls SCM, but it ONLY triggers the job when changes are detected in the branch that was last built.

      This causes the following issue:
      After I manually trigger the job with branch "develop", subsequent changes in branch "master" are ignored.

      This issue also manifests itself when Build Trigger: "Build when a change is pushed to BitBucket" is used.

      This seems to be a regression of issue https://issues.jenkins-ci.org/browse/JENKINS-27327

          [JENKINS-50168] When specifying the branch to poll as part of a parameterized build, git-plugin uses last polled branch instead

          Mark Waite added a comment -

          As far as I can tell, JENKINS-27327 describes an issue in Freestyle jobs and this is an issue for polling in Pipeline jobs. They are quite different. Not a regression.

          Mark Waite added a comment - As far as I can tell, JENKINS-27327 describes an issue in Freestyle jobs and this is an issue for polling in Pipeline jobs. They are quite different. Not a regression.

          Jeroen Smolenaers added a comment -

          markewaite yes, you're quite right. very similar issue otherwise though.

          Jeroen Smolenaers added a comment - markewaite yes, you're quite right. very similar issue otherwise though.

          Jeroen Smolenaers added a comment -

          Additional observation:

          Suppose the refspec is hardcoded "master" and the last built job checked out the same branch. If I change the refspec to "develop" and then commit on that branch, the job will not be triggered ("no changes").

          Presumably this is due to the fact that the branch checkout out by the last built job is checked for changes instead of the branch specified in refspec.

          Jeroen Smolenaers added a comment - Additional observation: Suppose the refspec is hardcoded "master" and the last built job checked out the same branch. If I change the refspec to "develop" and then commit on that branch, the job will not be triggered ("no changes"). Presumably this is due to the fact that the branch checkout out by the last built job is checked for changes instead of the branch specified in refspec.

          Joshua Williams added a comment -

          I've opened a pull request for this issue: https://github.com/jenkinsci/git-plugin/pull/615

          Joshua Williams added a comment - I've opened a pull request for this issue:  https://github.com/jenkinsci/git-plugin/pull/615

          Francisco Robles Martin added a comment -

          Any update on this? I am facing the same issue.

          Francisco Robles Martin added a comment - Any update on this? I am facing the same issue.

          Mark Waite added a comment -

          froblesmartin have you tried the pull request that jkwiz referenced? One of the best ways to help the Jenkins project is to "test drive" pull requests that address issues you're seeing. Compile your own copy of the pull request merged with the master branch and run it in your environment. One other user has done that and reported their results on the pull request. Their results were initially positive, then followed by "not working in more complicated case". If it resolves the issue you're seeing, that's a "double win". If it does not resolve the issue you're seeing, then the project has learned more about the pull request.

          Another technique is to click the "Vote for this issue" in the top right corner of the bug report so that maintainers know which bugs are the most interesting to users.

          Mark Waite added a comment - froblesmartin have you tried the pull request that jkwiz referenced? One of the best ways to help the Jenkins project is to "test drive" pull requests that address issues you're seeing. Compile your own copy of the pull request merged with the master branch and run it in your environment. One other user has done that and reported their results on the pull request. Their results were initially positive, then followed by "not working in more complicated case". If it resolves the issue you're seeing, that's a "double win". If it does not resolve the issue you're seeing, then the project has learned more about the pull request. Another technique is to click the "Vote for this issue" in the top right corner of the bug report so that maintainers know which bugs are the most interesting to users.

          Francisco Robles Martin added a comment -

          markewaite no I haven't tried it. It would be a bit complicated in the project I am working on...

          I have already voted for it, thanks for your reply!

          Francisco Robles Martin added a comment - markewaite no I haven't tried it. It would be a bit complicated in the project I am working on... I have already voted for it, thanks for your reply!

            jkwiz Joshua Williams
            jeroen_s Jeroen Smolenaers
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: