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

Allow lock retrieval based on requested priority

XMLWordPrintable

    • 1246.v28b_e4cc6fa_16

      I'd be interested in seeing a feature where a lock could have an optional priority. If a priority is set, actions requesting resources with a higher priority would get the lock sooner than those with lower priority.

       

      lock('my-resource', priority: 9) { }
}

lock('my-resource', priority: 5) { }

       

      In this example, I would expect the priority 9 lock to yield before the priority 5 lock, even if priority 5 requested the lock first. This could be used in conjunction with inversePrecedence to order lock yielding within priority buckets.

          [JENKINS-42679] Allow lock retrieval based on requested priority

          ethorsa added a comment - - edited

          There's a pending PR already: PR#78

          Unfortunately it's stuck since months.

          ethorsa added a comment - - edited There's a pending PR already: PR#78 Unfortunately it's stuck since months.

          Tobias Gruetzmacher added a comment -

          It seem some kind of priority support was already part of this plugin before version 1.7, but it was removed. I'll take a look at the merge request, but my focus is currently more on bug-fixing...

          Tobias Gruetzmacher added a comment - It seem some kind of priority support was already part of this plugin before version 1.7, but it was removed. I'll take a look at the merge request, but my focus is currently more on bug-fixing...

          William Brode added a comment -

          tgr thanks for all your great work!  Would definitely be interested in this feature.  Not sure if people are handling this another way but we use the lock(inversePrecedence: true) { milestone() } paradigm to "roll up" builds when multiple builds are ready to enter that stage of the pipeline.

          There is an issue with this: If change 1 starts, then change 2, but change 2 goes faster and gets to the lock first, it would abort change 2 and build change 1 (since change 1 called the lock step last).  So at least for SCMs with increasing numeric change numbers, it would be preferable to use the change number as the priority - to ensure we always let the newest change get the lock.

          William Brode added a comment - tgr thanks for all your great work!  Would definitely be interested in this feature.  Not sure if people are handling this another way but we use the lock(inversePrecedence: true) { milestone() } paradigm to "roll up" builds when multiple builds are ready to enter that stage of the pipeline. There is an issue with this: If change 1 starts, then change 2, but change 2 goes faster and gets to the lock first, it would abort change 2 and build change 1 (since change 1 called the lock step last).  So at least for SCMs with increasing numeric change numbers, it would be preferable to use the change number as the priority - to ensure we always let the newest change get the lock.

          ethorsa added a comment - - edited

          Available with 1246.v28b_e4cc6fa_16.

          Changelog: https://github.com/jenkinsci/lockable-resources-plugin/releases/tag/1246.v28b_e4cc6fa_16

          ethorsa added a comment - - edited Available with 1246.v28b_e4cc6fa_16 . Changelog:   https://github.com/jenkinsci/lockable-resources-plugin/releases/tag/1246.v28b_e4cc6fa_16

            Unassigned Unassigned
            rpocase Robby Pocase
            Votes:
            8 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: