fix(quality): a push to development must reach a verdict - #597
Merged
Conversation
#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.
This was referenced Aug 28, 2026
fix(l10n): the eight manifest strings that render English to a Dutch user
ConductionNL/launchpad#364
Merged
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: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:Seven of 21 apps had no verdict on
developmentat 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-propertyerror todevelopmentand 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
on:filter) → never cancelled.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.pyclean.