CI: Add Rust coverage job to CI workflows

[qnixsynapse]

Describe Your Changes

• Introduces a dedicated job (base_branch_rust_cov) to run Rust test coverage checks against the base branch when a pull request is opened. This ensures that the Rust component's test coverage is available for comparison against the existing codebase coverage, providing a more comprehensive review pipeline.

Fixes Issues

• Closes #
• Closes #

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

[tokamak-pm]

Code Review — first review

Summary

This PR adds a base_branch_rust_cov job that runs Rust test coverage on the base branch (via cargo-llvm-cov), then merges Rust + TypeScript lcov reports in the coverage-check job for a unified comparison.

Observations

Correctness

• The approach of generating separate Rust lcov on the base branch and then merging with TS coverage in coverage-check is sound.
• The cat merge strategy (cat ./coverage/lcov.info rust-lcov.info > merged-lcov.info) is a valid way to concatenate lcov files. Since Rust and TypeScript source paths never overlap, simple concatenation works correctly here.

Duplication of Rust coverage commands

• The exact same 6-line Rust coverage block (clean, 4 cov runs, report) appears twice: once in base_branch_rust_cov and again in coverage-check. Consider extracting this into a reusable composite action or at least a shared script (e.g., scripts/rust-coverage.sh) to reduce maintenance burden. If the manifest paths or flags ever change, you would need to update them in two places.

Duplication of Tauri dependency installation

• The Install Tauri dependencies step is duplicated verbatim in base_branch_rust_cov and coverage-check. Same suggestion: extract into a composite action or shared step.

actions/checkout@v3 vs @v4

• The new base_branch_rust_cov job uses actions/checkout@v3. The rest of the workflow also uses @v3, so this is consistent. However, v3 is deprecated in favor of v4 — consider upgrading across the board as a follow-up.

continue-on-error: true on the job

• This means if Rust coverage generation fails on the base branch, the entire pipeline still proceeds. In coverage-check, the needs: [base_branch_cov, base_branch_rust_cov] dependency means coverage-check will still run even if base_branch_rust_cov fails. However, the Download Rust code coverage report from base branch step will then fail (artifact won't exist). This step does not have continue-on-error, so it will break the coverage-check job when Rust cov fails. Consider either adding continue-on-error: true on that download step, or adding a conditional check for the artifact existence.

CLAUDE.md in .gitignore

• The .gitignore addition of CLAUDE.md is unrelated to the CI coverage changes. This is fine but should probably be in a separate commit for cleanliness.

No test changes

• This is purely a CI workflow change, so no application-level tests are needed.

Risks

• The Rust compilation + test step on ubuntu-latest can be slow (10-20+ min for a Tauri project). This will add wall-clock time to PRs. The continue-on-error: true mitigates blocking, but the runner cost is non-trivial.
• If the base_branch_rust_cov artifact is missing (job failed or skipped), the download in coverage-check will hard-fail. This is a real risk given continue-on-error: true on the producer job.

Suggestions

1. Add continue-on-error: true or an if: success() guard on the "Download Rust code coverage report from base branch" step in coverage-check to gracefully handle missing artifacts.
2. Extract the repeated Rust coverage steps into a shared script or composite action.
3. Consider caching ~/.cargo and target/ directories to speed up the Rust build.

Recommendation: improve needed

[github-actions]

Barecheck - Code coverage report

Total: 23.78%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered