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

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None
    • jenkins 1.598
      git-plugin 2.3.1
      git-1:1.7.9.5-1ubuntu0.1
      ubuntu linux 12.04.5 LTS

      When configuring a project to use git-plugin to poll SCM for changes and using a parameterized build to specify a branch, git-plugin polls the last polled branch instead of the default parameter specified.

      1. on any job using a git repository, add a string parameter to represent the branch or tag, say 'deploy_tag', with a default value of 'testing'
      2. configure the git repository, replace 'Branch Specifier' with ${deploy_tag}
      3. enable 'Poll SCM' and set time period to H/5 * * * *
      4. save configuration
      5. deploy application / service using the master branch
      6. watch git polling log for polling results

      Expected behavior:
      The polling log would show that the deploy_tag branch was polled.

      Actual behavior:
      The polling log will indicate that the master branch was polled.

      Use case:
      I have a client where branches are used to deploy different code to different environments. This allows a developer to deploy code to an environment by merging changes to a specific branch. I would like to be able to always deploy branch X to development automatically while allowing manual deployments to other environments without causing the default deploy scenario to fail. Right now, I have to ensure that I run a manual deploy to development after any manual deploy to staging, production, etc.. or the development build will not trigger a change until the next master commit.

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

          Mark Waite added a comment - - edited

          I ran various interactive tests with the git plugin 2.4 pre-release and the git client plugin 1.18.0 pre-release. It behaved as I expected in all cases.

          1. Create a bare git repository /var/lib/git/mwaite/bugs/JENKINS-27349.git
          2. Commit a master branch to that repository
          3. Commit a branch named "default-branch" to that repository
          4. Create a freestyle job, "JENKINS-27349"
          5. Add string parameter BRANCH_TO_BUILD with "default-branch" as default
          6. Define git repository to use the bare repository
          7. Build the job with BRANCH_TO_BUILD "master" (Confirm the master branch built as expected)
          8. Commit a change to the default-branch
          9. Use the "poll now" button to poll the repository for that job (Confirm that the build happened because there was a change on default-branch which the poll detected)
          10. Configure a post-receive hook on the repository
          11. Commit a change to the default-branch (Confirm that the job polled, Confirm that the poll triggered the default-branch)

          Mark Waite added a comment - - edited I ran various interactive tests with the git plugin 2.4 pre-release and the git client plugin 1.18.0 pre-release. It behaved as I expected in all cases. Create a bare git repository /var/lib/git/mwaite/bugs/ JENKINS-27349 .git Commit a master branch to that repository Commit a branch named "default-branch" to that repository Create a freestyle job, " JENKINS-27349 " Add string parameter BRANCH_TO_BUILD with "default-branch" as default Define git repository to use the bare repository Build the job with BRANCH_TO_BUILD "master" (Confirm the master branch built as expected) Commit a change to the default-branch Use the "poll now" button to poll the repository for that job (Confirm that the build happened because there was a change on default-branch which the poll detected) Configure a post-receive hook on the repository Commit a change to the default-branch (Confirm that the job polled, Confirm that the poll triggered the default-branch)

          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
            itsecureadmin Josh Miller
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: