Run CI on pushes to main - #38
Merged
Merged
Conversation
…erging main's required status check was removed to stop pull requests waiting on a 45-minute run. That also removed the only thing verifying what reaches main, so a merge can now land with nothing having reported on it at all. This does not restore the gate — it cannot, a push is after the fact. What it restores is attribution: a break on main is reported against the commit that caused it rather than discovered by whoever opens the next pull request. Two details that matter for a push trigger: `cancel-in-progress` is now conditional. A pull request superseding its own earlier run is what that setting is for; main superseding its own is not. If a merge cancelled the run verifying the merge before it, a break could land with nothing ever having reported on it, which is the case this exists to cover. The concurrency group keys on the pull request number where there is one and the commit otherwise, so two pushes to main never share a group. It also warms the caches, which is worth more here than it looks. A `pull_request` run writes its cache into `refs/pull/N/merge`, and no other pull request can read that scope — five identical libghostty-vt entries existed under five different pull requests, none of them reachable, so every pull request was installing Zig and compiling the same pinned revision from scratch. A run on main writes where they can all restore from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
m96-chan
added a commit
that referenced
this pull request
Sep 15, 2026
… not there (#42) main has been red on every push since #38. The `scope` job reads the changed files from `repos/OWNER/REPO/pulls/NUMBER/files`, and on a push event `github.event.pull_request.number` is empty, so the request goes to `/pulls//files` and comes back 404. `scope` fails, every job that needs it is skipped, and the `ios` check reports the failure. #37 added `scope` for pull requests and #38 added the push trigger. Each was green on its own; the combination was never run before it was on main. A push has nothing to skip anyway. What reached main is worth building, and that run is the only thing that reports on it now that the required check cannot. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
main's required status check was removed so pull requests would stop waiting on a 45-minute run. That also removed the only thing verifying what reaches main: a merge can now land with nothing having reported on it.
This does not restore the gate — a push runs after the fact. It restores attribution: a break on main is reported against the commit that caused it, rather than discovered by whoever opens the next pull request.
Two details a push trigger needs:
cancel-in-progressis now conditional. A pull request superseding its own earlier run is what that setting is for. main superseding its own is not — if a merge cancelled the run verifying the merge before it, a break could land with nothing ever reporting on it, which is exactly the case this exists to cover.It also fixes the cache scoping
A
pull_requestrun writes its cache intorefs/pull/N/merge, which no other pull request can read. Five identicalghostty-vt-…entries existed under five different pull requests, none of them reachable — so every pull request was installing Zig and compiling the same pinned revision from scratch, about four minutes each time. A run on main writes where they can all restore from.This makes
cache-ghostty.ymlin #37 redundant, since this run warms the same cache. Worth dropping from that branch when it rebases.Note on #37
#37 rewrites this file into four parallel jobs, so the two will conflict textually. This is the smaller and more urgent of the two — it is against the file as main has it today, and the trigger carries over to #37's shape unchanged.
🤖 Generated with Claude Code