fix(ci): run CI on a pull request whose base is not main - #92
Merged
Conversation
A branches filter on pull_request matches the PR's BASE, so scoping it to main meant a stacked PR created no CI run at all — not a pending check, an absent one, which reads as a calm status area rather than a missing verifier. Two PRs shipped unverified this way: epistole #98 (asserted idempotency nothing had executed) and pinax #11 (3,510 lines that produced 42 compile errors the first time anything built them). push: branches: [main] is unchanged; it is what prevents duplicate runs. This is the shape heurema already uses. Refs forkwright/kanon#3475
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
1 participant
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.
Finding
.github/workflows/ci.ymlscoped itspull_requesttrigger tobranches: [main]. That filtermatches the pull request's base, so a PR opened against any branch other than
mainmatchednothing and no CI run was ever created for it.
That is not a pending check or a slow check. It is an absent one — which renders as a PR with a calm
status area and nothing red on it, indistinguishable from a PR whose checks all passed.
Evidence
Two PRs shipped unverified through this in a single session:
epistoleAdopt the fleet license posture: one declaration, rendered per repo #98 — the Phase 2 SMTP send path, stacked on fix(dictyon): validate server-supplied key-hex and routing-data fields at netmap ingestion #97. Zero CI runs for its entire life.Its body asserted idempotency behaviour that no independent witness had ever executed.
pinaxdocs: llms.txt per kanon doc standards (closes #10) #11 — 3,510 lines of pager, buffer pool and B+tree, stacked on docs: add llms.txt per kanon doc standards #10. Also zero CI. Oncerebased onto
mainand gated for the first time it produced 42 compile errors. It had neverbeen compiled anywhere, by anything, and it sat open looking mergeable.
heuremaalready carries the unfiltered form, so this is not a new convention — it is bringing thisrepo to a shape the fleet already proves out.
Why this matters
The filter withdraws verification from exactly the case that needs it most: a dependent change
written against a contract that has not merged yet. Stacked PRs are the shape the fleet's process
produces whenever one unit depends on another, so this silently un-verifies the work most likely to
be built on an assumption.
It is also a live instance of
PHILOSOPHY.md§ an instrument must be able to be wrong: a checkthat cannot run teaches every reader to skim past its absence.
Desired correction
Drop the
branchesfilter frompull_requestonly.push: branches: [main]is unchanged — that oneis correct, and is what prevents duplicate runs.
The class fix — a
basanosrule so the next repo cannot inherit this — is tracked atforkwright/kanon#3475.
Done when: a PR whose base is not
mainproduces an actual CI run in this repo.Refs forkwright/kanon#3475