[JENKINS-47213] Opening a PR when the branch is still building with "Exclude branches that are also filed as PRs" leads to a never ending build in BitBucket

[nfalco79]

Bitbucket enhance its build status API with a refname (Cloud) and ref (Server) property to indicate the owner's git reference. This can be used as a sort of filter in case multiple build statuses have been associated with the same commit.
For example, this means that when browsing commits from the webpage, you will see all the build statuses associated with a commit (no scope); but, you should only see one when you land on the pull request webpage (scoped).

NOTE: At the time of implementation once a build status is created, it cannot be deleted via the API. If refname is set, it cannot be set to null. The property appears to participate in some way in the primary key of the build status, multiple build statuses with the same key but different refnames are allowed, especially in the use case the update APIs return an HTTP 500 error.
Available documentations:

• https://developer.atlassian.com/server/bitbucket/rest/v903/api-group-builds-and-deployments/#api-api-latest-projects-projectkey-repos-repositoryslug-commits-commitid-builds-post
• https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commit-statuses/#api-repositories-workspace-repo-slug-commit-commit-statuses-build-post
  does not explain precisly how this property should be valued. This force me to set the property to null in case of pull request, otherwise, the build status disappear from the webpage and branch restriction and merge conditions will not work.

Summary

Bitbucket Cloud

Considering only pages that show the build status, such as:

Steps:

1. Create a branch feature/xyz
2. Open a PR feature/xyz -> master
3. Merge PR

Pull Requests

In the specific "Pull Request" page now shows only the build status binded to the last commit in branch feature/xyz. Build status binded to the same commit in the target branch (example: master) is not listed.

You will see only 1 of 1 build passed.

There is some strange behavior on the "Pull Requests" listing page, let's say you filter by "Merged", the icon on the right in the tooltips shows all build states associated with the commit, BUT if you click on the bitbucket icon it only shows you the build state related to the commit (the same way it did on the specific pull request page above):

Before these changes, all build states associated with the commit were listed:

Commits

In the "Commits" page all build status (regardless the refname value) binded the commit are shown:

Branches

In the "Branches" page all build status (regardless the refname value) binded the commit are shown:

[nfalco79]

Installed in our production

[KalleOlaviNiemitalo]

Available documentations:

https://developer.atlassian.com/server/bitbucket/rest/v903/api-group-builds-and-deployments/#api-api-latest-projects-projectkey-repos-repositoryslug-commits-commitid-builds-post

That documentation is for POST /api/latest/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}/builds. As noted in #621, this plugin is still using the older POST /build-status/1.0/commits/{commitId}, which is instead documented at https://developer.atlassian.com/server/bitbucket/rest/v903/api-group-deprecated/#api-build-status-latest-commits-commitid-post (except the documentation has "latest" rather than "1.0").

bitbucket-branch-source-plugin/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/server/client/BitbucketServerAPIClient.java

Line 148 in 03e4c20

private static final String API_COMMIT_STATUS_PATH = "/rest/build-status/1.0/commits{/hash}";

bitbucket-branch-source-plugin/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/server/client/BitbucketServerAPIClient.java

Lines 516 to 519 in 03e4c20

	String url = UriTemplate.fromTemplate(API_COMMIT_STATUS_PATH)
	.set("hash", newStatus.getHash())
	.expand();
	postRequest(url, JsonParser.toJson(newStatus));

This old API is why the build status cannot be deleted, according to https://jira.atlassian.com/browse/BSERV-11393?focusedId=2784874&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2784874.

[nfalco79]

Good catch, I had forget to update the endpoint for the Server client.
Yes I had read comments in quite all the issues I found in github and in JIRA.
I saw also what atlassian-bitbucket-server-integration plugin does and no one describe how to value ref/refname property.
Since Cloud APIs does not provide a DELETE I can not implements any logic on top at all.

However, my hope would be to remove the Server logic and leave it handled by atlassian-bitbucket-server-integration. I am convinced that spending double the time to support both does not make much sense. It is exactly like having two different issues tracking (github/JIRA) for which I have to constantly jump here and there to gather informations, comments and so on...

[KalleOlaviNiemitalo]

The Bitbucket Cloud feature request [BCLOUD-15381] DELETE verb for the build status endpoint has six votes in almost seven years; it seems unlikely to be implemented any time soon.

[KalleOlaviNiemitalo]

@nfalco79, have you tested this with a pull request from a fork, on Bitbucket Server or Data Center? Or only with the source and target branches in the same a repository?

If I understand jenkinsci/atlassian-bitbucket-server-integration-plugin#401 (comment) correctly, the build status should then be posted to the repository that contains the source branch of the pull request. But it isn't clear to me whether this code does so.

[nfalco79]

Tested with source and target in the same repository.
Be attention that in case of pull request ref/refname is null otherwise the build status disappear from the web page. As test I also used a Cloud api to get build statuses for a specific pr.

In short any build that does not come from pr is valued with the name of the branch. In case of pr than null. This works for cloud, i hope the same for server.
If the same commit is the subject of two different pull request (different target) than you will see both build status in the pull request web page. I can not find any documentation about the expected value for pr.

[nfalco79]

If I understand jenkinsci/atlassian-bitbucket-server-integration-plugin#401 (comment) correctly, the build status should then be posted to the repository that contains the source branch of the pull request. But it isn't clear to me whether this code does so.

Let me see what they will do when they implement the feature (authentication, source reference and so on). No documentation, no gain, no party

[KalleOlaviNiemitalo]

Tested with source and target in the same repository.

Was that test with Bitbucket Cloud or with Bitbucket Data Center? (I assume you don't have access to Bitbucket Server because you asked me to test with that earlier.)

[nfalco79]

We have a Bitbucket Cloud account