REST API: how to check if a PR has conflict(s)

[Claudio Bizzotto]

As far as I know, the /pullrequests API (https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/pullrequests) doesn't offer a way of checking if a PR has conflicts.

I'm aware of the state attribute (MERGED, SUPERSEDED, DECLINED), but it won't help here, because all it shows is the status of the PR after an action has been taken.

I've also checked the pullrequests/{pull_request_id}/statuses endpoint, which also returns a state attribute, but again it only makes sense after some other thing has happened (a Pipelines build, for example):
SUCCESSFUL, FAILED, INPROGRESS, STOPPED. None of these help.

Ideally, as soon as a PR has been opened (independently of Pipelines or any further human interaction), some API endpoint should allow me to check if that PR contains conflicts or not.

Does anybody know of an indirect way of doing this? Preferably through an endpoint that does exist ;)

Thanks

[Deleted user]

One solution is to get a diff of the PR from the api and grep it for for instances of "<<<<<<<"  That will indicate if there is a conflict.

https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/pullrequests/%7Bpull_request_id%7D/diff

[John Langford]

That worked for me! Thank you!

[laszlo_BUZA_NNG]

At "Atlassian Bitbucket v8.9.1" server there could be diff, which does not display any conflict, but both files changed, so it has confict. Only the /merge the only way in this case which provide 100% (but it is very slow comparing other requests, 10-30s at first connection, after the first: 1-2s / request)

[Rafael Bradley]

In Bitbucket Server:

https://<hostname>/rest/api/1.0/projects/<project>/repos/<repo>/pull-requests/<pull-request-id>/merge

returns:

{"canMerge":false,"conflicted":true,"outcome":"CONFLICTED","vetoes":[...]}

[richbon75]

Great!  Thanks - Just a note for anyone coming across this later - GET from this URL if you just want to check the status.  A POST request to this endpoint will actually try to perform the merge, which may not be what you want.

https://docs.atlassian.com/bitbucket-server/rest/6.10.0/bitbucket-rest.html#idp287

[Alex Bondarev]

unfortunately there is not GET for ...`merge` for bitbucket cloud

https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/#api-repositories-workspace-repo-slug-pullrequests-pull-request-id-merge-post

[Aritra Chakraborty]

Hey,

So was in the same pinch, checked source code of the pull request html page and found out that there is indeed an endpoint for checking conflicts. 

And that is *Drumroll please*

https://bitbucket.org/api/1.0/repositories/<org_or_profile>/<repo_name>/pullrequests/<pull_request_id>/conflict-status

For example I got the pull request id from:

https://api.bitbucket.org/2.0/repositories/<org_or_profile>/<repo_name>/pullrequests/?fields=values.id

Then used that ID in the above conflict-check endpoint. 

Cheers! 

[Deleted user]

1.0 api will be deprecated at the end of the year. Is there a way to get the conflict-status on 2.0?

[Frank Lichtenheld]

For https://github.com/atlassian-api/atlassian-python-api I implemented logic on the basis of the pr/diffstat endpoint. While https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-diffstat-spec-get claims that a diffstat entry can have the status values "added, removed, modified, renamed" that is actually wrong. It can have additional values like "local deleted", "remote deleted", "merge conflict", "rename conflict", "rename/delete conflict", "subrepo conflict". Testing for those is much more reliable than grepping for "<<<<" in the diff.

See https://github.com/atlassian-api/atlassian-python-api/blob/master/atlassian/bitbucket/cloud/repositories/diffstat.py for the implementation.

Sadly it is not 100% reliable. AFAICT it breaks down when the PR is classified as "large PR". Like the web view the internal API view seems to reduce details in this case and the diffstats do not actually contain the conflicts anymore, just the original diff.

The web UI clearly still knows that the PR is conflicted but so far I couldn't find any source of that information in the public API.

[Julius Davies _bit-booster_com_]

My paid add-on, Bit-Booster - Rebase Squash Amend, makes that info available through its own internal API (servlet/bb_rb).

e.g., if you install my add-on, then this endpoint becomes available:

/plugins/servlet/bb_rb/projects/PROJECT_1/repos/rep_1/pull-requests/1

Look for the "isConflicted" key in the API response.

You can see the API whines about the add-on license being expired, but it never stops working.

Result:

{"enabled" : true,
"warn" : "Bit-Booster <a class='bbErr' target='_blank' href='http://localhost:7990/bitbucket/plugins/servlet/upm#manage/com.bit-booster.bb'>license expired</a>. 10 free rebases remain for today.",
"userHasWrite" : true,
"commitCount" : "1 commit",
"fromBranch" : "m",
"toBranch" : "basic_branching",
"tipMsg" : "b",
"isSquashed" : true,
"isRebased" : false,
"isConflicted" : false,
"blockMsg" : "",
"authors" : ["Administrator &lt;admin@example.com&gt;","Sylvie Davies &lt;sylvie@bit-booster.com&gt;"],
"defaultAuthor" : "Sylvie Davies &lt;sylvie@bit-booster.com&gt;",
"amendAuthor" : "Sylvie Davies &lt;sylvie@bit-booster.com&gt;",
"squashMsg" : "b",
"eof":"eof"}

But if you disable the Rebase, Squash, Amend functionality through Bit-Booster's config screen, then the API just returns this:

{"enabled" : false,
"warn" : "Bit-Booster <a class='bbErr' target='_blank' href='http://localhost:7990/bitbucket/plugins/servlet/upm#manage/com.bit-booster.bb'>license expired</a>. 10 free rebases remain for today.",
"eof":"eof"}

[Claudio Bizzotto]

Looks like it covers what we need. Does that addon work for Bitbucket Cloud as well?

[Julius Davies _bit-booster_com_]

Oh, sorry, Bitbucket Server (on-prem) only.   To implement this for cloud we'd need to store git repos for every customer, which is something we're not interested in doing at this time.

Here's the code (Java, using the JGit library) we use to calculate if the merge has a conflict or not:

ThreeWayMerger merger = MergeStrategy.RECURSIVE.newMerger(fileRepo, true);
ObjectId b1 = ObjectId.fromString(branch1);
ObjectId b2 = ObjectId.fromString(branch2);
boolean canMerge = merger.merge(b1, b2);

You might be able to suit that to your needs.  Note: that code creates a new tree-object in the git object database (the result of the merge), but since we never bother creating any pointers to the tree-object, subsequent "git gc" invocations clear it out.

[Claudio Bizzotto]

Thanks for your help, @Julius Davies _bit-booster_com_ (and for sharing your code)