Skip to content

fix(quality): a push to development must reach a verdict - #597

Merged
rubenvdlinde merged 1 commit into
mainfrom
fix/development-must-reach-a-verdict
Aug 27, 2026
Merged

fix(quality): a push to development must reach a verdict#597
rubenvdlinde merged 1 commit into
mainfrom
fix/development-must-reach-a-verdict

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Closes the open half of #526.

The premise in #526 is now stale

#526 diagnosed the cancellations as a cadence problem caused by the release loop pushing chore(release): every 8–12 minutes. That was true on 2026-08-20. The release job's self-skip guard landed 2026-08-26 and closed it.

Re-measured 2026-08-27, 8 hours, all 21 fleet repos, 109 commits on development:

count
release-loop churn 0 (0%)
real work 109 (100%)

Every one is a squash-merged PR. openregister alone merged ten. So the traffic cancelling these runs is the fleet working — it is not noise, and throttling it is not on the table.

Why cancelling is wrong here specifically

"Once commit N+1 exists, verifying N matters less" is right for a queue of feature-branch pushes. It is wrong for an integration branch: the run being cancelled is the only thing that would have said whether what just landed is sound — and its replacement gets cancelled too.

Each repo's last twelve completed runs on development:

repo cancelled
openregister 12 / 12
learniq 10 / 12
pipelinq 10 / 12
dossiq 8 / 12

Seven of 21 apps had no verdict on development at all.

A cancelled run is not a failure, but it is not a pass either — it is no verdict, and it renders as "nothing wrong here" in every summary that counts failures.

The concrete casualty

learniq shipped a vue/new-line-between-multi-line-property error to development and nothing reported it, because every Code Quality run there since 09:54 was cancelled rather than completed. It surfaced only when a PR cut after that commit went red. Fix in ConductionNL/learniq#664.

The change

-  cancel-in-progress: true
+  cancel-in-progress: ${{ github.event_name != 'push' }}
  • push (main/development only — see the on: filter) → never cancelled.
  • pull_request → still cancels; only the latest head commit is meaningful.
  • workflow_dispatch → still cancels within its own lane.

Cost

Queue depth, not money. The fleet is public, so Actions minutes are free (#—); the constraint is the 60-concurrent-job account ceiling, which buys latency. A late verdict beats no verdict.

Verified: YAML parses (21 jobs), assert-run-steps-resolvable.py clean.

#526 read the cancellation as a cadence problem caused by the release
loop, and at the time it was: an automated cycle pushed `chore(release):`
every 8-12 minutes while a run takes 14-23, so the branch could never
converge. The self-skip guard that landed 2026-08-26 closed that, and the
premise no longer holds.

Re-measured 2026-08-27 over 8 hours, all 21 fleet repos, 109 commits on
development:

    release-loop churn   0  (0%)
    real work          109  (100%)

Every one is a squash-merged pull request; openregister alone merged ten.
The traffic cancelling these runs is not noise to throttle, it is the
fleet working, and it will not slow down.

"Once commit N+1 exists, verifying N matters less" holds for a queue of
feature-branch pushes. It does not hold for an integration branch: the
run being cancelled is the only thing that would have said whether what
just landed is sound, and its replacement is cancelled too. Over each
repo's last twelve COMPLETED runs -- openregister 12 of 12 cancelled,
learniq 10 of 12, pipelinq 10 of 12. Seven of 21 apps had no verdict on
development at all.

That is not theoretical. learniq shipped an eslint error to development
and nothing reported it, because every run there since 09:54 was
cancelled rather than completed; it surfaced only when a PR cut after it
went red (learniq#664).

Push runs no longer cancel. pull_request still does -- there only the
latest head commit is meaningful. The cost is queue depth, not money:
the fleet is public so Actions minutes are free, and the 60-concurrent
ceiling buys latency. A late verdict beats no verdict.
@rubenvdlinde
rubenvdlinde merged commit 5a0329b into main Aug 27, 2026
36 checks passed
@rubenvdlinde
rubenvdlinde deleted the fix/development-must-reach-a-verdict branch August 27, 2026 19:42
This was referenced Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant