Skip to content

Run CI on dev pushes and save the Rust cache only there so PRs can finally restore it - #873

Merged
WaylandYang merged 1 commit into
devfrom
ci/cache-from-dev
Sep 23, 2026
Merged

WaylandYang merged 1 commit into
devfrom
ci/cache-from-dev

Conversation

@WaylandYang

Copy link
Copy Markdown
Contributor

Why

The Rust build cache in this repository has never been restored, not once. Evidence from today's 12 backend runs:

  • The Test step compiles 314 crates, 9 of them ours. The other ~305 dependencies are built from scratch every run (Clippy ~140s, Test compile ~180s, 迁移测试库 ~70s, sqlx-cli install ~78s).
  • Swatinem/rust-cache restore takes 0–2s and logs No cache found on every run, including second runs of the same PR.
  • actions/cache/usage: 17 entries, 10.7 GB against the 10 GB quota, all created today, all under refs/pull/N/merge, and every entry's last_accessed_at equals its created_at.

Three things combine:

  1. CI runs on push only for main. Nothing ever runs on dev, so there is no cache on the base branch that PRs could read. GitHub lets a PR read caches from its own ref, its base branch and the default branch only, so PRs never see what other PRs saved.
  2. Every PR run saves ~2 GB (backend ~1 GB + migrations ~0.9 GB). Five or six PRs fill the 10 GB quota and LRU eviction starts.
  3. By the time the same PR runs again, its own entry is usually gone. Run documents route tests against Postgres in CI so they cannot skip silently #868's surviving cache was created at 07:04 by its second run; the first run's entry from 04:51 had already been evicted.

What

  • on.push.branches: [main, dev]. Each merge into dev runs CI and saves a cache under refs/heads/dev, which every PR targeting dev can restore. This also closes the gap the migrations job header comment describes: the merged state of dev now gets a CI run.
  • save-if: ${{ github.event_name == 'push' }} on both rust-cache steps. PRs restore only; only dev/main push runs write. The cache footprint becomes ~2 GB total instead of thrashing at the quota. ~/.cargo/bin is part of that cache, so sqlx-cli stops being reinstalled per run too.

Workflow-level permissions: contents: read untouched.

What to expect

This PR's own run cannot show the speedup: no dev cache exists yet. The first push to dev after merging (this merge itself) saves it; the next PR run should restore ~1 GB in ~20–30s and then compile only the workspace crates and link the test binaries. Rough expectation: Clippy 140s → ~40s, Test compile 180s → 60–80s, 迁移测试库 70s → ~15s, 装 sqlx-cli 78s → seconds. Those are estimates, not measurements; I'll verify on the dev push run (cache saved) and the next PR run (cache restored).

🤖 Generated with Claude Code

…nally restore it

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: WaylandYang <145302500+WaylandYang@users.noreply.github.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