Use new build status API

[KalleOlaviNiemitalo]

What feature do you want to see added?

Use the new build status API that was added in Bitbucket Server 7.4. It differs from the old API in the following ways:

• The old API is at /rest/api/1.0/build-status/latest/commits/{commitId}, and the new API is at /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}/builds.

  The new {projectKey} and {repositorySlug} parameters would complicate fixing JENKINS-66620; see Send build completion notification for pull requests merged after build start #472 (comment).

• The user of the old API only needs to be LICENSED. The user of the new API needs REPO_READ permission.

• Build statuses that were added via the new API can be deleted later.

  The plugin could then be changed to delete build statuses of aborted builds, as suggested in Send build completion notification for pull requests merged after build start #472 (comment).

Upstream changes

• https://developer.atlassian.com/server/bitbucket/reference/api-changelog/#new-rich-build-status
• [BSERV-11393] Allow the ability to remove Build Status for a commit.
• [BSERV-13116] Update the "Updating build status for commits" with the information about new API
• [BSERV-13381] The legacy build-status end-point is not marked as deprecated in API, causing confusion

[KalleOlaviNiemitalo]

According to jenkinsci/atlassian-bitbucket-server-integration-plugin#401 (comment), the newer API also takes the Git ref name as a parameter, and Bitbucket uses that for deciding whether to show the build status in a pull request. Furthermore, if the source branch of a pull request is used as this ref, then the build status must be posted to the source repository of the pull request, not to the target repository.

[nfalco79]

It's not clear to me the difference between bitbucket-branch-source-plugin and atlassian-bitbucket-server-integration-plugin

[KalleOlaviNiemitalo]

bitbucket-branch-source-plugin supports both Bitbucket Data Center and Bitbucket Cloud.

atlassian-bitbucket-server-integration-plugin does not support Bitbucket Cloud, but has been more proactive in supporting new features of Bitbucket Data Center. Its support for Jenkins APIs has been gradually catching up with bitbucket-branch-source-plugin.

[nfalco79]

bitbucket-branch-source-plugin supports both Bitbucket Data Center and Bitbucket Cloud.

atlassian-bitbucket-server-integration-plugin does not support Bitbucket Cloud, but has been more proactive in supporting new features of Bitbucket Data Center. Its support for Jenkins APIs has been gradually catching up with bitbucket-branch-source-plugin.

ok, I would just a confirm. Pardon at this point a question is raising in my mind...why we are spending a double effort to provide the same feature?

[nfalco79]

I can confirm the same behaviour of the API for Bitbucket Cloud:
PUT https://bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses/build/{key}
when set refname to refs/heads/master or any other non pull request branch like refs/heads/support/5.1.x the build status will disappear from pull request builds.
But, contrary to what I thought, for the build status of the pull request if I set (for example) the refname to 'refs/heads/feature/test' or 'refs/pulls/731', it will disappear from the pull request page.
I believe that the build statuses are visible only if refname is set to null. Furthermore, once set, it is not possible to set the refname back to null. This is a problem because if you set it wrong, there is no API to delete a build status.

Anyway this is the way I would follow to resolve this kind of bug

[nfalco79]

Currently the API in use is a POST https://bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses/build
I thought that the id was only the "key" attribute for a build status, but from the tests I did the id seems to be the "key"/"refname" pair because if I change any other attribute like description, url, name, etc etc the build status always remains the one for the commit hash, while if I change the value of the refname it creates a new build status. This also means the refname can no longer be set to null, unless create a new build status entry.

[KalleOlaviNiemitalo]

Currently the API in use is a POST https://bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses/build

This issue is for Bitbucket Server and Data Center, not Bitbucket Cloud.

[nfalco79]

The same issue affect also bitbucket cloud. The API has the same behaviour, branch jobs attach build status to a commit without a refname will cause in PR page show twice builds. Will applied the same solution both for Server (deprecated), Data Center and Cloud

[KalleOlaviNiemitalo]

This was implemented in commit 7ac886d, which seems to correspond to #930.

[spriya757]

Hi @KalleOlaviNiemitalo

I'm from Bitbucket Cloud team. One of our customers reported the same issue as this - #621 (comment). Using refname as "refs/heads/master" won't show the Jenkins build in the pull request page. The correct format/usage of the field refname is just to use "master" instead of "refs/heads/master".

Can you please update the same in your plugin?
Having a null value works too.

Thank you!!

[nfalco79]

Hi @KalleOlaviNiemitalo

I'm from Bitbucket Cloud team. One of our customers reported the same issue as this - #621 (comment). Using refname as "refs/heads/master" won't show the Jenkins build in the pull request page. The correct format/usage of the field refname is just to use "master" instead of "refs/heads/master".

Can you please update the same in your plugin? Having a null value works too.

Thank you!!

Is there a documentation that we can follow to setup the ref attribute for bitbucket cloud ?

I used refs/heads/ because it was documented in the Bitbucket server documentation and I assumed (hoped) that the same would apply to the cloud.