Repository navigation
ci: keep shared caches warm from develop and stop slow steps early - #196
Merged
Merged
Conversation
PR runs restored caches only from their own PR, and every PR saved multi-GB caches that evicted all others under the 10 GB repo cap, so nearly every job built cold. Run CI on develop pushes and save caches only from develop or main; PR runs restore and never save. Skip release packaging on pull requests: nothing uploads it there, and setup-source-home already proved the release build. Bound apt and brew steps to 15 minutes with apt retries instead of the 90-minute job limit. The CI policy test now checks that only develop and main pushes save.
8 of 21 tasks
This was referenced Oct 2, 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.
Part of #194 (Part 0: CI speed). Measured 1 October: CI wall time median 47 min (p90 56); runners queue for 0.1 min, so time goes into the jobs themselves.
Root cause 1, cache thrash: CI ran on PRs and main only, so caches were saved only in PR scope. A PR can read only its own caches and those of develop or main, and there were none on develop. Each PR saved 6-8 GB under the 10 GB repo cap (PR #188 alone held 8.3 GB), evicting every other PR's caches: the oldest cache was 1 hour old, and test-elastos logged "No cache found".
Root cause 2, wasted and unbounded steps: PR runs rebuilt and packaged release binaries that are uploaded only for tags, main and dispatch (about 7 minutes on macOS), and a stalled apt mirror held one Linux job for 90 minutes.
Changes
save-if,actions/cachesplit into restore and save). PR runs restore and never save.scripts/ci-release-policy-test.pychecks that only develop and main pushes save caches (fails when a rust-cache step lackssave-ifor a save step ignores the rule).Not changed: tag builds stay cache-free (#137); jobs, names and required checks stay the same.
Proof after merge: the develop push run saves caches; the next PR run logs "Cache restored" in test-elastos and source-home jobs, and its time is recorded on #194 against the 47-minute baseline.