| Tobias Gruetzmacher 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. |
