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

git-plugin GIT_PREVIOUS_SUCCESSFUL_COMMIT incorrectly set

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      We're using Atlassian Bitbucket Jenkins Hook to notify Jenkins' job when a pull request is merged into develop branch. 

      When Bitbucket notifies of a new commit in develop to the Jenkins, it builds with CommitHookCause and builds the job in develop branch. When user manually starts the same job (at some other time), it's built with UserIdCause. 

      The following is GIT_COMMIT, GIT_PREVIOUS_SUCCESSFUL_COMMIT and cause from our build server. As you can see build 76 was started by user 1. It picked the last successful build commit from build #67, build 77 was trigger by commit into develop branch, but it picked the previous successful commit id from build #75. 

      We update the JIRA stories with version # built by our Jenkins' job and these anomalies in picking the previous-successful-commit..current-commit is causing duplicate updates.

      How can we configure Jenkins/git-plugin so it'll disregard the build cause when selecting the previously successful commit id?

       

      67:SCMTrigger (Polling based)
      67:GIT_COMMIT=70bbdc7efe052d8beb7902fbba03395d95c7a568
      67:GIT_PREVIOUS_SUCCESSFUL_COMMIT=3b578961d0865f45b4660bd7514c3fcb3f2768c3

      ...

      75:CommitHookCause=f6b0004af4520123ab8ed71540574cdf96fc01a9
      75:GIT_COMMIT=28cf5f0ef1b6de4b33aa60b6ec73e15bf62cf0dd
      75:GIT_PREVIOUS_SUCCESSFUL_COMMIT=28cf5f0ef1b6de4b33aa60b6ec73e15bf62cf0dd

      76:UserIdCause=user1
      76:GIT_COMMIT=f6b0004af4520123ab8ed71540574cdf96fc01a9
      76:GIT_PREVIOUS_SUCCESSFUL_COMMIT=70bbdc7efe052d8beb7902fbba03395d95c7a568

      77:CommitHookCause=d4e6ccba275b4682a823a3ce73c7368da9a50223
      77:GIT_COMMIT=d4e6ccba275b4682a823a3ce73c7368da9a50223
      77:GIT_PREVIOUS_SUCCESSFUL_COMMIT=28cf5f0ef1b6de4b33aa60b6ec73e15bf62cf0dd

      78:CommitHookCause=75407f7d73d83713109b54ea88d35f9d794e0939
      78:GIT_COMMIT=75407f7d73d83713109b54ea88d35f9d794e0939
      78:GIT_PREVIOUS_SUCCESSFUL_COMMIT=d4e6ccba275b4682a823a3ce73c7368da9a50223

      79:CommitHookCause=2a34ceb69cfefde4cc155a9c623075354d78bb1a
      79:GIT_COMMIT=2a34ceb69cfefde4cc155a9c623075354d78bb1a
      79:GIT_PREVIOUS_SUCCESSFUL_COMMIT=75407f7d73d83713109b54ea88d35f9d794e0939

      80:CommitHookCause=7f46b3de48cbbbd462701b83f95917be25d7e4bb
      80:GIT_COMMIT=7f46b3de48cbbbd462701b83f95917be25d7e4bb
      80:GIT_PREVIOUS_SUCCESSFUL_COMMIT=2a34ceb69cfefde4cc155a9c623075354d78bb1a

      81:CommitHookCause=d65e92608f97722859efcbc0bc6a5d8811464457
      81:GIT_COMMIT=d65e92608f97722859efcbc0bc6a5d8811464457
      81:GIT_PREVIOUS_SUCCESSFUL_COMMIT=7f46b3de48cbbbd462701b83f95917be25d7e4bb

      82:CommitHookCause=d65e92608f97722859efcbc0bc6a5d8811464457
      82:GIT_COMMIT=d65e92608f97722859efcbc0bc6a5d8811464457
      82:GIT_PREVIOUS_SUCCESSFUL_COMMIT=d65e92608f97722859efcbc0bc6a5d8811464457

      83:CommitHookCause=8317e80df2166b1c2295c9ea638155a157cd68e1
      83:GIT_COMMIT=8317e80df2166b1c2295c9ea638155a157cd68e1
      83:GIT_PREVIOUS_SUCCESSFUL_COMMIT=d65e92608f97722859efcbc0bc6a5d8811464457

      84:UserIdCause=user2
      84:GIT_COMMIT=37a622daba5dd76a45e345cd4bfb31750f2ede4f
      84:GIT_PREVIOUS_SUCCESSFUL_COMMIT=f6b0004af4520123ab8ed71540574cdf96fc01a9

      85:CommitHookCause=110fb22b88cd704985a7e26576ed25589908045b
      85:GIT_COMMIT=110fb22b88cd704985a7e26576ed25589908045b
      85:GIT_PREVIOUS_SUCCESSFUL_COMMIT=8317e80df2166b1c2295c9ea638155a157cd68e1

          [JENKINS-49636] git-plugin GIT_PREVIOUS_SUCCESSFUL_COMMIT incorrectly set

          Mark Waite added a comment -

          I assume from your description of multiple branches that you have a single job which is used to process multiple branches. Can you confirm that is the case?

          You might try an experiment using a job per branch, either by defining the specific jobs for each branch (if a few static branches are involved), or by using a multi-branch Pipeline with a Jenkinsfile in each branch. That seems like it might reduce the risk of confusion from branch changes.

          Mark Waite added a comment - I assume from your description of multiple branches that you have a single job which is used to process multiple branches. Can you confirm that is the case? You might try an experiment using a job per branch, either by defining the specific jobs for each branch (if a few static branches are involved), or by using a multi-branch Pipeline with a Jenkinsfile in each branch. That seems like it might reduce the risk of confusion from branch changes.

          markwaite, there is a single branch (develop) involved in this issue. When a PR in Bitbucket is merged into develop branch, a commit in develop branch is notified by Bitbucket to Jenkins which then builds the job from develop branch. This is what I referred to as CommitHookCause reason (from build.xml file).

          The issue occurs when the same job is built manually (Build # 76, 84 above) or based on the SCM polling (Build # 67).

          Vishal Agrawal added a comment - markwaite , there is a single branch (develop) involved in this issue. When a PR in Bitbucket is merged into develop branch, a commit in develop branch is notified by Bitbucket to Jenkins which then builds the job from develop branch. This is what I referred to as CommitHookCause reason (from build.xml file). The issue occurs when the same job is built manually (Build # 76, 84 above) or based on the SCM polling (Build # 67).

          Mark Waite added a comment -

          I don't know of any technique that will give you a different behavior than the current behavior.

          You could check if the Bitbucket webhook is passing additional parameters which are somehow influencing the plugin. I doubt that is what is happening, but there have been cases in the past where notifyCommit (a different form of notification) was honoring extra parameters and changing behavior as a result of those extra parameters. The webhooks might have a similar behavior.

          Mark Waite added a comment - I don't know of any technique that will give you a different behavior than the current behavior. You could check if the Bitbucket webhook is passing additional parameters which are somehow influencing the plugin. I doubt that is what is happening, but there have been cases in the past where notifyCommit (a different form of notification) was honoring extra parameters and changing behavior as a result of those extra parameters. The webhooks might have a similar behavior.

          Mihai Dinu added a comment -

          I have the exact same problem. vishal_agrawal, have you found a solution to it?

          Mihai Dinu added a comment - I have the exact same problem. vishal_agrawal , have you found a solution to it?

            Unassigned Unassigned
            vishal_agrawal Vishal Agrawal
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: