• Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Minor Minor
    • None
    • Jenkins ver. 2.65,
      Lockable Resources plugin ver. 2.0

      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.

          [JENKINS-44950] Support a quantity of zero required resources

          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.

          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.

          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.

          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.

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

          Aaron D. Marasco added a comment - Thanks; I didn't know an unnamed lock implicitly worked.

          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
          }
          

          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 }

          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.

          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.

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

              Created:
              Updated:
              Resolved: