Concern: is editing all resource fields via global config page safe?

[jimklimov]

One technically plausible way to edit lockable resource assignments is to change the strings in the Jenkins master global configuration page, in the section to list and otherwise edit these resources.

One discomforting thought nags at me however: does this mean that if an administrator takes some time to edit the global configuration (anything, not necessarily the resources) and then saves (or applies) it, would the (not-edited) string values from the resource list be re-applied to the actual resource objects? Or is there some tracking of "this field was not touched, do not re-apply"?

What I am concerned about is the possible re-assignment of resources that have been grabbed (or released) by builds and users between the time an administrator opened their $JENKINS_URL/configure page and the time they ultimately saved it... perhaps re-setting back the resource allocation statuses... is there something to worry in practice?

[offa]

I can confirm that editing resources in the global config may cause trouble. I ran into following scenario several times:

1. Builds using lockable resources run and some may wait for eg. blocked resources by other builds.
2. Someone removes unrelated locks – none of them used by active builds – in the global config and saves the change.
3. Multiple builds continue, though no resource is actually free.
4. 💥 Boom!

The time of edit seems not cause the problem here, as removing a few locks doesn't take much time.

is there something to worry in practice?

Yes, definitely!

[mPokornyETM]

That is the reason, why I want to remove the file 'reservedBy' from config page. More sense has a reason why user reserve the issue. Similar to node disconnect (or temporary disconnect) reason.