Cache the Rust build in CI
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- Half a day
- Newbie friendliness
- 80/100
Research direction
Start with the build job in .github/workflows/ci.yml, which runs fmt, clippy, test and build with no cache step. Read CONTRIBUTING for the commit-hash pinning rule, and check how Cargo.lock and rust-toolchain.toml are referenced. Add a cache keyed on those two files, then run the workflow twice on your fork, cold and warm, to show the speedup. Done means the warm run is faster, a Cargo.lock or toolchain change misses the cache, the deployment job does not share it, and CI is green.
Written by the indexing model from the issue text.
Description
Written against commit 78d0a89; later commits may have moved things, so check the code first.
Size: Trivial
Description
Every CI run (each push, each pull request, and the weekly schedule) compiles soroban-sdk and its test utilities from scratch for cargo clippy, cargo test and stellar contract build. There is no cache step, so most of the run is dependency compilation. The same problem is tracked for the main repository (Sorogate/sorogate issue "Cache the Rust build in CI"); this repository has its own workflow.
Current state
.github/workflows/ci.yml: thebuildjob runs fmt, clippy, test, build; no cache.- CONTRIBUTING says actions are pinned by commit hash with a version comment; a new action must be pinned the same way.
What to build
Add a cache for ~/.cargo registry and target/ keyed on Cargo.lock and the toolchain in rust-toolchain.toml (either Swatinem/rust-cache pinned by commit, or actions/cache with explicit paths; say why). Compare run times before and after on your fork (cold and warm) and put the numbers in the PR. The cache must not be shared with the deployment job.
Acceptance criteria
- A warm run is measurably faster; numbers in the PR.
- A change to
Cargo.lockor the toolchain misses the cache. - Any new action is pinned by commit with a version comment.
- CI is green.
Out of scope
Caching the Stellar CLI install.
Verification
Two consecutive runs on your fork.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 2
- Avg merge
- 2h 30m
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Sorogate/example-consumer
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Sorogate/example-consumer#17 ·
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Sorogate/example-consumer#15 ·
-
enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Sorogate/example-consumer#14 ·
-
enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Sorogate/example-consumer#11 ·
-
enhancement good first issue help wanted
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Sorogate/example-consumer#10 ·
All issues in Sorogate/example-consumer
Similar issues
-
bug easy good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lacs-project/sysknife#659 ·
Maintainers usually reply within 2 days
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
registrystack/registry-stack#2431 ·
Maintainers usually reply within 1 day
-
contribution
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
farion1231/cc-switch#8863 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
DioxusLabs/dioxus#6006 ·
Maintainers usually reply within 1 day