Add GitHub Actions workflow for rust-clippy analysis#459
Conversation
This workflow sets up rust-clippy to analyze Rust code on push and pull request events, as well as on a scheduled basis.
📝 WalkthroughWalkthroughA new GitHub Actions workflow ChangesRust Clippy SARIF Analysis Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
There was a problem hiding this comment.
Pull request overview
Adds a dedicated GitHub Actions workflow to run cargo clippy and upload results as SARIF so findings appear in GitHub code scanning for pushes, PRs, and on a schedule.
Changes:
- Introduces
.github/workflows/rust-clippy.ymlto run clippy and emit SARIF viaclippy-sarif. - Uploads the generated SARIF file using
github/codeql-action/upload-sarif@v3. - Configures triggers for
push,pull_request, andschedule.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Run rust-clippy | ||
| run: | ||
| cargo clippy | ||
| --all-features | ||
| --message-format=json | clippy-sarif | tee rust-clippy-results.sarif | sarif-fmt | ||
| continue-on-error: true |
| - name: Install required cargo | ||
| run: cargo install clippy-sarif sarif-fmt |
| - name: Checkout code | ||
| uses: actions/checkout@v4 |
| - name: Install Rust toolchain | ||
| uses: actions-rs/toolchain@16499b5e05bf2e26879000db0c1d13f7e13fa3af #@v1 | ||
| with: | ||
| profile: minimal | ||
| toolchain: stable | ||
| components: clippy | ||
| override: true | ||
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 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/rust-clippy.yml:
- Around line 37-39: The rust-clippy.yml workflow is forcing a stable Rust
toolchain with override: true on lines 37-39, which conflicts with the pinned
version 1.91.1 specified in rust-toolchain.toml. Remove the override: true
setting and change the toolchain specification to use the pinned version from
rust-toolchain.toml (1.91.1) to ensure consistent lint results across local
development and all CI workflows.
- Around line 34-39: Replace the archived and unmaintained actions-rs/toolchain
action with an actively maintained alternative. Remove the current uses
statement pointing to actions-rs/toolchain and replace it with either
dtolnay/rust-toolchain for a lightweight option or
actions-rust-lang/setup-rust-toolchain for a feature-rich alternative with
caching support. Update the with configuration block to match the expected
inputs of your chosen replacement action (the profile, toolchain, components,
and override fields may need adjustment based on the new action's requirements).
- Around line 30-31: The actions/checkout@v4 action in the "Checkout code" step
defaults to persisting authentication tokens in git config. Since this
rust-clippy workflow has no subsequent steps that require authenticated git
operations (no git push or authenticated fetch), add the persist-credentials:
false parameter to the checkout action to disable token persistence and follow
the principle of least privilege for credential exposure.
- Line 31: Replace the GitHub Actions version tags with immutable commit SHAs to
prevent supply-chain drift and ensure workflow reproducibility. In the
`actions/checkout@v4` reference, replace the `@v4` tag with its corresponding
commit SHA. Similarly, identify the action reference at the second location
mentioned in the comment and replace its version tag with the corresponding
commit SHA. This ensures that workflows always run with the exact same code and
prevents accidental updates when tags are moved.
- Around line 41-42: The cargo install command for clippy-sarif and sarif-fmt in
the "Install required cargo" step does not specify explicit versions, causing it
to pull the latest versions on every workflow run. This introduces risk of
breaking changes or unexpected failures. Pin explicit versions by appending
version specifiers (e.g., `@version`) to both clippy-sarif and sarif-fmt in the
cargo install command to ensure reproducible and stable CI runs.
🪄 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
Run ID: 13ddb679-274b-4d76-8767-3cd997dbad44
📒 Files selected for processing (1)
.github/workflows/rust-clippy.yml
| - name: Checkout code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/rust-clippy.ymlRepository: 89jobrien/minibox
Length of output: 2194
🌐 Web query:
actions/checkout v4 persist-credentials default behavior GitHub
💡 Result:
In the actions/checkout v4 GitHub Action, the persist-credentials input defaults to true [1][2]. When this setting is enabled (the default), the action configures the authentication token or SSH key used to check out the repository into the local git configuration [1][2]. This enables your workflow steps to run authenticated git commands (such as git push or git fetch) without requiring additional authentication setup [1][3]. To maintain security, the action automatically removes this token or key from the local git configuration during the post-job cleanup phase [1][4]. If you do not require this functionality, you can opt out by explicitly setting persist-credentials to false in your workflow file [1][5].
Citations:
- 1: https://github.com/actions/checkout/blob/v4/README.md
- 2: https://github.com/actions/checkout/blob/v4/action.yml
- 3: https://github.com/actions/checkout/tree/v4
- 4: https://github.com/actions/checkout/?tab=readme-ov-file
- 5: https://github.com/actions/checkout
Disable checkout credential persistence for least privilege.
actions/checkout@v4 defaults to persisting the authentication token in local git config. This workflow has no subsequent steps requiring authenticated git operations (no git push or authenticated fetch), so set persist-credentials: false to reduce credential exposure.
Suggested change
- name: Checkout code
uses: actions/checkout@v4
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Checkout code | |
| uses: actions/checkout@v4 | |
| - name: Checkout code | |
| uses: actions/checkout@v4 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 30-31: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 31-31: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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/rust-clippy.yml around lines 30 - 31, The
actions/checkout@v4 action in the "Checkout code" step defaults to persisting
authentication tokens in git config. Since this rust-clippy workflow has no
subsequent steps that require authenticated git operations (no git push or
authenticated fetch), add the persist-credentials: false parameter to the
checkout action to disable token persistence and follow the principle of least
privilege for credential exposure.
Source: Linters/SAST tools
| actions: read # only required for a private repository by github/codeql-action/upload-sarif to get the Action run status | ||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "rust-clippy.yml" -type fRepository: 89jobrien/minibox
Length of output: 97
🏁 Script executed:
cat -n .github/workflows/rust-clippy.ymlRepository: 89jobrien/minibox
Length of output: 2194
Pin GitHub Actions by commit SHA to prevent supply-chain drift.
Lines 31 and 52 reference moving tags (@v4, @v3) instead of immutable SHAs. This weakens workflow integrity and breaks reproducibility.
Suggested hardening
- - name: Checkout code
- uses: actions/checkout@v4
+ - name: Checkout code
+ uses: actions/checkout@<pinned-commit-sha>
...
- - name: Upload analysis results to GitHub
- uses: github/codeql-action/upload-sarif@v3
+ - name: Upload analysis results to GitHub
+ uses: github/codeql-action/upload-sarif@<pinned-commit-sha>🧰 Tools
🪛 zizmor (1.25.2)
[warning] 30-31: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 31-31: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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/rust-clippy.yml at line 31, Replace the GitHub Actions
version tags with immutable commit SHAs to prevent supply-chain drift and ensure
workflow reproducibility. In the `actions/checkout@v4` reference, replace the
`@v4` tag with its corresponding commit SHA. Similarly, identify the action
reference at the second location mentioned in the comment and replace its
version tag with the corresponding commit SHA. This ensures that workflows
always run with the exact same code and prevents accidental updates when tags
are moved.
Source: Linters/SAST tools
| uses: actions-rs/toolchain@16499b5e05bf2e26879000db0c1d13f7e13fa3af #@v1 | ||
| with: | ||
| profile: minimal | ||
| toolchain: stable | ||
| components: clippy | ||
| override: true |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
actions-rs/toolchain archived repository status 2024 2025
💡 Result:
The actions-rs/toolchain GitHub repository was officially archived by its owner on October 13, 2023, rendering it read-only [1]. Prior to its archiving, the repository had been widely considered unmaintained for several years [2][3][4]. It stopped receiving updates to address critical issues, such as the deprecation of Node.js 12 (which caused the action to trigger warnings in GitHub Actions workflows) [2][3] and the deprecation of the set-output command [2]. Because of this lack of maintenance and eventual archiving, the community and industry documentation recommend migrating to alternative actions [5]. A widely accepted and actively maintained alternative is dtolnay/rust-toolchain [2][5][6]. As of June 2026, the original actions-rs/toolchain repository remains archived and should not be used in active projects [1]. While various forks and replacements exist (such as step-security/actions-rs-toolchain [7] and others [8]), dtolnay/rust-toolchain remains a standard recommendation for setting up Rust toolchains in GitHub Actions [5][6].
Citations:
- 1: https://p.rst.im/q/GitHub.Com/actions-rs/toolchain
- 2:
set-outputcommand is deprecated actions-rs/toolchain#221 - 3: Node.JS 12 deprecation on GitHub Actions actions-rs/toolchain#219
- 4: Project unmaintained actions-rs/toolchain#216
- 5: https://rustprojectprimer.com/ci/github.html
- 6: Properly remove all deprecations actions-rs/toolchain#224
- 7: https://github.com/step-security/actions-rs-toolchain
- 8: https://github.com/figma/actions-toolchain
🌐 Web query:
GitHub Actions rust toolchain setup alternatives dtolnay actions-rs-toolchain
💡 Result:
For GitHub Actions Rust toolchain setup, the legacy actions-rs/toolchain is deprecated and archived [1]. As of June 2026, the primary alternatives are: 1. dtolnay/rust-toolchain [2]: A lightweight, concise, and widely used action. It is highly stable and frequently used for its simplicity [2][3][4]. 2. actions-rust-lang/setup-rust-toolchain [5][6]: A feature-rich alternative inspired by dtolnay/rust-toolchain. It includes built-in support for caching (via Swatinem/rust-cache), problem matchers for build and formatting errors, and CI-optimized defaults (like disabling incremental compilation) [5][6][4]. Recent migration trends often favor actions-rust-lang/setup-rust-toolchain for projects that benefit from its integrated caching and error diagnostics [7][8]. Conversely, dtolnay/rust-toolchain remains preferred by teams desiring a minimal, "bare-bones" dependency [4]. For organizations or projects requiring specialized features, other community alternatives exist, such as crustacean-dev/setup-rust, which bundles additional binary installation and caching features [9]. Recommendations for selection: - Use dtolnay/rust-toolchain if you prefer a minimal, low-overhead action [2][4]. - Use actions-rust-lang/setup-rust-toolchain if you want integrated caching, better error visibility via problem matchers, and CI-optimized environment settings [5][6][4]. - Always verify your choice by checking if your project already uses Swatinem/rust-cache separately; if it does, ensure you configure caching correctly in the setup action to avoid duplicate cache layers [7][8].
Citations:
- 1: https://p.rst.im/q/github.com/actions-rs/toolchain
- 2: https://github.com/dtolnay/rust-toolchain
- 3: Properly remove all deprecations actions-rs/toolchain#224
- 4: Project unmaintained actions-rs/toolchain#216
- 5: https://github.com/actions-rust-lang/setup-rust-toolchain/blob/main/README.md
- 6: https://github.com/actions-rust-lang/setup-rust-toolchain
- 7: fix(ci): replace dtolnay/rust-toolchain with actions-rust-lang/setup-rust-toolchain larsw/rdfless#59
- 8: junyeong-ai/slack-cli@1f9a352
- 9: https://github.com/crustacean-dev/setup-rust
Replace archived actions-rs/toolchain with an actively maintained alternative.
The actions-rs/toolchain action at line 34 is from a repository archived on October 13, 2023, and is no longer maintained. Consider migrating to dtolnay/rust-toolchain (lightweight option) or actions-rust-lang/setup-rust-toolchain (feature-rich with integrated caching and error matchers).
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 34-34: action or reusable workflow from archived repository (archived-uses): repository is archived
(archived-uses)
🤖 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/rust-clippy.yml around lines 34 - 39, Replace the archived
and unmaintained actions-rs/toolchain action with an actively maintained
alternative. Remove the current uses statement pointing to actions-rs/toolchain
and replace it with either dtolnay/rust-toolchain for a lightweight option or
actions-rust-lang/setup-rust-toolchain for a feature-rich alternative with
caching support. Update the with configuration block to match the expected
inputs of your chosen replacement action (the profile, toolchain, components,
and override fields may need adjustment based on the new action's requirements).
Source: Linters/SAST tools
| toolchain: stable | ||
| components: clippy | ||
| override: true |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate and read the rust-toolchain.toml file
find . -name "rust-toolchain.toml" -type fRepository: 89jobrien/minibox
Length of output: 83
🏁 Script executed:
# Read the rust-clippy workflow file to verify lines 37-39
cat -n .github/workflows/rust-clippy.ymlRepository: 89jobrien/minibox
Length of output: 2194
🏁 Script executed:
# Read the rust-toolchain.toml file to verify the pinned version
cat -n ./rust-toolchain.tomlRepository: 89jobrien/minibox
Length of output: 148
Use the repository-pinned Rust toolchain instead of forcing stable.
rust-toolchain.toml pins 1.91.1 with clippy, but this workflow forces stable with override: true on lines 37–39. This mismatch can produce different lint results from the pinned version used in local development and other CI workflows.
🤖 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/rust-clippy.yml around lines 37 - 39, The rust-clippy.yml
workflow is forcing a stable Rust toolchain with override: true on lines 37-39,
which conflicts with the pinned version 1.91.1 specified in rust-toolchain.toml.
Remove the override: true setting and change the toolchain specification to use
the pinned version from rust-toolchain.toml (1.91.1) to ensure consistent lint
results across local development and all CI workflows.
| - name: Install required cargo | ||
| run: cargo install clippy-sarif sarif-fmt |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
clippy-sarif crate versions history stability breaking changes
💡 Result:
The clippy-sarif crate is a command-line utility used to convert cargo clippy diagnostic output into the Static Analysis Results Interchange Format (SARIF) [1][2]. It is part of the sarif-rs project, a collection of Rust-based tools for interacting with the SARIF format [3]. Version History and Stability As of June 2026, the latest version of clippy-sarif is 0.8.0, which was released on May 9, 2025 [1][4]. The project maintains an active release cycle, with the repository being updated regularly [5]. While the crate provides stable functionality for its core use case (converting clippy output to SARIF), it does not explicitly guarantee long-term SemVer stability for its internal APIs [5]. Users should consult the project's repository and changelogs when upgrading, as breaking changes have been introduced in past versions [6]. Breaking Changes Significant breaking changes have occurred during the project's development. For instance, in version 0.8.0, the project migrated to using TypedBuilder instead of the previous Builder pattern [6]. Users integrating this crate into larger systems or relying on its library components should review the release notes on the sarif-rs GitHub repository to identify specific migration steps when moving between major or minor versions [5][6]. Usage and Integration The tool is primarily intended for use as a CLI utility [2]. The standard usage involves piping the output of cargo clippy into the tool: cargo clippy --message-format=json | clippy-sarif This is frequently used in CI/CD pipelines, such as GitHub Actions, to integrate clippy diagnostics into tools like GitHub Advanced Security (GHAS) [1]. Installation is supported via cargo install, cargo-binstall, or by downloading binaries directly from the project's GitHub releases [1][2].
Citations:
- 1: https://crates.io/crates/clippy-sarif
- 2: https://lib.rs/crates/clippy-sarif
- 3: https://psastras.github.io/sarif-rs/docs/getting-started/introduction/
- 4: https://newreleases.io/project/github/psastras/sarif-rs/release/clippy-sarif-v0.8.0
- 5: https://github.com/psastras/sarif-rs
- 6: https://github.com/psastras/sarif-rs/releases/tag/miri-sarif-latest
🌐 Web query:
sarif-fmt crate versions history
💡 Result:
The sarif-fmt crate, a command-line tool for formatting SARIF files, has been active since June 2021 [1]. As of June 14, 2026, the latest version is 0.8.0, released on May 9, 2025 [2][1]. The crate has undergone numerous releases over its history [2]. Notable recent version releases include: - 0.8.0: May 9, 2025 [2][1] - 0.7.0: December 18, 2024 [1] - 0.6.6: September 2, 2024 [1] - 0.6.5: August 6, 2024 [1] - 0.6.0: July 30, 2024 [1] - 0.5.0: July 8, 2024 [1] The crate has accumulated over 39 total releases since its inception [2]. Detailed version history, including metadata for older releases, is available through the official crates.io registry [1].
Citations:
🌐 Web query:
cargo install --locked flag documentation behavior
💡 Result:
cargo install --locked documentation/behavior (as of 2026-06-14) 1) What --locked is documented to do - For cargo install, by default Cargo ignores any Cargo.lock file bundled with the package, and recomputes dependency versions. - The --locked flag makes Cargo use the packaged Cargo.lock file if it is available, asserting that the exact same dependencies and versions are used as when that Cargo.lock was originally generated. It is intended for reproducible/deterministic builds (e.g., CI). [1][2] 2) When --locked errors (per documentation) - The docs state that Cargo will exit with an error if either: a) the lock file is missing, or b) Cargo attempted to change the lock file due to different dependency resolution. [1][2] 3) Relationship to --frozen / --offline - For cargo install, the docs also state that --frozen is equivalent to specifying both --locked and --offline. [1][2] 4) Noted documentation/behavior nuances (community reports) - There is an open/recorded discussion that the documentation around cargo install --locked with a missing lock file is contradictory (“if it is available” vs “Cargo will exit with an error … The lock file is missing”). [3] - Another issue notes that for cargo install, --locked uses the lockfile bundled with the crate being installed (not necessarily the lockfile of the current working directory). [4] So, the core documented behavior is: cargo install ignores a bundled Cargo.lock unless you pass --locked; with --locked, Cargo uses the packaged lockfile and Cargo is supposed to error if the lockfile is missing or would need to change due to different dependency resolution. [1][2]
Citations:
- 1: https://dev-doc.rust-lang.org/stable/cargo/commands/cargo-install.html
- 2: https://doc.rust-lang.org/cargo/commands/cargo-install.html
- 3: Contradictory documentation for
cargo install --lockedbehavior with missing lock file rust-lang/cargo#16649 - 4:
cargo install --lockedis not really locked rust-lang/cargo#9289
Pin clippy-sarif and sarif-fmt versions for reproducible CI.
Unpinned cargo install pulls latest crates on every run. Version 0.8.0 (May 2025) of both tools introduced breaking changes; future releases may break output format or fail unexpectedly. Pin explicit versions.
Suggested change
- - name: Install required cargo
- run: cargo install clippy-sarif sarif-fmt
+ - name: Install required cargo
+ run: cargo install clippy-sarif --version 0.8.0 sarif-fmt --version 0.8.0 --locked📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Install required cargo | |
| run: cargo install clippy-sarif sarif-fmt | |
| - name: Install required cargo | |
| run: cargo install clippy-sarif --version 0.8.0 sarif-fmt --version 0.8.0 --locked |
🤖 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/rust-clippy.yml around lines 41 - 42, The cargo install
command for clippy-sarif and sarif-fmt in the "Install required cargo" step does
not specify explicit versions, causing it to pull the latest versions on every
workflow run. This introduces risk of breaking changes or unexpected failures.
Pin explicit versions by appending version specifiers (e.g., `@version`) to both
clippy-sarif and sarif-fmt in the cargo install command to ensure reproducible
and stable CI runs.
This workflow sets up rust-clippy to analyze Rust code on push and pull request events, as well as on a scheduled basis.
Summary by CodeRabbit