-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
lockable-resources 1.11
https://issues.jenkins-ci.org/browse/JENKINS-34268 was closed implementing the possibility to lock a resources using a label in pipelines.
But there is no syntax for knowing what the actually locked resource name is when using a pipeline and locking on a label.
Specifically the proposed syntax from https://github.com/jenkinsci/lockable-resources-plugin/pull/36 : ", variable: 'MY_VAR'" is missing.
Our use case is that we wan't to specify a label containing node names for legacy builders that can't run the slave.jar (java7) anymore. We want to lock a resource (host name) from the label and then ssh to that machine and execute some build steps. This works with the FreestyleJob functionality of "Reserved resources variable name".
Solution
It is now possible to access the locked resource via an configurable environment variable.
lock(label: 'some_resource', variable: 'MY_VAR') { echo env.MY_VAR }
- is related to
-
JENKINS-50176 Locked resources using the variable parameter do not get reset to the variable once released to another requester and only appear as null on subsequent locks
-
- Resolved
-
- links to
[JENKINS-40997] Add way to get locked resource name in pipeline
Staffan Forsell
created issue -
Hi i tried to implement this with https://github.com/jenkinsci/lockable-resources-plugin/pull/50
Maybe someone can have a look?
| Assignee | New: Julian F. [ f_julian ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Description |
Original:
https://issues.jenkins-ci.org/browse/JENKINS-34268 was closed implementing the possibility to lock a resources using a label in pipelines. But there is no syntax for knowing what the actually locked resource name is when using a pipeline and locking on a label. Specifically the proposed syntax from https://github.com/jenkinsci/lockable-resources-plugin/pull/36 : ", variable: 'MY_VAR'" is missing. Our use case is that we wan't to specify a label containing node names for legacy builders that can't run the slave.jar (java7) anymore. We wan't to lock a resource (host name) from the label and then ssh to that machine and execute some build steps. This works with the FreestyleJob functionality of "Reserved resources variable name". |
New:
https://issues.jenkins-ci.org/browse/JENKINS-34268 was closed implementing the possibility to lock a resources using a label in pipelines. But there is no syntax for knowing what the actually locked resource name is when using a pipeline and locking on a label. Specifically the proposed syntax from [https://github.com/jenkinsci/lockable-resources-plugin/pull/36] : ", variable: 'MY_VAR'" is missing. Our use case is that we wan't to specify a label containing node names for legacy builders that can't run the slave.jar (java7) anymore. We wan't to lock a resource (host name) from the label and then ssh to that machine and execute some build steps. This works with the FreestyleJob functionality of "Reserved resources variable name". h4. Solution It is now possible to access the locked resource via an configurable environment variable. {code:java} lock(label: 'some_resource', variable: 'MY_VAR') { echo env.MY_VAR } {code} |
| Remote Link | New: This issue links to " PR #50 (Web Link)" [ 15835 ] |
Wouldn't more useful to provide a map of environment variables for each resource? This way the complete parameterization can be done in one place (configuration). Otherwise you have to code some conditions based on resource name in your pipeline. (we do it now using Anton Lundin's workaround)
Anton Lundins workaround has some inconveniences. If you for example use multiple locks stacked on top of each other, you will not get the resource locked by the individual step, but all that the currentBuild is holding.
You can work around this but it may be more convinient to actually get the lock that was reserved in the current call.
Personally I am even more into having non block scoped lock steps with a groovy based return value (e.g. a map would be useful when locking multiple resources with a label). This is already described in https://github.com/jenkinsci/lockable-resources-plugin/pull/64
Daniel Geißler
added a comment - - edited Anton Lundins workaround has some inconveniences. If you for example use multiple locks stacked on top of each other, you will not get the resource locked by the individual step, but all that the currentBuild is holding.
You can work around this but it may be more convinient to actually get the lock that was reserved in the current call.
Personally I am even more into having non block scoped lock steps with a groovy based return value (e.g. a map would be useful when locking multiple resources with a label). This is already described in https://github.com/jenkinsci/lockable-resources-plugin/pull/64
I'm not voting for workaround (I use it, because it works), and I would really enjoy proper realization.
Multiple stacking is not a problem in case of using environment as I wrote above. In rare case anybody really need a name of resource, it can be exported as resource object addressed by 'resource label'. Even the list of resources can be realized as list of objects in case of multiple locking. 'Name', 'Description' and etc. can be some attributes of it.
Personally I'm prefer scoped lock. If something can be forgotten, humans forget this.
Just to link the workaround from Anton Lundin as long as it is not implemented:
https://issues.jenkins-ci.org/browse/JENKINS-34268?focusedCommentId=281694&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-281694