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

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

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • git-plugin
    • None
    • git-plugin 2.3.5

    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

          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-27327 When specifying the branch to poll as part of a parameterized build, git-plugin uses last polled branch instead

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 10 older comments
            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.

            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.
            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.

            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.
            markewaite Mark Waite added a comment -

            Thanks for the test results. Very much appreciated!

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

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

            nicolas_applidium Nicolas Braun added a comment - I ran som test too and so far the behavior is correct
            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)

            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

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

              Dates

                Created:
                Updated:
                Resolved: