Repository navigation
Run the landed-quest guard in CI - #191
Conversation
Quest-Claim: f25310d9ae66b2b8
The check job builds quest from the PR's base with Nix, before any of the head's code runs, and fails when a quest branch neither deletes nor rewrites its quest. Merges that skip /quest-merge are checked too, and the guard rides the already-required check status. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Outcome: the landed-quest guard now runs in the required
(Written by Claude Opus 5.5) |
|
Merging via
Enabling squash auto-merge pinned to this head. (Written by Claude Opus 5.5) |
|
Update: kixelated/quest#192 landed first, so the first auto-merge attempt was refused ("Base branch was modified").
Enabling squash auto-merge pinned to (Written by Claude Opus 5.5) |
Finishes quest/m0/helpers/ci-guard.md, a follow-up of kixelated/quest#169.
Problem
quest check --basecatches a quest PR that finishes its quest without deleting or rewriting it, but only/quest-mergeran it. A PR merged any other way skipped the check.Change
On pull requests, the
checkjob now runs the guard before anything else:questfrom it withnix build .#quest.origin/<base>and the merge base are available).$RUNNER_TEMP, outside the checkout, runquest --root "$GITHUB_WORKSPACE" check --base "origin/$GITHUB_BASE_REF" --branch "$GITHUB_HEAD_REF".Only the head's checkout has happened when the guard runs; none of its code or runtime config (
bunfig.toml, the flake) has run yet. So the head can't weaken the check it is held to, as the merge skill requires. Branches that aren't quest branches pass without any filtering. Pushes tomainand manual runs skip the guard steps.I put the guard in the
checkjob, not in a job of its own, becausecheckis the only status check branch protection requires. That way it blocks merges with no change to settings. A separate job would have to run first anyway, and it would only block merges after someone added it to the required checks.The finished quest is deleted with
quest rm, which also removes its link from the helpers epic.Validation
I built
questfrom this tree withnix build .#quest. Itssrc/matches the base, since this PR doesn't touch it. I ran it from outside the checkout against this worktree, with--base origin/main:--branch plan/next): passes.--branch quest/m0/helpers/README, whose README this PR edits): passes.--branch quest/m0/helpers/ci-guard): passes.CI on this PR runs the real workflow, base build and detached merge-ref checkout included.
just check(including actionlint) andjust testpass locally.Limitations
quest checkon the head's tree. If a PR changes the quest format and uses the new format inquest/in the same PR, the base's rules reject it. The merge skill already has this behavior. If it ever comes up, it can be split into separate PRs.pull_requestworkflow. A PR that editscheck.ymlcan still drop the guard, but that change shows up in review.Follow-ups
quest checkoption that runs only the landed comparison.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code