Automatic Merging When Builds Pass

[olockwood]

@Brandon Reppert Thank you for getting back to me.
It's a pity you're not currently planning to make this accessible on the public V2.0 API, but if  the internal API is programmatically usable, then we can live with that.  FYI our account is premium.

Unfortunately, I'm having trouble with using the internal API, so I'm now invoking your kind offer of help :-)

With the public API, we can make a call like:

curl -vvv \
-s -u '<username-redacted>:<password-redacted>' \
-X POST \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-binary '{"close_source_branch":true,"message":"myMessage","merge_strategy":"squash","newstatus":"fulfilled"}' \
'https://api.bitbucket.org/2.0/repositories/<organization>/<repo>/pullrequests/143/merge'

At the moment, the PR I'm targeting has been approved but the build is still running, so an error is returned as expected i.e.:

{"type": "error", "error": {"fields": {"merge_checks": ["1 successful build on last commit"]}, "message": "1 failed merge check"}}*

Which is exactly the scenario where we want to (programmatically!) be using the "post-build-merge" functionality.

Unsurprisingly - since like you said it's not exposed! - just tweaking the final part of the URL to "post-build-merge" fails on the public 2.0 API:

{"type": "error", "error": {"message": "Resource not found", "detail": "There is no API hosted at this URL.\n\nFor information about our API's, please refer to the documentation at: https://developer.atlassian.com/bitbucket/api/2/reference/"}}

Recording what happens in the browser when you click "Merge when builds pass" yields a new URL, and also a world of headers and cookies for the authentication side, which I won't copy here unless you want me to.

Trying to use the new URL but the existing API authentication approach:

curl -vvv \
-s -u '<username-redacted>:><password-redacted' \
-X POST \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-binary '{"close_source_branch":true,"message":"myMessage","merge_strategy":"squash","newstatus":"fulfilled"}' \
'https://bitbucket.org/\u0021api/internal/repositories/<organization>/<repo>/pullrequests/143/post-build-merge'

returns, amongst a lot of tracing noise, the following:

...
* Server auth using Basic with user '<username-redacted>'
...
Authorization: Basic <redacted>
...
* We are completely uploaded and fine
< HTTP/2 401
< content-security-policy-report-only: script-src 'unsafe-eval' 'strict-dynamic' 'unsafe-inline' 'self' http: https: https://d301sr5gafysq2.cloudfront.net; style-src 'self' 'unsafe-inline' https://aui-cdn.atlassian.com https://d301sr5gafysq2.cloudfront.net; report-uri https://web-security-reports.services.atlassian.com/csp-report/bb-website; default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: *; connect-src bitbucket.org *.bitbucket.org bb-inf.net *.bb-inf.net id.atlassian.com analytics.atlassian.com as.atlassian.com api-private.stg.atlassian.com api-private.atlassian.com cofs.staging.public.atl-paas.net cofs.prod.public.atl-paas.net intake.opbeat.com api.media.atlassian.com api.segment.io xid.statuspage.io xid.atlassian.com xid.sourcetreeapp.com bam.nr-data.net bam-cell.nr-data.net sentry.io bqlf8qjztdtr.statuspage.io https://d301sr5gafysq2.cloudfront.net; object-src about:; base-uri 'self'
< server: nginx
< vary: Accept-Language, Cookie
* Authentication problem. Ignoring this.
...

That looks to me like it's going to reject all responses that don't come from a whitelist of hosts.  Since my API invocation comes from my laptop at present (and will, when we get this working, come from our Jenkins server) I can't see how I could satisfy such a whitelist.

Perhaps you could advise me how to proceed?

If it would be easier to continue this conversation in another channel, let me know the best way to reach you (email / IM / whatever).

Many thanks for your time.

[Brandon Poe]

Hi @Brandon Reppert ,

In regards to your comment:

We're making the feature a premium feature, but that is being done only because the use case doesn't really make sense for non-premium users at this time (since non-premium users are always presented with the option to merge the PR regardless of build status).

I would disagree, I think it is a benefit to non-premium members. Here's our common scenario right now in the beta:

1. PR created.
2. PR build starts.
3. Approvals are provided. Build has not completed...

Since all the approvals we seek as a team have been provided but the build hasn't finished, we want to schedule the merge to occur after the build completes. If the build fails, the PR shouldn't automatically merge.

This is immensely helpful even if the other merge checks don't block merge on a non-premium account. Otherwise, we have to keep checking on a PR to see if the build has finished before merging.

[jeremy_lorino]

We're making the feature a premium feature, but that is being done only because the use case doesn't really make sense for non-premium users at this time (since non-premium users are always presented with the option to merge the PR regardless of build status).

@Brandon Reppert, I agree with @Brandon Poe. Just because a non-premium user does not have the ability to enforce any merge checks does not mean the user still wants to wait for a build to finish to merge.

I understand the need to have a premium tier; and I am not complaining about having to pay for premium. I do not believe your comment justifies premium.

Btw, pending merges is still a "Beta" feature according to Bitbucket labs yet has already been made a premium feature.

Even if your builds just take 1-2 minutes, we get it. Who wants to watch builds?

-- Brandon Reppert, Automatic Merging When Builds Pass

[Ming Gong]

This feature is no longer premium. Thank you for your feedback.

[olockwood]

@Ming Gongnice to know that the wider Bitbucket community will be able to use this.

@Brandon Reppert have you had a chance to consider my question about usage of the internal APIs?  or to reconsider actually making this a first-class citizen in the public APIs?

To give you a little more context of how we want to use this API:

• we have a part of our standard Jenkins pipeline which, for each of our components, periodically checks for updates to whitelisted dependencies (an updatebot-like capability)

• if such updates exist, a PR is automatically raised
• if the automated PR build passes, then a PR of this type is automatically approved
• we want to extend this such that these automated PRs are automatically merged.

We believe the "automatically merging when builds pass" feature is the right way to support the currently-missing functionality in the 4th bullet.

However, without being able to programatically access this API capability, we would either have to:

• continue relying on people manually merging these PRs, or manually clicking the "automatically merge when builds pass" button - in either case, a poor use of developer time, given we're talking about 100+ repos being checked 3 times a week!
• use the "merge pull request" API - much more complex than it sounds; given the implementation of the Bitbucket Jenkins plugin, the PR won't be marked as "build passed" until the very last point in the Jenkins job (as far as I can tell, you can't hook in after this operation!) so there'd have to be some triggering of a delayed-action "merge" task (e.g. a separate Jenkins job).

I guess I also don't see any argument against exposing this in the public APIs (given the public APIs already support the "merge pull request" API) and I can't imagine it being a whole lot of work to expose.  But then, I guess I also don't know your codebase :-)

I look forward to your thoughts.  Thanks.