cloudbees-folder 6.708.ve61636eb_65a_5 was released.

This doesn't work quite perfectly yet, with Jenkins 2.319.3, Folders Plugin 6.708.ve61636eb_65a_5, and Bitbucket Branch Source Plugin 751.vda_24678a_f781. I configured the "Orphaned Item Strategy" settings of a Multibranch Pipeline project as follows:

• Abort builds: yes
• Discard old items: yes
  • Days to keep old items: empty
  • Max # of old items to keep: empty

I opened a pull request, and Jenkins created a job for the pull request and added build #1 to the queue. Because the agents were busy, the build did not start yet. I then merged the pull request, and Jenkins immediately disabled the pull request job. However, build #1 was still in the queue. Finally, I clicked "Scan Multibranch Pipeline Now". Jenkins then removed Build #1 from the queue and deleted the pull request job.

It would be better to cancel the build immediately when the job is orphaned and disabled, not only when the job is deleted. I don't know whether it's possible to implement that just in cloudbees-folder-plugin or whether it would need changes in branch-api-plugin or workflow-multibranch-plugin as well.

The current implementation is in the DefaultOrphanedItemStrategy.orphanedItems method, which logs "Evaluating orphaned items". I got that log entry to "Scan Multibranch Pipeline Log" but not to "Multibranch Pipeline Events". Perhaps that means the orphanedItems method is not called during the webhook event.

Right, there is a distinction between handling a single event (which disabled the job, marking the branch “dead”) and processing orphans which happens only during full branch indexing.

To abort builds more aggressively would I think require a change in branch-api. https://github.com/jenkinsci/branch-api-plugin/blob/b600837d9d8b07a296b805b71123b795a51aa518/src/main/java/jenkins/branch/MultiBranchProject.java#L1994 covers the case that a PR was reopened (for example), so we could extend this method to detect the converse case (live → dead) and copy the idiom from https://github.com/jenkinsci/cloudbees-folder-plugin/blob/e61636eb65a5e7f9f2e000853a6d8ad8fdef39e8/src/main/java/com/cloudbees/hudson/plugins/folder/computed/DefaultOrphanedItemStrategy.java#L260-L278 to abort any running builds and cancel any scheduled ones. reda_alaoui are you up for it?

Sorry jglick , too much things on my plate for now. So don’t hold your breath for it.

Just copying the idiom from DefaultOrphanedItemStrategy to MultiBranchProject seems a bit ugly because cloudbees-folder-plugin allows strategies other than DefaultOrphanedItemStrategy (see configure-details.jelly), although a search does not show any other classes that implement OrphanedItemStrategy.

kon indeed acc. to https://www.jenkins.io/doc/developer/extensions/cloudbees-folder/#orphaneditemstrategy that is the only known implementation. Anyway I think it should not matter since marking a branch dead already disables the branch project (no new builds possible) independently of orphaning. So it makes sense to me to have this code path also cancel/abort builds of that project.

If the build is doing some kind of deployment, then the user might want to let it run to the end, even if no new builds can be started. So if DefaultOrphanedItemStrategy.abortBuilds is false then I think the MultiBranchProject should not abort builds when it disables the job.

Oh I see your point. We would need to create another option on the MultiBranchProject (or OrganizationFolder) to let users opt into this behavior.

Perhaps it would suffice to define a JobProperty in workflow-job which would cancel/abort builds whenever the project is disabled, similar to JENKINS-43353. That is something you could control from a Jenkinsfile using properties in Scripted syntax, options in Declarative. (OK to be set near the start of build number 1, and you could conditionally enable it for example on PR builds but not on trunk builds that might be running deployments.)

I imagine one could have options at the pipeline level asking to abort builds, but override it with another options locally in the stage that does the deployment. Then the run would be OK to abort if it has not reached that stage yet, or has already completed it. That might be complex to implement though, especially with nested or parallel stages.

Yeah that sounds tricky to implement (and a complex UX too), though possible in principle.