This would be valuable for non-GitHub branch sources as well. Implementation strategies were discussed in JENKINS-60677, which was however resolved without this feature.

If this were implemented in the Branch API plugin rather than the GitHub Branch Source plugin, so that it would apply to Bitbucket Branch Source too, then there would be a complication with the Bitbucket Server 7.7 feature that automatically declines inactive pull requests. Bitbucket Server does not post any warning to the pull request before automatically declining it. Pull requests sometimes remain inactive for several weeks even though they are still needed. When Bitbucket Server automatically declines such a pull request, we reopen it right away. It would be unfortunate if the automatic decline immediately caused Jenkins to discard the build history and reset the build number.

Perhaps Jenkins should distinguish between merged, declined, and deleted pull requests. If a pull request is merged or deleted, then it cannot be reopened (although a new pull request can be created from the same branch), and it's OK to delete the corresponding job from Jenkins immediately. If a pull request is declined, then it can still be reopened, and the corresponding job should be preserved for a few days.

Or perhaps I should ask Atlassian to make Bitbucket Server post a comment to each pull request that is about to be automatically declined.

Hi all,

Could it be possible to have a status about this problem. It is indeed quite annoying to have to manually cleanup workspaces.

Best Regards

I think Jenkins could be changed to automatically delete workspaces even while the branch job still exists in the multibranch project, if it has disabled the job because the branch no longer exists in SCM. So it would still keep the runs (including logs, test results, and artifacts). Perhaps that feature could fit in the existing Distributed Workspace Clean plugin.