Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Banjamino opened this issue Sep 27, 2023 · 6 comments
Labels

Comments

@Banjamino
Copy link

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

@Banjamino Banjamino added the bug label Sep 27, 2023
@delijo
Copy link

delijo commented Nov 23, 2023

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
Copy link

mdealer commented Feb 13, 2024

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
Copy link

ade commented May 21, 2024

@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
Copy link
Contributor

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
Copy link

mdealer commented May 21, 2024

@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
Copy link
Member

andham commented Aug 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants