fix(ci): Correctly update and restore cache for lint:cpp-static-check's generated files .

[sitaowang1998]

Description

#197 added caching of lint:cpp-static-check in GitHub workflow, which does not correctly insert new caches. The cache created are immutable, but we save cache using the same key, and the cache save failed. Thus, the GitHub workflow are using an obsolete cache that are create.

This PR fixes this issue by appending the has of the cache content to the key. When restoring the cache, we use a prefix of that key, and actions/cache/restore will automatically select the newest entry.

Checklist

• The PR satisfies the contribution guidelines.
• This is a breaking change and that has been indicated in the PR title, OR this isn't a
  breaking change.
• Necessary docs have been updated, OR no docs need to be updated.

Validation performed

• Merged into main in my fork.
• New cache was created on push.
• Changed a C++ file and pushed again. The trigger workflow was restored cache successfully. Only the changed file is checked by clang-tidy, and the runtime drops from 54 minutes to 16 minutes.

Summary by CodeRabbit

• Chores
  • Updated continuous integration caching strategy to improve build efficiency and consistency in the development workflow.

[coderabbitai]

Walkthrough

GitHub Actions workflow configuration updated to replace static cache keys with hash-based keys that incorporate checksums of relevant files for the C++ static linting task, maintaining consistent key generation across cache restoration and saving steps.

Changes

Cohort / File(s)	Summary
CI/CD Workflow Configuration \.github/workflows/code-linting-checks\.yaml	Updated cache key for C++ static linting check from fixed main-branch string to dynamic hash-based key incorporating multiple checksum files and lint target directory. Renamed cache key identifier to lint:check-cpp-static-on-ubuntu-latest. Applied block scalar syntax for multi-line hashFiles() composition.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Areas requiring attention:

• Verification that the new hash-based cache key correctly includes all necessary input files for invalidation detection
• Confirmation that the hashFiles() expression syntax is valid and references correct file paths
• Validation that cache key naming convention aligns with project standards

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing the cache key strategy for the lint:cpp-static-check job to enable proper cache updates and restoration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b34204b and 564d09e.

📒 Files selected for processing (1)

• .github/workflows/code-linting-checks.yaml (2 hunks)

🔇 Additional comments (2)

.github/workflows/code-linting-checks.yaml (2)

57-66: Cache restoration strategy looks good.

The restore step uses a fixed key that will first search for an exact match, then for partial (prefix) matches of the key. This complements the save step's hash-based key approach, allowing new caches to be created when files change while reusing the newest existing cache during subsequent runs.

---

73-86: Hash-based cache key strategy is sound.

The save step correctly appends a hash of relevant files to create unique cache entries per build state, enabling cache invalidation when dependencies or source files change. The cache restore action will locate the newest matching entry when multiple prefix matches exist. The glob patterns are valid and match the checksum files and build artifacts appropriately.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining why this PR is needed, why this solution was chosen, and what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}