Duplicate Notifications On Pull Request

[mandrachek]

If I merge into my development branch, then create a pull request from development branch to staging branch, I wind up with double builds from my development branch. Just creating the pull request seems to kick it off a build from development.

From the log below, it looks like my commit at 8:25:08 kicks off a build of 2bacbcf154d976678ff508e66d2eec2678365c81.

At 8:28:47, which is when my pull request was created, another build of 2bacbcf154d976678ff508e66d2eec2678365c81 was scheduled.

And then at 8:32:16, with I approved the merge, the staging build kicks off for the merge commit, 1901f36b185d3174f1d7aa75335f9df856c8a5c0.

I've got 2 different jobs, same repo, 1 setup to run from the staging branch, one setup to run from the development branch.

This is on Stash v3.11.1, using Stash Webhook to Jenkins 2.7.1

Log:

Oct 15, 2015 8:25:08 PM FINE hudson.plugins.git.GitStatus
Received notification for uri = https://stash/scm/app/android.git ; sha1 = 2bacbcf154d976678ff508e66d2eec2678365c81 ; branches = [development]
Oct 15, 2015 8:25:08 PM FINE hudson.plugins.git.GitStatus
Branch Spec development matches modified branch development for App Android Development. 
Oct 15, 2015 8:25:08 PM INFO hudson.plugins.git.GitStatus$JenkinsAbstractProjectListener onNotifyCommit
Scheduling App Android Development to build commit 2bacbcf154d976678ff508e66d2eec2678365c81
Oct 15, 2015 8:28:47 PM FINE hudson.plugins.git.GitStatus
Received notification for uri = https://stash/scm/app/android.git ; sha1 = 2bacbcf154d976678ff508e66d2eec2678365c81 ; branches = [development]
Oct 15, 2015 8:28:47 PM FINE hudson.plugins.git.GitStatus
Branch Spec development matches modified branch development for App Android Development. 
Oct 15, 2015 8:28:47 PM INFO hudson.plugins.git.GitStatus$JenkinsAbstractProjectListener onNotifyCommit
Scheduling App Android Development to build commit 2bacbcf154d976678ff508e66d2eec2678365c81
Oct 15, 2015 8:32:16 PM FINE hudson.plugins.git.GitStatus
Received notification for uri = https://stash/scm/app/android.git ; sha1 = 1901f36b185d3174f1d7aa75335f9df856c8a5c0 ; branches = [staging]
Oct 15, 2015 8:32:16 PM FINE hudson.plugins.git.GitStatus
Branch Spec staging matches modified branch staging for App Android Staging. 
Oct 15, 2015 8:32:16 PM INFO hudson.plugins.git.GitStatus$JenkinsAbstractProjectListener onNotifyCommit
Scheduling App Android Staging to build commit 1901f36b185d3174f1d7aa75335f9df856c8a5c0

[mandrachek]

Would it be possible to check to see if that commit on the source branch has been marked as a build success in stash, and if so, skip requesting the build against the source branch?

[j5awry]

Or, alternatively, create a way to turn off doing builds when initiating a Pull Request?

Generally speaking, we're seeing this happen a lot--a team makes a commit to a Feature branch. Build runs, passes, so they do a Pull Request. This kicks off another build of the Feature branch. This is usually something in the order of 5-6 minutes apart (sometimes less, occasionally more).

it'd be nice for teams whose flow requires a successful build before a PR to be able to disable "build on PR" for branches.

[yleviel]

We're seeing the same issue... you make some change, everything seems ok, so you open a PR only to see that it's running the same test again. This creates scenarios where pushing to the origin followed by an immediate opening of the PR causes two sequential builds. At minimum, we should be allowed to choose to only call the hook on update instead of a PR open or disable the feature altogether.

[matthewbarr]

One option is to limit the branches to build, in Jenkins.

[mandrachek]

Turning of any my development, staging, and master branches really isn't an option. This plugin just really doesn't behave in a sane fashion, from what I can see. To go from feature branch -> development branch -> staging branch -> master branch produces WAY too many builds. :( We haven't yet found a good solution for this with jenkins. Thinking about trying bamboo.

[sriramgd]

+1. We use the Jenkins webhook, and find it very useful. This would be a useful feature for us, we have the same issue with feature branches and duplicate builds. We spin up a feature build environment and deploy to it whenever a new PR is created. If the user edits the PR to say add a user, it causes a duplicate build which causes failures due to locking in our builds. We typically re-trigger the build after the failure. It would be great if the feature @mandrachek suggested could be added, possibly with a configurable:

• Trigger build on PR creation - on/off
• Trigger build on PR edit authors - on/off
• Trigger build on PR new commit - on/off

Thanks

[tiberiomoliveira]

+1 I'm facing the same problem as @mandrachek, Jenkins receives two notifications, one for the commit and one for the merged code. It would be nice to set the webhook to notifies only on commits or only on merges. Thanks.

[papag00se]

+1 I also have this issue. A build is triggered for the PR being created AND a build is triggered on merge. I don't need two builds.

[papag00se]

I threw together a temporary fix for this. I used Wireshark to sniff the traffic between BitBucket and Jenkins. I saw the URL and headers that each used when handling these notifications. Then I created a proxy web in C# and told BitBucket to report to that instead. In that proxy web I use the BitBucket API to go see if the sha passed is actually part of the fromRef in a pull request. If it is I ignore it (for now - later I will use it to trigger PR builds). If it's not part of a PR then I am assuming it is an actual merge. So it then calls the original Jenkins URL. The process sounds more difficult than it actually was.

The URL BitBucket sends: http://<JENKINS_BASE>/git/notifyCommit?url=<REPO_URL>&branches=<BRANCH_NAME>&sha1=<COMMIT_SHA>

BitBucket expects back a content body: Scheduled <JENKINS_BUILD_NAME>\r\n

...and a header: (value is a new line delimited list of Jenkins Job URLs) Triggered: http://<JENKINS_BASE>/job/My%20Jenkins%20Job%20Name/\r\n

The BitBucket API call: GET http://<BITBUCKET_BASE>/rest/api/1.0/projects/<PROJECT_KEY>/repos/<REPO_SLUG>/pull-requests/

You are looking for the BRANCH_NAME and COMMIT_SHA value above in: {"values": [{"fromRef":{"displayId": <BRANCH_NAME>, "latestCommit": <COMMIT_SHA>}}]}

It would be so much easier if there were options as @sriramgd mentioned above.

[mfoody]

Has anyone found a solution to this?

[cyyeong]

Will this be fixed or enhanced?