Using the lock as an extension for `disableConcurrentBuilds(abortPrevious: true)`
What feature do you want to see added?
Afaict the current usages of lock is to prevent subsequent runs from entering the current code section. However, I am trying to find a way to do the opposite, namely cancel any current jobs that have the given lock. I couldn't find a way do that even when considering skipIfLocked.
The workflow to support would be something like this:
-
JobAcalculates the label for the lock -
JobAcreates the lock and starts doing a long job -
JobBis triggered and it calculates the same label for the lock -
JobBruns a snippet and cancelsJobA, triggering a cleanup job for its current long job -
JobBprocedes to create the lock and stats doing its long job
What I am trying to support here that disableConcurrentBuilds(abortPrevious: true) is to cancel the current running jobs that have a specific set of parameters, while the option disableConcurrentBuilds seems like it would cancel any job in the current piepline.
Upstream changes
No response
Are you interested in contributing this feature?
No response
@LecrisUT are you similar with groovy shared scripts in the Jenkins pipeline. In that case it might be possible to do it in groovy as well. But it will be tricky. How important it is for you. Maybe I can provide some 'official' plugin solution for that. Maybe you can particapte too ;-)
@LecrisUT are you similar with groovy shared scripts in the Jenkins pipeline. In that case it might be possible to do it in groovy as well. But it will be tricky.
Can't say I am familiar with these, I would not be able to hack my way around this.
How important it is for you. Maybe I can provide some 'official' plugin solution for that.
Pretty much blocker for resolving an issue. We are trying to resolve it with a redis server though.
Maybe you can particapte too ;-)
Unfortunately we are in a process of migrating the CI, and resolving this issue is mostly a life-support issue, so I can't participate for the long-term