Adopt the Whitaker Dylint suite in the lint gate and CI - #15
Conversation
Align the repository with the estate-wide Whitaker rollout pattern established in leynos/netsuke#410. The repository skeleton already ran Whitaker in `make lint` and CI, but it installed the installer from a pinned git revision and carried bespoke PATH-resolution plumbing in the Makefile. - Simplify the Makefile to the standard `WHITAKER ?= whitaker` tool variable and drop the USER_WHITAKER/USER_BIN_PATH indirection; the lint recipe now invokes the wrapper directly after Clippy with warnings denied, matching the other tool variables. - Replace the git-revision installer in CI with the released whitaker-installer 0.2.5 via `cargo binstall` (provided by the shared setup-rust action), caching only the installer binary and the cargo-binstall cache under the estate-standard cache key. The suite reports no findings on this codebase, so no code changes or dylint.toml exclusions were required.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 7 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 23db8a04b1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
This project builds with the Cranelift debug backend, so the Dylint driver's pinned nightly needs `rustc-codegen-cranelift` installed. Restore the installer's `--cranelift` flag, which the standardized install step had dropped.
Pass WHITAKER_INSTALLER_VERSION to the run block through the shell
environment rather than inline `${{ env }}` template expansion, which
zizmor flags as a template-injection risk; the job-level `env:` block
already exports the variable. Add `--locked` to the cargo binstall
invocation so that its compile-from-source fallback resolves
dependencies from the published lockfile, keeping fallback builds
reproducible.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
1 participant
Summary
This pull request aligns rentaneko with the estate-wide rollout of the
Whitaker Dylint suite (see leynos/netsuke#410 for the reference
adoption). The repository skeleton already ran Whitaker in
make lintand in CI, but it installed the installer from a pinned git revision and
carried bespoke PATH-resolution plumbing in the Makefile. Both are now
replaced with the standard pattern: a plain
WHITAKER ?= whitakertoolvariable, and installation of the released whitaker-installer 0.2.5 via
cargo binstallwith the estate-standard cache key. The suite reportsno findings on this codebase, so no code changes or
dylint.tomlexclusions were required.
Review walkthrough
Makefile:the
WHITAKERvariable is simplified towhitaker, theUSER_WHITAKERandUSER_BIN_PATHindirection is removed, and thelintrecipe invokes the wrapper directly after Clippy with warningsdenied. The target's help text now mentions the Whitaker suite.
.github/workflows/ci.yml:the
WHITAKER_INSTALLER_REVgit pin is replaced byWHITAKER_INSTALLER_VERSION: '0.2.5'; the cache step now stores only~/.cargo/bin/whitaker-installerand~/.cache/cargo-binstallunderthe
whitaker-installer-<os>-<arch>-<version>key; and the installstep uses
cargo binstall(provided by the shared setup-rust action)with an idempotence guard.
Validation
make check-fmt lint— passes; Clippy and the Whitaker suite bothreport no findings (
whitaker --all -- --all-targets --all-featureswith
RUSTFLAGS="-D warnings").make typecheck test— passes; 1 test run via nextest, doc-testsclean.
make markdownlint— passes; 17 files, 0 errors.make nixie— passes; all Mermaid diagrams validated.mbake validate Makefile— valid syntax.