mPokornyETM
commented
1 year ago This is exact the reason, why I created the #341 I think all of the magic, what you explain can be done in groovy as well. An helper in our shared-library will be great.
import org.jenkins.plugins.lockableresources.LockableResourcesManager as LRM
@NonCPS
def getResource(String name)
{
def allr = LRM.get().getResources();
for(int i = 0; i < allr.size(); i++)
{
if ( allr[i] && (allr[i].getName() == name) )
return allr[i];
}
return null;
}
def filteredNodes = [];
int expectedCount = 4;
// the best way to synchronize code between jobs is to use lockable-resources ;-)
lock('get-nodes') {
jenkins.model.Jenkins.instance.computers.each { c ->
if (filteredNodes.size() == expectedCount)
return;
if (c == null || c.node == null) {
return; // sometimes (no idea why) c.node is null
}
if (!c.isOnline()) {
// is offline ignore it
return;
}
String nodeName = c.node.selfLabel.name;
der resource = getResource(nodeName);
if (resource == null) {
// resources does not exist, create it
return;
}
if (resource.isLocked() || resource.isQueued() || resource.isReserved()) {
// occupated
return;
}
filteredNodes.push(nodeName);;
}
}
echo 'my free and online nodes: ' + filteredNodes
ps: I type it here just so, without syntax check or what ever, But I thing as idea it shall helps
monger39
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