Skip to content

Add GitHub Actions workflow for rust-clippy analysis #459

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
89jobrien wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add GitHub Actions workflow for rust-clippy analysis #459

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions .github/workflows/rust-clippy.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# rust-clippy is a tool that runs a bunch of lints to catch common
# mistakes in your Rust code and help improve your Rust code.
# More details at https://github.com/rust-lang/rust-clippy
# and https://rust-lang.github.io/rust-clippy/

name: rust-clippy analyze

on:
push:
branches: [ "main", "next" ]
pull_request:
# The branches below must be a subset of the branches above
branches: [ "main" ]
schedule:
- cron: '19 14 * * 3'

jobs:
rust-clippy-analyze:
name: Run rust-clippy analyzing
runs-on: ubuntu-latest
permissions:
contents: read
security-events: write
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
Comment on lines +30 to +31
Comment on lines +30 to +31

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/rust-clippy.yml

Repository: 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:

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.

Suggested change
- 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

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -name "rust-clippy.yml" -type f

Repository: 89jobrien/minibox

Length of output: 97

🏁 Script executed:

cat -n .github/workflows/rust-clippy.yml

Repository: 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


- name: Install Rust toolchain
uses: actions-rs/toolchain@16499b5e05bf2e26879000db0c1d13f7e13fa3af #@v1
with:
profile: minimal
toolchain: stable
components: clippy
override: true
Comment on lines +34 to +39

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 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:

🌐 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:

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

Comment on lines +37 to +39

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, locate and read the rust-toolchain.toml file
find . -name "rust-toolchain.toml" -type f

Repository: 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.yml

Repository: 89jobrien/minibox

Length of output: 2194

🏁 Script executed:

# Read the rust-toolchain.toml file to verify the pinned version
cat -n ./rust-toolchain.toml

Repository: 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.


Comment on lines +33 to +40
- name: Install required cargo
run: cargo install clippy-sarif sarif-fmt
Comment on lines +41 to +42
Comment on lines +41 to +42

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 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:

🌐 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:

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.

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
🤖 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.


- 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
Comment on lines +44 to +49

- name: Upload analysis results to GitHub
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: rust-clippy-results.sarif
wait-for-processing: true
Loading