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

notifyCommit doesn't spawn a build unless a job on another branch is already running that build

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I may not be able to provide a lot of information, but here's what I know.

      I have a build job that is designed to build master or pull request branches, depending on a custom branch parameter. I also clone the job for each current release branch we are working on.  The job specifies a "Pipeline script from SCM" and specifies the git repo we are using, and the branch (master or release).

      We use BitBucket, and the "Bitbucket Server Webhook to Jenkins", along with the "Pull Request Notifier" in BitBucket.  When we create pull requests, the PRN works fine and causes Jenkins to run the job on the pull request branch.

      When we merge a PR to master, or a release branch, most of the time it does not spawn a build of the master or release branch. Today I may have discovered the circumstances that result in it spawning a build on a merge.

      If no build is currently running, the merge to master does not spawn a build.

      If a build of the master branch is currently running, the merge to master does not spawn a build.

      However, if there is currently a build running of a pull request branch, the merge to master DOES spawn a build (makes it pending) of the master branch.

      I've tested this several times today, although only with a single pull request branch. I would find it hard to believe it matters which pull request branch it is.

      In our testing, we haven't really been merging PRs to master each time, we simply recorded the "notifyCommit" URL and we've been manually running it with "curl".

      So, for instance, we would run something like the following:

       

      curl -fsSL -D - -g 'http://...:17723/jenkins/git/notifyCommit?url=ssh://git@...:7999/st_usl/oce_usl.git&branches=master&sha1=eb4326eb8c48ec4793abe5330e9dce199d6a5dc0'
      

      I've reused this exact command line for my tests. If a build is not running, or a build of master is running, I get the following output:

       

       

      No git jobs using repository: ssh://...:7999/st_usl/oce_usl.git and branches: master
      No Git consumers using SCM API plugin for: ssh://git@...:7999/st_usl/oce_usl.git
      

       

      If, however, there is a current build with job on a pull request branch, it gives me this (where "foo" is my job name):

       

      Scheduled foo
      No Git consumers using SCM API plugin for: ssh://git@...:7999/st_usl/oce_usl.git
      

      And this results in a job being started.

      Note that we're using a somewhat older version of Jenkins.  We've decided to upgrade to
      2.56.2, but we have no certainty this problem will go away in that version.
       
      I'm not the admin for the server, but if more information is needed, the admin can either comment on this, or I can get required information from him.
       

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          I think that your notifyCommit call relies on passing arguments (branch and sha1) to the notifyCommit URL without authentication. That resulted in SECURITY-275 and git plugin release 2.5.0 with commit 5b57aa to resolve that security problem.

          If you must pass branch and sha1 as arguments, instructions are available in that commit message that describe how you can configure Jenkins to allow only the branch and sha1 arguments, rather than the previously unlimited arguments which were allowed prior to git plugin 2.5.0.

          The original intent of the notifyCommit hook (as described in "Polling must die") was to invite Jenkins to check the monitored repository for any and all changes. It was not intended as a way to pass arbitrary arguments into Jenkins from an anonymous user. Unfortunately, the git plugin made the mistake of widening the use beyond what was originally intended for notifyCommit. That created a security issue which was resolved in git plugin 2.5.0 and later.

          You did not mention the git plugin version where you were seeing the problem. Can you confirm that the installation which did not have the problem was prior to git plugin 2.5.0 and the installation which shows the problem is git plugin 2.5.0 or later?

          Show
          markewaite Mark Waite added a comment - - edited I think that your notifyCommit call relies on passing arguments (branch and sha1) to the notifyCommit URL without authentication. That resulted in SECURITY-275 and git plugin release 2.5.0 with commit 5b57aa to resolve that security problem. If you must pass branch and sha1 as arguments, instructions are available in that commit message that describe how you can configure Jenkins to allow only the branch and sha1 arguments, rather than the previously unlimited arguments which were allowed prior to git plugin 2.5.0. The original intent of the notifyCommit hook (as described in "Polling must die") was to invite Jenkins to check the monitored repository for any and all changes. It was not intended as a way to pass arbitrary arguments into Jenkins from an anonymous user. Unfortunately, the git plugin made the mistake of widening the use beyond what was originally intended for notifyCommit. That created a security issue which was resolved in git plugin 2.5.0 and later. You did not mention the git plugin version where you were seeing the problem. Can you confirm that the installation which did not have the problem was prior to git plugin 2.5.0 and the installation which shows the problem is git plugin 2.5.0 or later?

            People

            • Assignee:
              Unassigned
              Reporter:
              dkarr David Karr
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: