From 43b560c2ea585eef61b8d389f85504a75ffaea60 Mon Sep 17 00:00:00 2001 From: Kaur Kuut Date: Sun, 1 Feb 2026 00:47:40 +0200 Subject: [PATCH] Describe Prep in `README.md`. --- README.md | 24 ++++++++++++++++++++++++ prep/README.md | 24 ++++++++++++++++++++++++ 2 files changed, 48 insertions(+) diff --git a/README.md b/README.md index 771abb7..ff76a0f 100644 --- a/README.md +++ b/README.md @@ -10,6 +10,30 @@ +Prep is a cross-platform CLI tool that provides Rust workspace verification in single short command. +You can just invoke `prep ci` and if the checks succeed then you can rest easy knowing that your PR won't fail CI. + +## Motivation + +Rust projects tend to have a wide variety of fairly complicated verification steps in CI. +These steps help ensure that the project stays consistent and keeps working in various scenarios. + +However, these CI steps are either written as GitHub Action YAML files or as Bash scripts. +Running GitHub Actions requires a rather heavyweight Docker image, which expects a Unix userland, just like Bash scripts. +Additionally, they target ephemeral VMs, so they do a lot of tooling setup that isn't efficient for a local machine. +All of that meaning that you're really out of luck on Windows and even on Unix it's going to be needlessly cumbersome. + +So you need to analyze the specifics of a project's CI and craft custom local scripts to emulate the CI steps. +That, or you just manually invoke a few Cargo commands and hope for the best, leading to frequent CI failures on your PRs. +Which sucks because CI tends to run at a lot slower speed than your local machine, especially due to cold build cache. + +## Prep to the rescue + +Before opening a PR you can just run `prep ci` locally and verify that everything matches CI expectations. +Because Prep aims for a rather robust set of verifications this will be beneficial even when the project still uses custom CI scripts. +However, for best results the project itself should run `prep ci` in its CI instead of custom scripts. +That way the only problems that remain uncaught locally are platform specific, which the CI will catch with its multi-platform job matrix. + ## Installation ```sh diff --git a/prep/README.md b/prep/README.md index a3ba0aa..33c5e31 100644 --- a/prep/README.md +++ b/prep/README.md @@ -10,6 +10,30 @@ +Prep is a cross-platform CLI tool that provides Rust workspace verification in single short command. +You can just invoke `prep ci` and if the checks succeed then you can rest easy knowing that your PR won't fail CI. + +## Motivation + +Rust projects tend to have a wide variety of fairly complicated verification steps in CI. +These steps help ensure that the project stays consistent and keeps working in various scenarios. + +However, these CI steps are either written as GitHub Action YAML files or as Bash scripts. +Running GitHub Actions requires a rather heavyweight Docker image, which expects a Unix userland, just like Bash scripts. +Additionally, they target ephemeral VMs, so they do a lot of tooling setup that isn't efficient for a local machine. +All of that meaning that you're really out of luck on Windows and even on Unix it's going to be needlessly cumbersome. + +So you need to analyze the specifics of a project's CI and craft custom local scripts to emulate the CI steps. +That, or you just manually invoke a few Cargo commands and hope for the best, leading to frequent CI failures on your PRs. +Which sucks because CI tends to run at a lot slower speed than your local machine, especially due to cold build cache. + +## Prep to the rescue + +Before opening a PR you can just run `prep ci` locally and verify that everything matches CI expectations. +Because Prep aims for a rather robust set of verifications this will be beneficial even when the project still uses custom CI scripts. +However, for best results the project itself should run `prep ci` in its CI instead of custom scripts. +That way the only problems that remain uncaught locally are platform specific, which the CI will catch with its multi-platform job matrix. + ## Installation ```sh