-
Notifications
You must be signed in to change notification settings - Fork 201
allow to link a lockable resource to a node #455
Copy link
Copy link
Open
Labels
Good for Groovy shared libraryIt might be done in groovy shared library much more easier than hereIt might be done in groovy shared library much more easier than hereTriageNeed to clarify, remove, close or whatever to clean up open issues / PRsNeed to clarify, remove, close or whatever to clean up open issues / PRslock Jenkins nodeLockable resource interactions with Jenkins nodes.Lockable resource interactions with Jenkins nodes.
Metadata
Metadata
Assignees
Labels
Good for Groovy shared libraryIt might be done in groovy shared library much more easier than hereIt might be done in groovy shared library much more easier than hereTriageNeed to clarify, remove, close or whatever to clean up open issues / PRsNeed to clarify, remove, close or whatever to clean up open issues / PRslock Jenkins nodeLockable resource interactions with Jenkins nodes.Lockable resource interactions with Jenkins nodes.
Type
Fields
Give feedbackNo fields configured for Enhancement.
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:
This is maybe related to #341 and/or #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