jenkinsci / jenkinsci/lockable-resources-plugin

Update to v1309 changes LRM API and behavior

Open
#712 1 comment 3 reactions 0 assignees View on GitHub
Clarification needed Triage
Dominant language
Java
Stars
99
Forks
205
Avg merge
2d 13h
Merged PRs (30d)
8

Description

### Jenkins and plugins versions report

Environment


```text
Paste the output here
```

### What Operating System are you using (both controller, and any agents involved in the problem)?

Linux, Windows
Jenkins LTS 2.462.2
LR plugin v1309 .. v1315

### Reproduction steps

Using the plugin for a long time from custom JSL code by "directly" calling methods of the LockableResourceManager and LockableResource class instances. Recent changes in #673 removed the previously deprecated methods to `unlock()` the resources, dissociating them from a build, renaming them into `unlockResources()`. Technically, they were deprecated. But dropping them as a side casualty of other refactoring, unannounced, was not too friendly (I'd prefer complaining aliases that refer to new methods transparently) :)

Another related issue is that the newly named methods are not complete replacements: they now require a non-`null` value for a `build` object - specifically the one the resource is locked for, whereas previously passing a `null` allowed to just free it (e.g. passing the same resource between jobs and builds and not caring much who grabbed it first). To this effect, just noting that we can get the build object from the resource object itself, so it is a work-aroundable complication. Not sure why it had to happen in the first place though :)

```
def lrm = LockableResourcesManager.get()
def lr = lrm.fromName('testSUT-1')
lrm.unlockResources([lr], lr.getBuild())
```

Alternately, `lrm.unlockResources([lr])` without a second argument should also work - assuming all listed resources were locked by the same build (first resource's build is applied to everyone's unlocking).

### Expected Results

Old scripts using the plugin continue working, or the "catastrophic" change of API is loudly announced.

### Actual Results

* Old scripts fail to `unlock` resources due to missing methods
* The amended code is slightly more complex to provide the correct build object extracted from the same resource we are freeing

### Anything else?

For completeness, just in case someone else stumbles on this - the API change with PR #673 included the following removed methods in LockableResourcesManager.java :

* `getResourcesFromBuild()`

* `getReadOnlyResources()` - concept obsoleted, was a speedup for what is not a problem now => plain `getResources()` should suffice

* `freeResources()` - API change (`build` no longer `@Nullable`)

* `unlock()` - several (all?) method signatures removed; roughly replaced by new `unlockResources()` methods (tied to a `build` that may not be `null` now)

* `unlockNames()` - one method signature removed, another changed (`build` no longer `@Nullable`)

* added `unlockBuild()`

### Are you interested in contributing a fix?

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.