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

Git SCM polling is not triggered from a push notification with a parametrized branchspec

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

      To reproduce:

      • A parametrized build with parameter BRANCH_TO_BUILD
      • Git SCM with branch specifier "${BRANCH_TO_BUILD}"
      • SCM polling enabled

      Expected:

      • A push notification should trigger the polling for the job

      Actual:

      • Polling is not triggered

        Attachments

          Activity

          jblanchard Jean Blanchard created issue -
          Hide
          jblanchard Jean Blanchard added a comment -
          Show
          jblanchard Jean Blanchard added a comment - Fixed in pull-request https://github.com/jenkinsci/git-plugin/pull/309
          Hide
          nicolas_applidium Nicolas Braun added a comment -

          Hi Jean,

          I am having some problems with my CI server too and I am wondering if it is the same problem !
          Configuration is the same :

          • A basic multi-branch job with a parametrized build with parameter BRANCH_TO_BUILD, default **
          • Git SCM with branch specifier "${BRANCH_TO_BUILD}"
          • SCM polling enabled

          Basically what I would like is for the job to trigger a build on any branch (develop, master, feature/xx) if there is a commit on it. I can also manually build a specific branch

          What seems to happen is that Jenkins will only poll changes in the branch I manually build. For example :
          • if I build manually /develop, afterward my automatic poll will only track changes in develop http://i.imgur.com/8L5tuTS.png
          • if I the trigger on manually build with parameter ** then the automatic poll will correctly track all branches http://i.imgur.com/HgBwRMM.png

          I believe this is the same issue (or maybe https://issues.jenkins-ci.org/browse/JENKINS-27349 - all 3 seems related) but please confirm otherwise I will open a dedicated issue

          Nicolas

          Show
          nicolas_applidium Nicolas Braun added a comment - Hi Jean, I am having some problems with my CI server too and I am wondering if it is the same problem ! Configuration is the same : • A basic multi-branch job with a parametrized build with parameter BRANCH_TO_BUILD, default ** • Git SCM with branch specifier "${BRANCH_TO_BUILD}" • SCM polling enabled Basically what I would like is for the job to trigger a build on any branch (develop, master, feature/xx) if there is a commit on it. I can also manually build a specific branch What seems to happen is that Jenkins will only poll changes in the branch I manually build. For example : • if I build manually /develop, afterward my automatic poll will only track changes in develop http://i.imgur.com/8L5tuTS.png • if I the trigger on manually build with parameter ** then the automatic poll will correctly track all branches http://i.imgur.com/HgBwRMM.png I believe this is the same issue (or maybe https://issues.jenkins-ci.org/browse/JENKINS-27349 - all 3 seems related) but please confirm otherwise I will open a dedicated issue Nicolas
          pmv pmv made changes -
          Field Original Value New Value
          Assignee Nicolas De Loof [ ndeloof ] pmv [ pmv ]
          Hide
          pmv pmv added a comment -

          Nicolas - your setup sounds like ours. With Jean's patches, and with our jobs configured to require a workspace for polling, it works as we expect. So I don't think you need a new ticket - you either need to manually build the plugin with Jean's changes or wait for them to be included in a release.

          Show
          pmv pmv added a comment - Nicolas - your setup sounds like ours. With Jean's patches, and with our jobs configured to require a workspace for polling, it works as we expect. So I don't think you need a new ticket - you either need to manually build the plugin with Jean's changes or wait for them to be included in a release.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Jean Blanchard
          Path:
          src/main/java/hudson/plugins/git/GitStatus.java
          src/test/java/hudson/plugins/git/GitStatusTest.java
          http://jenkins-ci.org/commit/git-plugin/cc2ddb7dd0207401c4515633f5c3704757107199
          Log:
          JENKINS-27352 Fix commit notification for a parametrized branchspec

          When the branchspec is parametrized, and a commit notification is received for
          the tracked repository, the polling is always triggered, even if a sha1 was
          received.

          Also, add some FINE logs to the notifyCommit code.

          Compare: https://github.com/jenkinsci/git-plugin/compare/9369a12c7bc4...cc2ddb7dd020

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jean Blanchard Path: src/main/java/hudson/plugins/git/GitStatus.java src/test/java/hudson/plugins/git/GitStatusTest.java http://jenkins-ci.org/commit/git-plugin/cc2ddb7dd0207401c4515633f5c3704757107199 Log: JENKINS-27352 Fix commit notification for a parametrized branchspec When the branchspec is parametrized, and a commit notification is received for the tracked repository, the polling is always triggered, even if a sha1 was received. Also, add some FINE logs to the notifyCommit code. Compare: https://github.com/jenkinsci/git-plugin/compare/9369a12c7bc4...cc2ddb7dd020
          Hide
          markewaite Mark Waite added a comment -

          Fix included in git plugin 2.4.0 released 18 July 2015

          Show
          markewaite Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015
          markewaite Mark Waite made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          morr Daniel Horecki added a comment -

          Using Jenkins LTS version 1.609.2 and git plugin 2.4.0. This fix may break builds when there are some default parameters. When job is triggered by hand, parameters are present. When build is triggered by commit notification, parameters are gone.

          Show
          morr Daniel Horecki added a comment - Using Jenkins LTS version 1.609.2 and git plugin 2.4.0. This fix may break builds when there are some default parameters. When job is triggered by hand, parameters are present. When build is triggered by commit notification, parameters are gone.
          Hide
          morr Daniel Horecki added a comment -

          After downgrading to git plugin 2.3.5 situation is normal - both triggers have parameters set.

          Show
          morr Daniel Horecki added a comment - After downgrading to git plugin 2.3.5 situation is normal - both triggers have parameters set.
          Hide
          markewaite Mark Waite added a comment -

          Daniel Horecki can you provide a more specific example so that the case you're describing can be investigated further?

          When the job is "triggered by hand", I assume that means that it is launched through the Jenkins job page and the parameters are provided as part of that job. Is that correct?

          When "build is triggered by commit notification", I assume that means an external process (curl, wget, etc.) invokes a commitNotify URL (http://your-jenkins/jenkins/commitNotify?more-details). Is that correct? If so, what are the details included in that commitNotify URL?

          Show
          markewaite Mark Waite added a comment - Daniel Horecki can you provide a more specific example so that the case you're describing can be investigated further? When the job is "triggered by hand", I assume that means that it is launched through the Jenkins job page and the parameters are provided as part of that job. Is that correct? When "build is triggered by commit notification", I assume that means an external process (curl, wget, etc.) invokes a commitNotify URL ( http://your-jenkins/jenkins/commitNotify?more-details ). Is that correct? If so, what are the details included in that commitNotify URL?
          Hide
          morr Daniel Horecki added a comment -

          Yes, it is correct for "triggered by hand". Commit notification comes from Stash Webhook to Jenkins and only parameter there is URL of git repository, e.g. 'http://jenkins:8080/jenkins/git/notifyCommit?url=https://stash-server/scm/project/repo.git'. There is no any option to include any additional parameters from this hook.

          Show
          morr Daniel Horecki added a comment - Yes, it is correct for "triggered by hand". Commit notification comes from Stash Webhook to Jenkins and only parameter there is URL of git repository, e.g. 'http://jenkins:8080/jenkins/git/notifyCommit?url= https://stash-server/scm/project/repo.git '. There is no any option to include any additional parameters from this hook.
          Hide
          pmv pmv added a comment -

          We've been using 2.4.0 since it came out, and we have seen a problem identical to what Daniel describes. For us it has been very rare. We've had hundreds of builds triggered by commit notifications (coincidentally, also the Stash hook), and have only had two or three missing parameters. Since for us it has been so infrequent (and also impossible to recreate), not much effort has gone in to tracking it down.

          We are still on Jenkins 1.580.1, but we may update to 1.609.2 as early as next week.

          Show
          pmv pmv added a comment - We've been using 2.4.0 since it came out, and we have seen a problem identical to what Daniel describes. For us it has been very rare. We've had hundreds of builds triggered by commit notifications (coincidentally, also the Stash hook), and have only had two or three missing parameters. Since for us it has been so infrequent (and also impossible to recreate), not much effort has gone in to tracking it down. We are still on Jenkins 1.580.1, but we may update to 1.609.2 as early as next week.
          Hide
          pmv pmv added a comment -

          We updated to 1.609.2 on 08/25, so we've been running with it about a week. We still have git client 1.18.0 and git 2.4.0, and have not seen an increase in the number of triggered builds missing parameters (in fact, I don't think we've seen any since the upgrade).

          Show
          pmv pmv added a comment - We updated to 1.609.2 on 08/25, so we've been running with it about a week. We still have git client 1.18.0 and git 2.4.0, and have not seen an increase in the number of triggered builds missing parameters (in fact, I don't think we've seen any since the upgrade).
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 161557 ] JNJira + In-Review [ 208519 ]

            People

            • Assignee:
              pmv pmv
              Reporter:
              jblanchard Jean Blanchard
            • Votes:
              5 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: