fix(ci): add npm cache to backend/frontend jobs, drop unused wasm target, cache stellar-cli binary. - #489
Conversation
…get, cache stellar-cli binary
|
@Kureszn Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
📝 WalkthroughWalkthroughThe pull request narrows the Rust CI target, expands Rust and npm caching, and adds a security policy covering private vulnerability reporting, response timelines, supported versions, and vulnerability scope. ChangesCI optimization
Security policy
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
SECURITY.md (1)
21-21: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winClarify support for released versions.
“Only the latest commit on
main” is a moving target and does not tell users whether tagged or released versions receive security fixes. Enumerate supported release lines, or explicitly state that released versions are unsupported.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@SECURITY.md` at line 21, Clarify the security support policy in SECURITY.md by explicitly stating whether tagged or released versions receive security fixes. Replace the ambiguous “latest commit on main” wording with either the supported release lines or a clear statement that released versions are unsupported.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Line 38: Update the CI cache configuration around the Stellar CLI installation
to include Cargo install metadata (~/.cargo/.crates2.json and
~/.cargo/.crates.toml) along with the relevant registry and git cache paths. Pin
the stellar-cli installation to an explicit version and include that version in
the cache key so cache entries are invalidated when the CLI version changes.
---
Nitpick comments:
In `@SECURITY.md`:
- Line 21: Clarify the security support policy in SECURITY.md by explicitly
stating whether tagged or released versions receive security fixes. Replace the
ambiguous “latest commit on main” wording with either the supported release
lines or a clear statement that released versions are unsupported.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a2fd147a-261f-4a14-b166-cb841a8c114b
📒 Files selected for processing (2)
.github/workflows/ci.ymlSECURITY.md
| path: | | ||
| ~/.cargo/registry | ||
| ~/.cargo/git | ||
| ~/.cargo/bin/stellar |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "### workflows"
git ls-files .github/workflows || true
echo "### ci.yml relevant lines"
if [ -f .github/workflows/ci.yml ]; then
nl -ba .github/workflows/ci.yml | sed -n '1,120p'
fi
echo "### stellar/cargo cache references"
rg -n "cargo install|stellar|cache|~/\.cargo|/\.cargo" .github workflow . --glob '!**/node_modules/**' || true
echo "### rust toolchain/version pins near ci"
rg -n "toolchain|stellar-cli|stellar|cargo install" .github workflow . --glob '!**/node_modules/**' || trueRepository: Stellar-Ecosystem/lodestar
Length of output: 156
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "### workflows"
find .github/workflows -maxdepth 1 -type f 2>/dev/null | sort || true
echo "### ci.yml line count and relevant lines"
if [ -f .github/workflows/ci.yml ]; then
wc -l .github/workflows/ci.yml
nl -ba .github/workflows/ci.yml | sed -n '1,140p'
fi
echo "### targeted searches for install/cache paths"
rg -n "cargo install|stellar-cli|stellar|cache|cargo cache|target/action|~/\.cargo|/\.cargo/.crates2.json|/\.cargo/.crates.toml|\.crates2\.json" .github . 2>/dev/null \
| head -n 200 || trueRepository: Stellar-Ecosystem/lodestar
Length of output: 156
🌐 Web query:
docs.rs cargo metadata .crates2.json cargo install caching installed packages
💡 Result:
Cargo uses the.crates2.json and.crates.toml files located in the installation root directory (by default $CARGO_HOME, which is usually $HOME/.cargo) to track packages installed via cargo install [1][2][3][4]. These files are essential metadata for Cargo to identify which packages are already installed, their versions, features, and associated binaries [5][3][6]. If you are using Continuous Integration (CI) and want to cache binaries installed with cargo install to avoid re-downloading and re-compiling them, you must include the following files and directories in your cache [1][7]: -.crates.toml -.crates2.json - bin/ - registry/index/ - registry/cache/ - git/db/ Failing to cache the.crates2.json and.crates.toml files while caching the bin/ folder can lead to errors where Cargo is unaware of the existing binaries and may attempt to re-install them or fail due to conflicts [5][8]. These files should not be edited manually [1][7]. For more information on configuring the installation root and cache behavior, you can refer to the official Cargo documentation regarding the Cargo home directory [1][7].
Citations:
- 1: https://doc.rust-lang.org/cargo/guide/cargo-home.html
- 2: https://rustwiki.org/en/cargo/reference/config.html
- 3: https://doc.rust-lang.org/cargo/commands/cargo-install.html
- 4: https://github.com/rust-lang/cargo/blob/master/doc/man/generated_txt/cargo-install.txt
- 5: Separate error code for
cargo installfailing due to binary already installed rust-lang/cargo#11513 - 6: https://dev-doc.rust-lang.org/stable/cargo/commands/cargo-install.html
- 7: https://dev-doc.rust-lang.org/nightly/cargo/guide/cargo-home.html
- 8: request: faster, more idempotent binary installs rust-lang/cargo#11959
🌐 Web query:
GitHub actions cache Rust Cargo install ~./cargo/.crates2.json ~/.cargo/registry/src
💡 Result:
To cache Rust Cargo dependencies in GitHub Actions, it is standard practice to cache specific directories within ~/.cargo/ and the local target/ directory [1][2][3]. While you can manually configure actions/cache, many developers prefer using specialized community actions like Swatinem/rust-cache to manage complex caching logic and avoid common issues like cache bloat [4][5][6]. Standard Caching Paths If using actions/cache, typically include the following paths [1][2][3]: ~/.cargo/registry/index ~/.cargo/registry/cache ~/.cargo/git/db target/ Regarding your specific query about ~/.cargo/registry/src: Generally, it is not recommended to cache ~/.cargo/registry/src [4]. Cargo is designed to efficiently recreate the contents of this directory from the compressed crate archives stored in ~/.cargo/registry/cache [4]. Caching the src directory is typically unnecessary and can increase the time required to upload and download the cache [4]. Best Practices Use a lockfile for keys: Always include the hash of your Cargo.lock file in your cache key to ensure the cache is invalidated when dependencies change [2][7][3]. Example: key: ${{ runner.os }}-cargo-${{ hashFiles('/Cargo.lock') }} [2][3]. Consider specialized actions: Community actions like Swatinem/rust-cache are often recommended because they handle "smart" caching, such as pruning unnecessary build artifacts from target/ that change every commit and would otherwise bloat your cache [4][8][6]. Use restore-keys: Provide restore-keys to allow for partial cache matches, which helps speed up builds even when an exact lockfile match is not found [7][3][9]. Example using actions/cache: - name: Cache cargo uses: actions/cache@v4 with: path: | ~/.cargo/registry/index ~/.cargo/registry/cache ~/.cargo/git/db target/ key: ${{ runner.os }}-cargo-${{ hashFiles('/Cargo.lock') }} restore-keys: ${{ runner.os }}-cargo-
Citations:
- 1: https://github.com/actions/cache/blob/92f67a482915a145e9372ed84b9e7f13538ecc69/examples.md
- 2: https://docs.github.com/actions/tutorials/build-and-test-code/building-and-testing-rust
- 3: https://www.rustfaq.org/en/how-to-cache-cargo-builds-in-ci-for-faster-pipelines/
- 4: https://github.com/swatinem/rust-cache
- 5: https://microsoft.github.io/RustTraining/engineering-book/ch11-putting-it-all-together-a-production-cic.html
- 6: https://gitspider.com/guides/github-actions-cache-cargo-rust
- 7: https://github.com/actions/cache/blob/main/caching-strategies.md
- 8: https://github.com/Swatinem/rust-cache/
- 9: https://rust.code-maven.com/github-actions
🌐 Web query:
Cargo install --version caching crate source ~/.cargo source git crates2.json
💡 Result:
Cargo uses its home directory ($HOME/.cargo/ by default) to manage a cache of crates, sources, and registry indices [1]. When you use cargo install, Cargo tracks the installed binaries and their metadata in hidden files within this directory [2][1]. Key components of Cargo's caching mechanism include: Crate Source Caching: Cargo maintains a local registry index and a cache of downloaded crate tarballs (.crate files) in $CARGO_HOME/registry/cache/ [1][3]. When a crate is needed, it is downloaded and then unpacked into $CARGO_HOME/registry/src/ [1][4]. If a version is already present in these locations, Cargo skips the download and extraction steps to save time [4]. Git Source Caching: For crates installed via the --git flag, Cargo clones the remote git repository into $CARGO_HOME/git/db/ and checks out the required commit, branch, or tag into $CARGO_HOME/git/checkouts/ [1]. Tracking Installations (.crates2.json): The file $CARGO_HOME/.crates2.json (along with .crates.toml) is a critical metadata file used by Cargo to track which packages are installed via cargo install [2][1]. It records details about the installed binaries and their sources [1]. Important Note: You should never edit these files manually [1]. If you need to cache binaries installed with cargo install for CI/CD environments, you must preserve the following components of your $CARGO_HOME: * bin/ *.crates.toml *.crates2.json * registry/index/ * registry/cache/ * git/db/ Using cargo install --version allows you to pin to a specific version or range [5][6], but note that build artifacts generated during installation (the actual compiled binaries) are often placed in a temporary directory by default [5][7]. If you are concerned about build performance in CI, you can influence where these build artifacts are placed by setting the CARGO_TARGET_DIR environment variable [5][7].
Citations:
- 1: https://doc.rust-lang.org/cargo/guide/cargo-home.html
- 2: request: faster, more idempotent binary installs rust-lang/cargo#11959
- 3: https://doc.rust-lang.org/cargo/reference/registries.html
- 4: https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/registry/mod.rs
- 5: https://doc.rust-lang.org/stable/cargo/commands/cargo-install.html
- 6: https://github.com/rust-lang/cargo/blob/master/doc/man/cargo-install.md
- 7: Add an option to
cargo installto specify a cache directory rust-lang/cargo#4725
Cache Cargo install metadata and pin the Stellar CLI version.
GitHub actions/cache restores cache paths before cargo install runs, but unless it includes Cargo’s install metadata (~/.cargo/.crates2.json, ~/.cargo/.crates.toml) and the relevant registry/git cache paths, later cargo install --version invocations can still reinstall or fail over installed binaries. Add the missing home-directory paths to the cache and use a pinned stellar-cli version plus a cache key component for that version.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 38, Update the CI cache configuration
around the Stellar CLI installation to include Cargo install metadata
(~/.cargo/.crates2.json and ~/.cargo/.crates.toml) along with the relevant
registry and git cache paths. Pin the stellar-cli installation to an explicit
version and include that version in the cache key so cache entries are
invalidated when the CLI version changes.
|
Hi @Kureszn, This PR could not be merged because it has merge conflicts with the target branch. Please resolve the merge conflicts, push the updated changes, and the PR can be reviewed and merged. Thank you! |
|
This might be a little error, It states here from my end that there are no conflicts and it can be cleanly merged |
|
There are no conflicts with base branch on my end, it says changes can be cleanly merged. |
2 participants
All necessary files have been set up and every other issue resolved adhering to the acceptance criteria.
Closes #402
Summary by CodeRabbit
Documentation
Chores