fix(ci-templates): default install command to shipper, not shipper-cli#151
Conversation
Surfaced by the post-rc.2 docs sweep. The `shipper ci` subcommand generates CI workflow snippets for GitLab, CircleCI, and Azure DevOps — all three still printed `cargo install shipper-cli --locked` as the install step, which doesn't match the three-crate story that #95 landed. `shipper` is the recommended install path; `shipper-cli` is a real adapter crate that users can still install directly if they want the adapter binary, not a deprecated shim. Update the three CI generators to print `cargo install shipper --locked` and refresh the matching insta snapshots. The github-actions template already assumed `shipper` on PATH, so no change there. Also loosens wording in the lib.rs module doc: the `shipper-cli` binary is not there "for backward compatibility" — it's the adapter crate shipping its own binary that wraps run(). That's a real, first-class install path, not a back-compat shim. No effect on crates.io rc.2 artifacts (0.3.0-rc.2 already shipped). Will land in rc.3 / 0.3.0. Verified: - cargo check -p shipper-cli clean - 129 e2e_expanded tests pass (including the 3 updated snapshots)
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (1)
Summary by CodeRabbitDocumentation
WalkthroughUpdated crate-level documentation in Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
There was a problem hiding this comment.
Code Review
This pull request updates the documentation and CI configuration generation logic to recommend installing the shipper crate instead of shipper-cli. This change ensures that users are directed to the primary installation face of the tool, as defined in the project's architecture. Corresponding test snapshots for Azure DevOps, CircleCI, and GitLab have been updated to reflect this change. I have no feedback to provide.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Summary
Post-rc.2 docs sweep caught that the
shipper cisubcommand generators for GitLab, CircleCI, and Azure DevOps still printedcargo install shipper-cli --lockedas the install step. The three-crate story madeshipperthe recommended install path; these templates were stale.What changed
crates/shipper-cli/src/lib.rs— threecargo install shipper-cli --lockedstrings →cargo install shipper --locked(GitLab, CircleCI, Azure DevOps templates). GitHub Actions template already assumedshipperon PATH.shipper-clibinary is the adapter crate's own binary, not a back-compat shim.instasnapshots refreshed to match.Context
The post-rc.2 smoke installs confirmed:
cargo install shipper --version 0.3.0-rc.2 --locked→ works,shipper 0.3.0-rc.2cargo install shipper-cli --version 0.3.0-rc.2 --locked→ works, same code pathshipper-core = "0.3.0-rc.2"embedder compile → no clap/indicatif in dep graphSo the product story is correct on crates.io; this PR closes the last place in the repo that still told users the wrong install command.
Test plan
cargo check -p shipper-clicleancargo test -p shipper-cli --test e2e_expanded— 129 passed (including the 3 updated snapshots)grep -rn "cargo install shipper-cli --locked" crates/— no matches outside intentional adapter-path references