Option 'disableConcurrentBuilds(abortPrevious: true)' works as not expected with Bitbucket notifications

[Banjamino]

Jenkins and plugins versions report

Environment

Jenkins: 2.401.3
OS: Linux - 5.10.130
Java: 11.0.19 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
---
cloudbees-bitbucket-branch-source:832.v43175a_425ea_6

What Operating System are you using (both controller, and any agents involved in the problem)?

Controller - Linux - 5.10.130
Windows agent - Windows Server 2019 Datacenter
Linux agent - Linux - 5.10.130

Reproduction steps

1. Enable options disableConcurrentBuilds(abortPrevious: true) in Jenkinsfile
2. Run a build.
3. Run a new build again while previous one is still in progress

Expected Results

The Official Jenkins documentation mentions that options { disableConcurrentBuilds(abortPrevious: true) } to abort the running one and start the new build, so it's expected start of a new build after previous one is aborted. In this case notification to Bitbucket about new build should have the status 'in pogress' and stays in this state while the build will be finished with some other status. In short, notification from previous build shouldn't overwrite a notification from a new build.

Actual Results

A new build starts before previous one is aborted and this behaviour affects notification to Bitbucket, becuase when the new build is started, the plugin 'bitbucket-branch-source-plugin' sents notification that the build in progess, then during some time previous build is aborted and overwrite current notification state to 'SUCCESS'.

Anything else?

No response

[delijo]

I am affected also.
For me, the critical issue here is the SUCCESS status send to Bitbucket for the Superseded build which allows users to merge their PR the status should be FAILED/ABORTED.
Not having the IN_PROGRESS build displayed properly is not great but no a big issue as long as the final build status is properly send at the end.

[mdealer]

I think I have encountered this. The issue is ambiguous implementation in Bitbucket Branch Source plugin by not using a unique enough key. See my fork.

In my opinion, build.getParent().getFullName(); does not cut it and should just use the URL of the build instead. The system should have multiple build awareness from the start or we will end up fighting Jenkins a good portion of the time.

[ade]

@mdealer Does your fix work well enough to be created as a PR? Affected by this issue as well and would like to see a fix.

[KalleOlaviNiemitalo]

If a build of a pull request fails a test because of some transient error, and it is then replayed and succeeds, I'd want the new build status to overwrite the original one so that the earlier error won't hold up the PR merge. If you use the URL of the build as the key, then how is this going to work?

[mdealer]

@mdealer Does your fix work well enough to be created as a PR? Affected by this issue as well and would like to see a fix.

Have been using it for over a year now, but you need to be aware of the below.

If a build of a pull request fails a test because of some transient error, and it is then replayed and succeeds, I'd want the new build status to overwrite the original one so that the earlier error won't hold up the PR merge. If you use the URL of the build as the key, then how is this going to work?

I find the current implementation unnecessarily ambiguous. Bitbucket keeps track of all the builds, but somehow various UI parts display just one build but then the PR shows multiple builds of the last commit. This is confusing.

The old plugin behavior is useful in some scenarios, but for Jenkins it is a fallacy - Jenkins runs builds in parallel and the status updates are not guaranteed to be in order. Both sides can be improved, but there are logical holes in the usability. Some configuration would be nice.

[andham]

I've now run into this as well. :-(
Looking into this I see that the new build-status API (#621) introduced a CANCELLED state in Bitbucket 8.16, see https://developer.atlassian.com/server/bitbucket/rest/v816/api-group-builds-and-deployments/#api-api-latest-projects-projectkey-repos-repositoryslug-commits-commitid-builds-post.

[nfalco79]

#906 handle correctly the abort result, so you interrupted build will result in failed or cancelled
With this plugin it is not possible to drive the behavior that new builds start after the previous build has finished. Each build is independent by managing the specification notification state. Also I would say that the new build could fail (network error, or failure to download the JDK....) before the previous one finishes.
If you choose to not send any notification status for abort build than it can work for this use can but could not when a real user stop the a build, status will stay in progress but you want failed/cancelled