+1. Alternatively, add a flag to the resource that marks it as 'transient' and so is not stored in the global config. Something like:

lock(name: 'my-resource', transient: true) {
   ...
}

Removing on release would not be safe. +1 for the transient parameter.

There should be a periodic background task looping on defined resources and removing those marked as transient and not used after a specific amount of time.

Also transient resources should not be displayed in the administration page as it does not make sense to configure them nor remove them.

Non-persistent "transient" locks would not be safe when used with Pipeline jobs, because Pipeline jobs running on other nodes can survive a restart of the Jenkins master. If the transient lock definitions aren't on disk, they won't be there when Jenkins master comes back.

I would bump this issue priority as the jenkins management UI (http://jenkinsurl/configure) becomes almost unusable after a bunch of non lockable resources. For me, the complete load takes 20 seconds, with 200 resources created. Our current workaround is shutting down jenkins, deleting the org.jenkins.plugins.lockableresources.LockableResourcesManager.xml and starting again

seanf witokondoria So... maybe there should be a separate page for locks instead of them being in global configure? (eg something similar to credentials) That way it wouldn't clutter the main configure page. Even on separate page, sounds like it would need to be paginated if there's so huge amounts of items.

It seems a combined approach would be valuable: split config (paginated) and self eraseable (non transient) locks.

IMHO, as a first baby step, a simple "delete all" button wuold suffice

+1 on this. We got so many locks and It's been such a pain to access the Jenkins config.