[wshlavacek]

A pull request opened with gh pr create --label "changelog exempt" fires opened and labeled together. Under the changelog workflow's concurrency group with cancel-in-progress, one of the two runs was cancelled, and the cancelled run stays in the commit's status rollup as a second fragment staged. The rollup then reads FAILURE although every check that ran passed.

Measured with statusCheckRollup on the commits involved:

• first commits of sbml: build the ring-of-sizes links once, and write their refusals with one helper (#1406) #1407 and tests: read #1304's attribution on 338 and 339, whichever way dense LU breaks XIIa = 0 #1408: FAILURE, the cancelled fragment staged the only red;
• heads of ci: run both sanitizer jobs nightly, not on every C++ pull request #1262, tests: make test_c_api's checks run in the builds CI uses #1258, benchmarks: refresh the seven July ODE timing reports on 0.16.0 (#551) #1251, steady_state: a pivot within its rounding is a zero one, on every platform (#1001) #1223, tests: point the sensitivity-run xfail at #1182 #1184, Re-pick the paying-Jacobian fixture after #888 (#898) #909 and harness: grade SBML Test Suite cases through the suite kernel, so event-promoted symbols stop crashing the run #839: the same cancelled-plus-success pair, FAILURE.

Change

• The concurrency block is gone. Dropping only cancel-in-progress would not be enough, because a group still cancels a pending run when another queues behind it (opened plus two labels is three runs). The job is read-only and takes seconds.
• With every run finishing, the runs have to agree. The label escape read github.event.pull_request.labels, which is a snapshot of the moment each event fired, so an opened run could fail for real on an exempt pull request beside a labeled run that passed. The step now reads the labels from repos/…/pulls/N when it runs.
• The label read is a plain assignment, so a failed API call ends the step under the runner's bash -e. It is not read as "no label", and there is no grep -q under pipefail.
• test_changelog_fragments.py gains a textual pin (no concurrency, no payload label read), in the style of the module's other workflow checks. It fails against main's workflow.

Checked

• The step's script, run locally under bash -e against live pull requests:
  • sbml: build the ring-of-sizes links once, and write their refusals with one helper (#1406) #1407 (labelled, source change, no fragment): exempt, exit 0.
  • sbml: build the ring-of-sizes links once, and write their refusals with one helper (#1406) #1407 with the label lookup made to miss: the "stages no changelog entry" error, exit 1.
  • mir: raise when MIR runs out of memory or address space (#1215) #1399 (no label, fragment staged): passes.
  • A nonexistent PR number: ends at the label read with exit 1, before the files call.
• test_changelog_fragments.py: 51 passed; the new test fails on main's workflow.
• This pull request was opened with the label, so its own fragment staged runs are the race under the new workflow: two runs (opened, labeled), both SUCCESS, none cancelled.
• DO NOT MERGE: probe for #1417's changelog label read #1418, a draft probe on top of this branch, changed one library file (python/bngsim/_rounding.py) and staged no fragment, so its gate passes only if a run sees the label. It was closed and its branch deleted afterwards.
  • Opened with the label: two runs, both SUCCESS, both logging "labelled 'changelog exempt'".
  • Label removed: the unlabeled run failed with "changes the shipped library (python/bngsim/_rounding.py) and stages no changelog entry".
  • Label re-applied: the labeled run passed, and gh pr checks showed fragment staged as pass.

Not changed here: the commit's statusCheckRollup counts every check run on a commit, so on #1418 the red unlabeled run kept the commit's rollup at FAILURE after the label went back on, although gh pr checks showed pass. That is how the label escape has always behaved after a red run, not something this change introduces.