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

Git SCM polling is not triggered from a push notification with 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-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 added a comment - Fixed in pull-request https://github.com/jenkinsci/git-plugin/pull/309
          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

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

          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.

          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

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

          Fix included in git plugin 2.4.0 released 18 July 2015

          markewaite Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015

          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.

          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.

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

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

          morr 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?

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

          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.

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

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

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

          People

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

            Dates

              Created:
              Updated:
              Resolved: