-
Bug
-
Resolution: Unresolved
-
Minor
-
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
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.