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

Support a quantity of zero required resources

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Done
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.65,
      Lockable Resources plugin ver. 2.0
    • Similar Issues:

      Description

      If possible, it would be convenient to be able to specify a quantity of zero required resources of a certain type - instead of having to have an "if" condition. This way we could pass in values for quantity and not have to check for 0.

       

      Something like:

      lock(resource: 'resource', quantity: 0) { ...

      that would essentially be ignored.

        Attachments

          Activity

          nv035674 Nathan Vahrenberg created issue -
          Hide
          aarondmarasco_vsi Aaron D. Marasco added a comment -

          Is there a good workaround for this? I don't think a simply "if" will get around it if you still want the code to execute.

          Here's my scenario: I am synthesizing HDL in different phases. Some tools require a license for every phase, while some only when creating the final artifact. I want to share the licenses as much as possible and only have the phases lock the license when it's needed. My planned workaround is to have a "license pool" called "infinite" or something like that, and then have like 100 fake items in the pool to be checked out. Then switch out the resource name. But a quantity 0 would be easier and more obvious what I'm aiming for.

          Show
          aarondmarasco_vsi Aaron D. Marasco added a comment - Is there a good workaround for this? I don't think a simply "if" will get around it if you still want the code to execute. Here's my scenario: I am synthesizing HDL in different phases. Some tools require a license for every phase, while some only when creating the final artifact. I want to share the licenses as much as possible and only have the phases lock the license when it's needed. My planned workaround is to have a "license pool" called "infinite" or something like that, and then have like 100 fake items in the pool to be checked out. Then switch out the resource name. But a quantity 0 would be easier and more obvious what I'm aiming for.
          Hide
          nv035674 Nathan Vahrenberg added a comment -

          My workaround for the time being has been to reserve a resource with a blank name, something like:

          resource_name = ''
          if (...) { resource_name = 'whatever' }
          lock(resource: resource_name) { ...

          This works for my use case. I wanted the ability to lock for only some projects while still allowing all projects to call into the same central library.

          Show
          nv035674 Nathan Vahrenberg added a comment - My workaround for the time being has been to reserve a resource with a blank name, something like: resource_name = '' if (...) { resource_name = 'whatever' } lock(resource: resource_name) { ... This works for my use case. I wanted the ability to lock for only some projects while still allowing all projects to call into the same central library.
          Hide
          aarondmarasco_vsi Aaron D. Marasco added a comment -

          Thanks; I didn't know an unnamed lock implicitly worked.

          Show
          aarondmarasco_vsi Aaron D. Marasco added a comment - Thanks; I didn't know an unnamed lock implicitly worked.
          Hide
          tgr Tobias Gruetzmacher added a comment -

          Does this fix in release 2.6 from today help?

          This allows an "empty" lock when using the "extra" list:

          def locks = []
          if (cond) {
              locks << [quantity: 1, resource: 'foo']
          }
          lock(extra: locks) {
              // some block
          }
          
          Show
          tgr Tobias Gruetzmacher added a comment - Does this fix in release 2.6 from today help? This allows an "empty" lock when using the "extra" list: def locks = [] if (cond) { locks << [quantity: 1, resource: 'foo' ] } lock(extra: locks) { // some block }
          tgr Tobias Gruetzmacher made changes -
          Hide
          nv035674 Nathan Vahrenberg added a comment -

          I threw together a quick test and it looks like that works. It logs out this when it doesn't have anything to lock:

          09:03:55  Trying to acquire lock on [nothing]
          09:03:55  Lock acquired on [nothing] 

           

          Which is better than what it said previously, something like "no resource specified - probably a bug." There were a few times people were misled by that message. I think that's good enough to close this out.

          Show
          nv035674 Nathan Vahrenberg added a comment - I threw together a quick test and it looks like that works. It logs out this when it doesn't have anything to lock: 09:03:55 Trying to acquire lock on [nothing] 09:03:55 Lock acquired on [nothing]   Which is better than what it said previously, something like "no resource specified - probably a bug." There were a few times people were misled by that message. I think that's good enough to close this out.
          nv035674 Nathan Vahrenberg made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Done [ 10000 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              nv035674 Nathan Vahrenberg
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: