|
| 1 | +<div align="center"> |
| 2 | + |
| 3 | +# Prep |
| 4 | + |
| 5 | +**Prepare Rust projects for greatness** |
| 6 | + |
| 7 | +[](https://crates.io/crates/prep) |
| 8 | +[](https://deps.rs/crate/prep) |
| 9 | +[](#license) |
| 10 | + |
| 11 | +</div> |
| 12 | + |
| 13 | +Prep is a cross-platform CLI tool that provides Rust workspace verification in a single short command. |
| 14 | +You can just invoke `prep ci` and if the checks succeed then you can rest easy knowing that your PR won't fail CI. |
| 15 | + |
| 16 | +The latest version is [0.1.0] which was published on 2026-01-31. |
| 17 | +You can read about the changes in the [changelog]. |
| 18 | + |
| 19 | +## Motivation |
| 20 | + |
| 21 | +Rust projects tend to have a wide variety of fairly complicated verification steps in CI. |
| 22 | +These steps help ensure that the project stays consistent and keeps working in various scenarios. |
| 23 | + |
| 24 | +However, these CI steps are either written as GitHub Action YAML files or as Bash scripts. |
| 25 | +Running GitHub Actions requires a rather heavyweight Docker image, which expects a Unix userland, just like Bash scripts. |
| 26 | +Additionally, they target ephemeral VMs, so they do a lot of tooling setup that isn't efficient for a local machine. |
| 27 | +All of that meaning that you're really out of luck on Windows and even on Unix it's going to be needlessly cumbersome. |
| 28 | + |
| 29 | +So you need to analyze the specifics of a project's CI and craft custom local scripts to emulate the CI steps. |
| 30 | +That, or you just manually invoke a few Cargo commands and hope for the best, leading to frequent CI failures on your PRs. |
| 31 | +Which sucks because CI tends to run at a lot slower speed than your local machine, especially due to cold build cache. |
| 32 | + |
| 33 | +## Prep to the rescue |
| 34 | + |
| 35 | +Before opening a PR you can just run `prep ci` locally and verify that everything matches CI expectations. |
| 36 | +Because Prep aims for a rather robust set of verifications this will be beneficial even when the project still uses custom CI scripts. |
| 37 | +However, for best results the project itself should run `prep ci` in its CI instead of custom scripts. |
| 38 | +That way the only problems that remain uncaught locally are platform specific, which the CI will catch with its multi-platform job matrix. |
| 39 | + |
| 40 | +## Installation |
| 41 | + |
| 42 | +```sh |
| 43 | +cargo install prep --locked |
| 44 | +``` |
| 45 | + |
| 46 | +## Usage |
| 47 | + |
| 48 | +``` |
| 49 | +Usage: prep [command] [options] |
| 50 | +
|
| 51 | +Commands: |
| 52 | + ci Verify for CI. |
| 53 | + clp clippy Analyze with Clippy. |
| 54 | + fmt format Format with rustfmt. |
| 55 | + help Print help for the provided command. |
| 56 | +
|
| 57 | +Options: |
| 58 | + -h --help Print help for the provided command. |
| 59 | + -V --version Print version information. |
| 60 | +``` |
| 61 | + |
| 62 | +## License |
| 63 | + |
| 64 | +Licensed under either of |
| 65 | + |
| 66 | +- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or <http://www.apache.org/licenses/LICENSE-2.0>) |
| 67 | +- MIT license ([LICENSE-MIT](LICENSE-MIT) or <http://opensource.org/licenses/MIT>) |
| 68 | + |
| 69 | +at your option. |
| 70 | + |
| 71 | +[0.1.0]: https://github.com/Nevermore/prep/releases/tag/v0.1.0 |
| 72 | +[changelog]: prep/CHANGELOG.md |
0 commit comments