jenkinsci / jenkinsci/lockable-resources-plugin
allow to link a lockable resource to a node
- Dominant language
- Java
- Stars
- 99
- Forks
- 205
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 8
Description
### What feature do you want to see added?
in our (mostly scripted) pipelines we need to use a single resource for which an agent can have between 0-4 of such resources.
Not each agent has such resource, some have 2, some 3, some 4. Typically a single resource is locked by one of the 'parallel' (sub-)builds of a pipeline. Agents typically have 6 execution slots. The resources are identified by a generic label.
The challenge for the pipeline job is to lock a free resource available through an online node where an execution slot is available.
In our current solution each resource has in its name the name of a node, and an index nr on that node; for example this could be "virtmachA_devres01", "virtmachA_devres02", .. where "virtmachA" is the name of an agent. Then, in the pipeline script, we request a lock with label "devres" (the label assigned to all the resources). Given the resource, we extract the agent name, and assign the particular code t that, using the "node(derived_agent) {...}".
This mostly works, unless the node is offline, or all execution slots are taken.
It is also annoying when the node has to be taken offline for maintenance; all resources for that agent need to be reserved manually.
My enhancement proposal is to extend the LockableResource with an (optional) 'agentname'. When defined:
* getting (locking) the resource can only be done when the agent is online and has a free slot
* the name of the agent is available through the resource.agent , thus allowing to schedule the workload on that agent.
This is maybe related to [#341](https://github.com/jenkinsci/lockable-resources-plugin/issues/341) and/or [#309](https://github.com/jenkinsci/lockable-resources-plugin/issues/309). However I think this proposal would need only a little work in the plugin, whereas it makes the pipeline scripts much easier and more robust.
### Upstream changes
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.