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

Git SCM-polling uses wrong parameter values for a parametrized branchspec

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      git-plugin 2.3.5
    • Similar Issues:

      Description

      This is a follow-up to JENKINS-14276. I'm creating this to better track the issues I fixed in my original pull-request [1], which I will update accordingly.

      To reproduce:

      • A parametrized build with parameter BRANCH_TO_BUILD, with default value "branch1"
      • Git SCM with branch specifier "${BRANCH_TO_BUILD}"
      • SCM polling enabled
      • Previous manual job launch with BRANCH_TO_BUILD=branch2

      Expected:

      • When polling, BRANCH_TO_BUILD is set to branch1 (default value), so only updates to branch1 trigger a build.

      Actual:

      • When polling, BRANCH_TO_BUILD is set to branch2 (value from last execution).

      [1] https://github.com/jenkinsci/git-plugin/pull/293

        Attachments

          Issue Links

            Activity

            Hide
            pmv pmv added a comment -

            Thanks Mark. 308 doesn't look too dangerous, but we default our parameter to '**' instead of leaving it blank, so I believe we'll work fine without it. I'll give your new build a try.

            Show
            pmv pmv added a comment - Thanks Mark. 308 doesn't look too dangerous, but we default our parameter to '**' instead of leaving it blank, so I believe we'll work fine without it. I'll give your new build a try.
            Hide
            pmv pmv added a comment -

            So far so good. We do a lot of builds per day, so I consider this tested for our use cases. Our git config across jobs is pretty homogeneous, though, so I can't claim all features of the plugin have been tested (I'm sure there are plenty we don't use). Thanks again for the new build.

            Show
            pmv pmv added a comment - So far so good. We do a lot of builds per day, so I consider this tested for our use cases. Our git config across jobs is pretty homogeneous, though, so I can't claim all features of the plugin have been tested (I'm sure there are plenty we don't use). Thanks again for the new build.
            Hide
            markewaite Mark Waite added a comment -

            Thanks for the test results. Very much appreciated!

            Show
            markewaite Mark Waite added a comment - Thanks for the test results. Very much appreciated!
            Hide
            nicolas_applidium Nicolas Braun added a comment -

            I ran som test too and so far the behavior is correct

            Show
            nicolas_applidium Nicolas Braun added a comment - I ran som test too and so far the behavior is correct
            Hide
            markewaite Mark Waite added a comment -

            I ran some verification tests switching between 2.3.5 (buggy) and the next pre-release. It was well behaved in all the cases I tested.

            0. Create a bare git repository /var/lib/git/mwaite/bugs/JENKINS-27349.git
            0. Commit a master branch to that repository
            0. Commit a branch named "default-branch" to that repository
            1. Create a freestyle job, "JENKINS-27349"
            2. Add string parameter BRANCH_TO_BUILD with "default-branch" as default
            3. Define git repository to use the bare repository
            4. Build the job with BRANCH_TO_BUILD "master"
            1. Confirm the master branch built as expected
            5. Commit a change to the default-branch
            6. Use the "poll now" button to poll the repository for that job
            1. Confirm that the build did not happen even though there was a
            change on default-branch which the poll should have detected (bug)
            7. Configure a post-receive hook on the repository
            8. Commit a change to the default-branch
            1. Confirm that the job polled
            2. Confirm that the poll did not trigger the default-branch even
            though that is the default value (bug)

            Show
            markewaite Mark Waite added a comment - I ran some verification tests switching between 2.3.5 (buggy) and the next pre-release. It was well behaved in all the cases I tested. 0. Create a bare git repository /var/lib/git/mwaite/bugs/ JENKINS-27349 .git 0. Commit a master branch to that repository 0. Commit a branch named "default-branch" to that repository 1. Create a freestyle job, " JENKINS-27349 " 2. Add string parameter BRANCH_TO_BUILD with "default-branch" as default 3. Define git repository to use the bare repository 4. Build the job with BRANCH_TO_BUILD "master" 1. Confirm the master branch built as expected 5. Commit a change to the default-branch 6. Use the "poll now" button to poll the repository for that job 1. Confirm that the build did not happen even though there was a change on default-branch which the poll should have detected (bug) 7. Configure a post-receive hook on the repository 8. Commit a change to the default-branch 1. Confirm that the job polled 2. Confirm that the poll did not trigger the default-branch even though that is the default value (bug)

              People

              • Assignee:
                ndeloof Nicolas De Loof
                Reporter:
                jblanchard Jean Blanchard
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: