Groovy Expression in Free-Flow jobs is either broken or not documented enough to be useable. about lockable-resources-plugin HOT 6 CLOSED

@f-steff I think you confused resources and labels. A resource is always the one thing that is locked, it exists once and has an unique name (if we take the hardware example, this may be office_printer_14). Every resource can have multiple labels (the printer could be labeled dot-matrix-printer, in-office-printer, a4-printer, etc.). All resources with the same label form a "pool", so if you try to lock 1x a4-printer, you might get a random resource which has the label a4-printer - if all resources with the label a4-printer are in use, your job waits until one is available.

from lockable-resources-plugin.

Hi, looking at this today for my setup - it seems that when the Lockable Resources plugin sees a queued job with enabled groovy script, it calls the script for each single definition of a lockable resource, independently. It is up to your script to match the strings in resourceName and resourceLabel, maybe resourceDescription too.

The groovy script ultimately returns true or false, so the plugin has an array of accepted resourceName's - and then picks one (assuming you've required "1" as the amount in settings) to lock and return into the build environment in the variable name you've set up for the job. If none of the picked resources are currently available, the job stays in queue and the loop repeats after a few seconds.

Thanks to your write-up, as well as https://github.com/jenkinsci/lockable-resources-plugin/blob/master/src/main/resources/org/jenkins/plugins/lockableresources/RequiredResourcesProperty/help-resourceMatchScript.html for helping figure this out. The println routine and jenkins.log were also very helpful ;)

Now, one more quest for me remains - I want this logic to interact with build arguments of the queued job, and those seem to not be available in the context of this groovy script :( UPDATE: Hopefully PR #72 will address this issue of mine.

from lockable-resources-plugin.

Hi @jimklimov,
Thank you for your investigations and findings. Not least the comments on issue #73 which seems really interesting.

I'll see if I can find time to work in it this week, and if successful will update the Jenkins Wiki with simple examples.

If you have discovered more valuable info, please let me know.

Thanks.

from lockable-resources-plugin.

@jimklimov
To access the build-parameters passed to the job, you can use:
import hudson.model.*
def JobParameter = System.getenv("YOUR_PARAMETER_PASSED_TO_THE_SCRIPT")

I tested your hypothesis, by dumping all variables available to the Groovy script:
println "Lockable Resource Groovy Script Start"
this.binding.variables.each {k,v -> println "$k = $v"}
println "Lockable Resource Groovy Script End"
println ""
return false

This resulted in the following output repeated over and over when the job attempted to start:

Lockable Lockable Resource Groovy Script Start
resourceLabels = [Node2A, Node2B, Node2C]
resourceDescription = This is a TEST resource.
resourceName = Node2
Lockable Resource Groovy Script End

Lockable Lockable Resource Groovy Script Start
resourceLabels = [Node1A, Node1B, Node1C]
resourceDescription = This is a TEST resource.
resourceName = Node1
Lockable Resource Groovy Script End

So it's possible to match resourceName and resourceLabels, and it's possible to return true or false.

If true is returned, all Names and Labels are locked - unless the Number of resources to request value is not a positive number, in which case the job runs without checking the resources.

So effectively it's possible to use this as a simple semaphore, based on the resourceName, since using resourceLabels doesn't add any value.

It would be nice if it was possible to return true/false to select on the resourceName level or a resourceLabels list to specify the labels this jobs selected to have locked.

from lockable-resources-plugin.

Note that by now my PR is merged. When I was doing similar experiments, I did not see build args as envvars in the evaluated lockable-resources groovy script. It is also quite possible I botched the experiment somehow, not being proficient in Java ;) But I did find "teh codez" on the net to print out all envvars seen by the script's context - and build args were not there for me.

I am not sure I got all your further elaboration about resource matching, but note that locking regards each individual resourceName which often marks some limited (and unshareable) physical resource. It is quite valid for different instances to have same labels (maybe part of different larger label sets) so you can declare "give me any one of these, exclusively while this job runs"!

from lockable-resources-plugin.

Hi again @jimklimov, Sorry for my late delay.

It's great that your PR is merged, but I wonder when it will be released in the plugin?

About my further elaborations, it was based on my understanding of the plugin, which again was based on the old online (and in plugin) help text. As far as I remember, it stated that one resource (name) could have several "sub-resources" (labels), and that you could choose to lock on the all (name), or a few specific, leaving the others available for other jobs.

To me it made sense like this:
Resource name: Transmitters
Resource labels: Transmitter1, Transmitter2, Transmitter3, Transmitter4
#of resources requested: n

So with the above setup, I could have two ways to lock resources.

1. Specify "Transmitters" as Resource name: I would end up getting the amount requested (n), out of the four available transmitters in the pool. If I requested 2, another job could get the other two.

2. Specify the labels to get some specific resources out of the pool.

As I understand the implementation as is is now, the usage of name's or label's doesn't make any difference - as it locks the same resource. And I even less understand the usage of the the amount of resources to lock... - dont you always get all of them?

from lockable-resources-plugin.