Three Jenkins Plugins for Bitbucket Pull Request Handling??

[Tim Black]

We have this one, this one, and this one. They all appear to be quite active and provide roughly the same functionality. Which one are you using, and can you speak to their differences in functionality and stability?

I'm using Bitbucket Server 6.10.1 and the Bitbucket Server Notifier plugin to post build statuses, and have "Minimum Successful Builds" Merge Checks set up, but the only builds it's checking here are the source branch build. This is useful, but of course what is most important in the PR Merge Check is the merged-to-target-branch build status.

So, I want to set up PR event triggers (using one of these 3 plugins), and then have my Jenkins pipeline conditionally merge to the specified target branch before building, and reporting status back to BBS.

So, in BBS, build statuses for commits associated with PR source branches will be these  merged-to-target-branch build statuses, and build status for commits outside the context of a PR will be for normal builds from the branch.

Now that you know what I'm trying to accomplish, which of these plugins would you recommend? I'd rather not waste more time than necessary on test driving each one. Thanks!

[Imran Khan]

Hi @Tim Black 

First of all, thanks for writing a detailed question and describing your use case. 

I'm not sure if you're aware that Bitbucket team built and supports a Jenkins plugin. You can see more details about it here - https://community.atlassian.com/t5/Bitbucket-articles/Atlassian-supported-Jenkins-integration-for-Bitbucket-Server/ba-p/1148326#M151

Currently, it triggers build on `push` event. We do have an open suggestion for https://issues.jenkins-ci.org/browse/JENKINS-60342 providing support for pull request events and this something we are exploring. 

Assuming, we do that here is how think workflow described you can work. (Just thinking out loud please don't assume it to be prescriptive)

• Pull request opens/updated tiggers build in Jenkins
• Jenkins checks out the source branch and target branch and merges it locally. If successful, proceeds with the other build steps
• Once build is complete, the build status is automatically sent to commit on the tip of the source branch. It will also show on the pull request. Perhaps you can modify the build name to indicate effective merge was built and tested instead of source branch. This name will show up when you click on the build status on a commit or pull request inside Bitbucket Server.

Let me know what you think? Also, happy to answer any other question that you may have.

Cheers,

Imran Khan

Product Manger - Bitbucket Server

[Tim Black]

@Imran Khan Thanks for your quick reply, and sorry for my late one. See my comment on this here.

I strongly suggest your team focus on a simpler, generalized solution to "handling PRs" that does not make so many assumptions about user /Dev workflow. You simply need to add basic support for enabling the various PR event webhooks from within a Jenkins pipeline, and ensure that the event payload is made available in the context of a triggered pipeline, so that people can do what they need in pipeline logic.

There's no need to do more than that at this time. You can hopefully get this core feature out to people sooner, unblocking them, and you won't be wasting time implementing things that a fraction of your plugin's users need.

For example, I see that you were proposing your plugin handle a pre-build merge above, and although yes that's useful, this is not what people are clamouring for primarily - they can do the pre-build merge, and the notification to bitbucket all in their pipeline code. What they really need is simply the basic PR event webhook support, so they can customize when their pipelines are triggered, and customize their pipeline's behavior based on runtime inspection of the event payload. With these core functionality, your plugin users can do anything in this realm.

The detail of "where do you report build status for a merged PR build" IMO is NOT something your plugin should try to solve now, and maybe ever. On PR creation/update/commit trigger, a pipeline job could easily detect what's going on, and perform the required merge in the workspace, then perhaps push that to a new, dedicated "PR staging branch" on the remote, then report the build status to that staging branch, whose lifetime would coincide with the lifetime of the PR. (This is an edit to what I was proposing in my OP -  reporting status of a merged build into the source branch commit on Bitbucket doesn't necessarily make sense as it's not the full truth.) This is IMO how it should work, at a high level, and these are not all pieces that your plugin needs to figure out or do. These details are also dependent on Bitbucket Server's feature roadmap, and I would hope that you would have more insight into this than any of us. I could imagine BBS adding some of these features in the future (managing Automatic creation of PR staging branches to hold build statuses for merge checks to use). In fact I believe they already have something similar to this, since a PR knows when the merge is in potential conflict. (How would it know unless it attempted to perform a merge? Where are those merges performed/maintained?)

BTW, FWIW, my team will be on BBS 7.6 LTS very soon. We're not yet using your bitbucket server integration plugin, and probably won't start until proper (basic) PR event webhook support is added. 

[Tim Black]

@Imran Khan thanks for your quick reply, and I apologize for my late one. I'm having to rewrite this now since my previous reply seems to have been deleted...

Re "Supporting PRs in atlassian-bitbucket-server-integration-plugin", the executive summary is this:

Please just focus on providing as soon as possible, the basic support for PR Event Webhooks, so that users can:

1. specify the various PR event triggers in their Pipelines
2. access the various PR event payloads from their Pipelines

where at a minimum "various PR event triggers" == opened, from_ref_updated, and merged.

With these, your users have all they need to implement modern CI behaviors using BB merge checks for quality gates, etc.. Please do not spend any time implementing the business logic of these CI behaviors in your plugin. Just release ASAP a new version of your plugin providing solid support for the above PR event webhooks, with proper pipeline access to the event payloads.

Only after appeasing the pipeline users should you start providing more sophisticated, in-built CI behaviors for your freestyle job users, whose requests IMO are muddying these waters. I wanted to emphasize this, since it appears to me from perusing your documentation/feature list that you are prioritizing the "shiny" freestyle job features, and I find this disappointing. Atlassian should be encouraging users to use pipeline instead of freestyle jobs anyway, esp since it simultaneously encourages more use of their SCM product (Bitbucket). 

FWIW, we're on Jenkins 2.222.3 and will soon be on Bitbucket Server 7.6, and although I have your plugin installed and connected to BBS, we are not using it. We're instead using git plugin 4.3.0 for all of our multibranch pipeline branch sources, and the bitbucket-server-notifier 1.20 to send build statuses to BBS (from pipeline code). Short of any announcement from you that you will release PR webhook support in the next few weeks, I will start using one of the alternatives I linked in the OP to provide this behavior, since your plugin doesn't provide anything beyond, or even in parity with, what this "plugin cocktail" provides at the moment.

That said.. to answer your question.. your description of how to implement the event-merge-build-notify sequence seems aligned with what I'm trying to accomplish. So if you're already down that road, and not going to release until it's done, so be it. Just know that I'm not willing to wait much longer for the basic webhook support that other plugins have provided for years.

[Imran Khan]

Hi @Tim Black ,

Thanks for your feedback. Supporting Pull requests is definitely on our roadmap. You can see more details here - https://issues.jenkins-ci.org/browse/JENKINS-60342. I think you have already commented on that issue.

To be clear, we are not prioritising Freestyle or pipelines. We want to provide choice to users to use their preferred project type. We have also added support for multi branch pipeline project, it didn't exist when the plugin was first made available. 

Thanks

Imran