Repository navigation
[#14151] improvement(ci): Stop Fork CI on the first failed job and report results faster - #14152
Merged
Merged
Conversation
…and refresh PR checks faster - Add a Stop on first failure job to fork-ci.yml that logs progress each minute and cancels the run once any job fails or times out, so authors can re-run failed jobs immediately instead of waiting for the slowest suite. It is the only job with actions: write and runs on ubuntu-latest because ubuntu-slim stops jobs after 15 minutes. - Report a run stopped this way as failure with the failed job in the check title. - Scale the scheduled sweep budget with the hourly API quota.
Contributor
Author
|
|
…n a fork run is not listed Run listings can miss existing runs, e.g. during GitHub incidents. Show a waiting check instead of asking the author to enable Actions, and never replace a run already recorded on the check with an empty listing. Note in CONTRIBUTING that reopening a PR refreshes the check but does not re-run Fork CI.
…d keep light checks off the shared pool - Scheduled status sweeps keep polling for 11 minutes, one pass every two minutes, because GitHub fires five-minute schedules only every 10-20 minutes on apache/gravitino and fork runs cannot notify upstream. Small quotas keep a single pass. - Run Trusted ASF Allowlist and Conflict Marker Check on ubuntu-slim: these small jobs queued for over three hours on the shared ubuntu-latest pool.
yuqi1129
changed the title
jerryshao
previously approved these changes
Oct 23, 2026
yuqi1129
force-pushed
the
fork-ci-fail-fast
branch
from
October 23, 2026 01:26
9517b0d to
6c16df0
Compare
yuqi1129
changed the title
yuqi1129
changed the title
diqiu50
approved these changes
Oct 23, 2026
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.
What changes were proposed in this pull request?
fork-ci.yml: add aStop on first failurejob that polls the run's jobs once a minute, logs progress (19/28 jobs completed, 1 failed; waiting for ...), and cancels the run as soon as any job fails or times out. It is the only job withactions: write, runs only trusted script code (no PR build or tests), and usesubuntu-latestbecauseubuntu-slimstops jobs after 15 minutes.fork-ci-status.cjs: a run that ended because a job failed is reported asfailurewith the failed job in the check title (e.g.Failed: backend / BackendIT ...), instead ofcancelled.update-fork-ci.cjs: scale the scheduled sweep budget with the hourly quota (limit / 24, at least 60 calls), and keep a scheduled sweep polling for 11 minutes, one pass every two minutes (repositories with small quotas keep a single pass). Fork runs cannot notify upstream, and GitHub fires the five-minute schedule only every 10-20 minutes on apache/gravitino, so results used to appear 15-40 minutes after the fork run finished.asf-allowlist-trusted.yml,conflict-marker-check.yml: run onubuntu-slim. On the sharedubuntu-latestpool these few-second jobs queued for more than three hours, leaving the required ASF Allowlist Check pending. The allowlist action installs its own Python and supportsubuntu-slim.fork-ci-status.cjs/update-fork-ci.cjs: when the run listing returns no fork run, show a waiting check (Waiting for Fork CI) instead ofaction_required"Enable Actions in the fork", and never replace a run already recorded on the check with an empty listing. During the current GitHub Actions incident,listWorkflowRunsintermittently returned 0 runs for existing runs, which turned reopened PRs into "Enable Actions".Why are the changes needed?
GitHub only allows "Re-run failed jobs" after the whole run completes, and Fork CI runs all suites in one run, so a single early failure meant waiting about two hours for the slowest suite before retrying. The PR check also stayed "in progress" for that time. With 60 calls per sweep, a finished fork run could take 30+ minutes to appear on apache PRs.
Fix: #14151
Does this PR introduce any user-facing change?
Contributors: one failed job now stops the rest of the Fork CI run; "Re-run failed jobs" is available immediately and also re-runs the jobs that were stopped.
How was this patch tested?
.github/scripts/tests/fork-ci.test.cjs(new: cancel on first failure, watcher ignores itself and exits after all jobs complete, failure title, singleactions: writejob onubuntu-latest, quota-scaled sweep budget, waiting on a missing run, keeping a recorded run, multi-pass sweeps that mirror a run finishing within the window); actionlint.failure | Failed: asf_allowlist / asf-allowlist-check, and "Re-run failed jobs" was available immediately and re-ran the cancelled jobs (Required CI succeeded). A run with an 18-minute job passed with the watcher exiting on its own, and a real test failure inbuild / changescancelled a run within one poll, with the progress lines in the watcher log.Fork CI=failureat 00:43:43, and one that passed at 00:49:14 showedsuccessat 00:50:40, with no other event. Onubuntu-slim, Conflict Marker Check and ASF Allowlist Check reported 40-70 seconds after the push.Waiting for Fork CIand then the fork run once it was listed again..github/workflows, so its own Fork CI check needs a trusted run dispatched by a committer.