Open KalleOlaviNiemitalo opened 2 years ago
According to https://github.com/jenkinsci/atlassian-bitbucket-server-integration-plugin/pull/401#issuecomment-1613889355, 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.
It's not clear to me the difference between bitbucket-branch-source-plugin and atlassian-bitbucket-server-integration-plugin
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.
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?
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
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.
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.
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
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 https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/472#issuecomment-971452568.
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 https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/472#issuecomment-971452568.
Upstream changes