Skip to content

CI: a pull request gets the fast answer, main and dispatch get everything - #242

Open
itz4blitz wants to merge 3 commits into
mainfrom
ci/fast-pr-path
Open

itz4blitz wants to merge 3 commits into
mainfrom
ci/fast-pr-path

Conversation

@itz4blitz

Copy link
Copy Markdown
Collaborator

What changed and why

A PR took 26-50 minutes to go green. Measured over the last 30 days (800 tinyclient runs): the macOS test job rebuilt from nothing whenever the 10 GB Actions cache had evicted it (16-19 min of build instead of 4.6), Windows took 12-28 min, and Linux took 9. The release build and packaging ran on every PR too. Details in the thread.

Now:

  • A pull request runs Linux only, the tests split three ways with cargo nextest --partition hash:N/3, plus one parallel job for Linux doc tests and the mobile check. The release build and packaging run only when the change touches packaging/, .github/actions/, Cargo.toml, Cargo.lock or this file (the new changes job decides).
  • A push to main, and gh workflow run ci.yml --ref <branch>, run everything: Linux (3 shards), macOS and Windows (2 shards each), every release program. A release already waits for main's run, so nothing it relies on changed.
  • PRs that only touch docs, the site, the review config, .github/scripts or the pr-review workflows no longer start the Rust matrix.

Type

  • feature
  • fix
  • perf
  • refactor
  • chore
  • docs

Platforms

  • windows
  • macos
  • linux
  • android
  • ios

Proof

CI itself. This pull request's own run is the evidence; the numbers are in the comment below once it finishes.

Scenario: none (chore)

Compatibility

No app change. release.yml, release-cut.sh and reuse-binaries.sh read main's push run of ci.yml and its package artifacts, which are unchanged. The test (...) check names now carry a shard (test (ubuntu-22.04 1/3)). Nothing is a required check today.

Risk and rollback

A platform-only break (macOS or Windows) in a PR is now caught on main's push run, not before the merge, or earlier by dispatching the workflow on the branch. Revert this commit to go back.

Release note

None.

🤖 Generated with Claude Code

itz4blitz and others added 3 commits November 11, 2026 13:48
…hing

A pull request now runs Linux only, with the tests split three ways (nextest
--partition hash), and skips the release build unless the change touches
packaging, Cargo.toml or Cargo.lock. macOS and Windows tests, the other
release programs and doc tests on those platforms run on every push to main
and on a manual dispatch, which is what a release already waits for.

The measured problem: a PR waited 26-30 minutes on a macOS test job that
rebuilt cold whenever the 10 GB cache had evicted it, and 12-28 on Windows,
while Linux took 9. The tests are CPU-bound (about 1,300 CPU-seconds), so
they scale with runners. Docs, site and the review and pr-gate tooling no
longer start the Rust matrix at all.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The first run of the three-shard split measured 4.2-6.1 minutes per shard
(1.9-3.0 of tests, uneven because hash partitions by test count, not time).
Five shards bring the slowest under five minutes. Main keeps three.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ilds every release program

Resolves the ci.yml conflict with #241: Linux entries carry --features
tinyclient/gui (as #241 turned it on, so main writes the cache pull requests
restore), the extras job builds and doc-tests with it, and package keys on
!= pull_request so a dispatch builds all four, as the header says.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant