Feat/refactor ci trigger#5011
Draft
lum1n0us wants to merge 4 commits into
Draft
Conversation
lum1n0us
force-pushed
the
feat/refactor_ci_trigger
branch
2 times, most recently
from
July 27, 2026 06:35
ea909b4 to
7eec92d
Compare
Move pre-merge CI onto the contributor's fork and spend upstream minutes only when a maintainer actually approves. CI over a PR's lifecycle (assume the PR is updated N times = N pushes): - Fork (contributor's own minutes): every push to a non-main/release/dev branch triggers the push-event CI. Over the PR that is N runs per workflow, each still subject to its on.push.paths filter (only the workflows whose files changed actually run). - Upstream (project minutes): nothing runs on push. A `pull_request_review` (submitted) event fires the `gate` job; the first APPROVED review of the PR lets the real jobs run once, later approvals are skipped. Because a new push dismisses the stale approval, each "push -> re-approve" cycle allows at most one full upstream run. Best case a clean PR costs upstream exactly 1 run; a PR re-approved after k re-pushes costs k upstream runs. Required repository settings: - Branch protection: "Dismiss stale pull request approvals when new commits are pushed" MUST be enabled. The gate counts APPROVED reviews and skips when >1; dismissal is what resets the count so a re-approval can trigger a fresh upstream run after new commits. - Actions must be allowed to run on forks (default), so fork push CI works. Implementation: - Fork CI: replace `pull_request` triggers with unrestricted `push` (branches-ignore main/release/**/dev/**) so forks run on their own minutes. - Upstream CI: add `pull_request_review` (submitted) plus a reusable `gate` job (.github/workflows/gate.yml) that only lets CI run for the first approval of a PR. - Gate restores the path filtering `pull_request_review` lacks via .github/scripts/pr_touches_paths.py. - Checkout steps pin the PR merge ref (env.PR_REF) under pull_request_review, since the event otherwise checks out the base branch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lum1n0us
force-pushed
the
feat/refactor_ci_trigger
branch
from
July 27, 2026 07:10
7eec92d to
431e9f4
Compare
lum1n0us
force-pushed
the
feat/refactor_ci_trigger
branch
from
July 27, 2026 07:32
ce2a11b to
eee08b7
Compare
lum1n0us
force-pushed
the
feat/refactor_ci_trigger
branch
from
July 27, 2026 12:14
191cda7 to
9af5dc0
Compare
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.
Move pre-merge CI onto the contributor's fork and spend upstream minutes
only when a maintainer actually approves.
CI over a PR's lifecycle (assume the PR is updated N times = N pushes):
branch triggers the push-event CI. Over the PR that is N runs per
workflow, each still subject to its on.push.paths filter (only the
workflows whose files changed actually run).
pull_request_review(submitted) event fires the
gatejob; the first APPROVED review of thePR lets the real jobs run once, later approvals are skipped. Because a new
push dismisses the stale approval, each "push -> re-approve" cycle allows
at most one full upstream run. Best case a clean PR costs upstream exactly
1 run; a PR re-approved after k re-pushes costs k upstream runs.
Required repository settings:
are pushed" MUST be enabled. The gate counts APPROVED reviews and skips
when >1; dismissal is what resets the count so a re-approval can trigger a
fresh upstream run after new commits.