Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-34268

Lock multiple resources using the Pipeline lock step

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The current implementation of Pipeline lock step allows to block a single resource.

      It should be extended to cover all the functionality of the plugin (applicable to non-freestyle jobs) such as blocking resources by label or request a lock for N resources.

      The DSL must be something like this:

      lock (resources: ['resource1', 'resource2']) {
        ... execution block ...
      }
      

      or

      lock (label: 'my-resources') {
        ... execution block ...
      }
      

      The behavior of the label parameter would be equivalent to:

      lock (resources: ['resource3', 'resource4']) { // if both resource3 and resource4 are labeled as 'my-resources'
        ... execution block ...
      }
      

        Attachments

          Issue Links

            Activity

            Hide
            dafalcon Dan Falcone added a comment - - edited

            After implementing Anton Lundin's suggestion, I received the following error in my build (followed by a stacktrace):

            org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method

            To fix it, I went to Manage Jenkins > In process Script Approval, clicked Approve on the pending signature approval, and reran the build.  I had to repeat the process 4-5 times to approve all the required signatures, but it worked great after that.

            Show
            dafalcon Dan Falcone added a comment - - edited After implementing Anton Lundin's suggestion, I received the following error in my build (followed by a stacktrace): org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method To fix it, I went to Manage Jenkins > In process Script Approval, clicked Approve on the pending signature approval, and reran the build.  I had to repeat the process 4-5 times to approve all the required signatures, but it worked great after that.
            Hide
            mrozekma Michael Mrozek added a comment - - edited

            Signatures required for the above workaround:

            method org.jenkins.plugins.lockableresources.LockableResource getName
            method org.jenkins.plugins.lockableresources.LockableResourcesManager getResourcesFromBuild hudson.model.Run
            method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild
            staticMethod org.jenkins.plugins.lockableresources.LockableResourcesManager get
            Show
            mrozekma Michael Mrozek added a comment - - edited Signatures required for the above workaround : method org.jenkins.plugins.lockableresources.LockableResource getName method org.jenkins.plugins.lockableresources.LockableResourcesManager getResourcesFromBuild hudson.model.Run method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild staticMethod org.jenkins.plugins.lockableresources.LockableResourcesManager get
            Hide
            mireksz Mirek Sz added a comment -

            Anton Lundin

            I did a really ugly workaround for the missing resourceVariable :

            Did you happen to find any way of getting the resource that's locked in the current lock closure? Your workaround always returns the name of first locked resource. I'm trying to run label-based locks in parallel, so I cannot simply use getResourcesFromBuild(...)[0], but must find out the exact resource locked within current scope. Any ideas?

            Show
            mireksz Mirek Sz added a comment - Anton Lundin I did a really ugly workaround for the missing resourceVariable : Did you happen to find any way of getting the resource that's locked in the current lock closure? Your workaround always returns the name of first locked resource. I'm trying to run label-based locks in parallel, so I cannot simply use getResourcesFromBuild(...) [0] , but must find out the exact resource locked within current scope. Any ideas?
            Hide
            glance Anton Lundin added a comment -

            The hack grew quite a bit over the following days, and ended up as:

            https://gist.github.com/glance-/aaa3c037757895798d4e1be5134bb843

             

            I removed the need for extensive whitelisting by writing it as a pipeline library which later could be imported into the pipeline dsl by:
            @Library("PipelineHelpers")
            import PipelineHelpers.LockableResourcesHelper

             

            We never use different locked resources in parallel so I have never needed to figure out if you can map locked resource to which block that locked it. If you ever do, please post the solution here for others to find.

            Show
            glance Anton Lundin added a comment - The hack grew quite a bit over the following days, and ended up as: https://gist.github.com/glance-/aaa3c037757895798d4e1be5134bb843   I removed the need for extensive whitelisting by writing it as a pipeline library which later could be imported into the pipeline dsl by: @Library("PipelineHelpers") import PipelineHelpers.LockableResourcesHelper   We never use different locked resources in parallel so I have never needed to figure out if you can map locked resource to which block that locked it. If you ever do, please post the solution here for others to find.
            Hide
            armb Alan Braggins added a comment - - edited

            We use locked resources in parallel, so the getResourcesFromBuild workaround didn't work for us.

            https://github.com/jenkinsci/lockable-resources-plugin/pull/50 seems to work. (I haven't tried pull/49, but it appears to be a similar approach to the same fix.)

            Show
            armb Alan Braggins added a comment - - edited We use locked resources in parallel, so the getResourcesFromBuild workaround didn't work for us. https://github.com/jenkinsci/lockable-resources-plugin/pull/50  seems to work. (I haven't tried pull/49, but it appears to be a similar approach to the same fix.)

              People

              • Assignee:
                amuniz Antonio Muñiz
                Reporter:
                amuniz Antonio Muñiz
              • Votes:
                19 Vote for this issue
                Watchers:
                33 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: