Want a custom sort of "milestone" condition

[jimklimov]

When working on PRs, or after merging several PRs and getting many new builds of the remaining ones due to target branch (typically "master") updates, many builds get scheduled and not all of them are worth pursuing.

The milestone step (or more complex approaches with milestone + lock) are often recommended to abort older builds if a newer one passed the milestone. We use it in the Jenkins-dynamatrix and/or NUT Jenkinsfile-dynamatrix specifically, but in practice this does not fire too often: an earlier build of the PR'ed branch(es) and/or the updated master-branch revisions occupy all available workers until done, and only then a later-scheduled build gets CPU time to be evaluated.

This issue proposes a different approach to tackle this area, practically to use for NUT CI builds - but ideally backed by library code and made useful generally:

• NUT builds benefit from having a "quick" set of smoke tests (pass shellcheck, spellcheck, rule out m4 errors in the process), while a parallel stage does the dynamatrix magic to propose CI build cells that would run heavier scenarios.
• The native convergence point is after that parallel stage for quick tests AND dynamatrix discovery is done. For example, here the build can bail out if some quick tests failed. Only later the "slow build" stage optionally starts and runs the discovered dynamatrix.
• The proposal is to add right in this spot a check for competing and more preferential builds, so as to peacefully end the unneeded iteration. Getting to this point can well take 10-15 minutes in favourable conditions, so most of the situations where we want to auto-cancel this build would materialize and land on GitHub by this time.
  • Possible criteria to abort a job would include:
    • This PR is closed (Jenkins job disabled... TBD: differentiate from being marked as a GitHub draft PR?);
    • Newer build numbers with same JOB_NAME are known (queued or running);
    • Originally requested Git commit is not resolvable (a force-push happened in the meantime);
  • Exemptions needed:
    • For a list of named branches (exact, regex) - e.g. for all "master" branch builds to happen completely;
    • Tie-in with GitHub comments/labels/... to exempt specific PR builds too (e.g. posting a series of experiments and refactorings, with a developer explicitly interested in the results of each)?