Gaspard Petit

Thanks for the review, I added back the `getResourcesWithLabel` with deprecation notice. I have been using this change in our production build Jenkins for over a month now and it's...

This was recently closed, but I'm also pushing for something similar in https://github.com/jenkinsci/lockable-resources-plugin/pull/305 with a `updateLock` step. Yes the `LockableResourcesManager` can be pulled into groovy, but using it directly is...

The ordering should now be resolved from #301 I am proposing PR #307 which I think would resolve this better. For example, the following pipeline works with this change: ```{groovy}...

I will be taking a look at this merge request. It's quite old and cannot easily be rebased so I'll submit it as a new branch based on this one.

Added a `build` filter and updated the description with it. This step would search for the current build's locks by default on a no-param `findLocks()` - but could still be...

> Hi, sorry for falling out of the loop, and thanks for your many PRs. One question to this one's description: > > > no argument to get all locks...

I agree, this should now be resolved with #301

The strategy you describe does sound interesting - stealing the lock for extraordinary measures (troubleshooting / healing) does seem like a good approach. I don't dislike the idea of testing...

Please hold - this change exacerbates the randomness of the lock ordering in the env variable; I will fix the current issue in master first and fix here after

Ok - fixed. This change would have caused regression against https://github.com/jenkinsci/lockable-resources-plugin/pull/301