chore: cargo-ox-check, unified Rust build/CI scaffolding tool#25
chore: cargo-ox-check, unified Rust build/CI scaffolding tool#25martin-kolinek wants to merge 9 commits into
Conversation
martin-kolinek
changed the title
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #25 +/- ##
========================================
- Coverage 99.6% 86.4% -13.2%
========================================
Files 11 16 +5
Lines 1847 665 -1182
========================================
- Hits 1840 575 -1265
- Misses 7 90 +83 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
The previous text claimed ust-toolchain.toml-driven auto-install was cached across subsequent runs. It is not — ~/.rustup is not in the cache key set by ox-ci-setup, so the toolchain download runs once per job. Cost is small relative to the cached cargo registry / target paths, so the design choice is fine, but the docs shouldn't claim a cache hit that doesn't exist. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Microsoft/ox-tools (where cargo-ox-ci lives) uses `cargo ox-ci update` to
manage its own CI. Every PR runs the regenerate-check gate: build the binary
from source, run `update`, `git diff --exit-code`. A catalog or emitter
change that produces drift fails its own PR check immediately.
Layers documented:
- Self-hosting (primary): the dogfood loop.
- Fixture-based integration tests for shapes ox-tools doesn't have.
- Schema validation (actionlint / taplo / just --summary).
- Manual release checklist for things dogfooding can't catch (1ESPT,
self-hosted runners, macOS, cross-repo migrations).
Also covers bootstrap (the one hand-written workflow that wraps the
regenerated reusable workflow), breaking-change handling, recovery from
self-inflicted main breakage, and acknowledged coverage gaps.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
A fix PR builds cargo-ox-ci from its own branch, so its regenerate-check passes regardless of main's state. What's actually blocked is unrelated in-flight PRs whose merge base is the broken commit; they recover by rebasing past the fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
sandersaares
left a comment
sandersaares
left a comment
There was a problem hiding this comment.
I like it and want to try it out already.
|
|
||
| 1. **One opinionated build profile** for Rust repos, with sane defaults distilled from the | ||
| strongest patterns observed across the existing repos. | ||
| 2. **Two tiers**: `pr` (blocking on every pull request) and `nightly` (slow, scheduled). |
There was a problem hiding this comment.
With the current state of PR-mini having 12 hour expiration anyway, I'd rather not have it at all.
There was a problem hiding this comment.
And to expand a bit further, the opinionated part of this design pushes more stuff into nightly builds - all the expensive things (except diff-mutants, which may also be worth omitting for faster merge experience) was moved to nightly. I want to see build times we can achieve with such an approach, and if we land somewhere reasonable, maybe we can get away with just having pr.
| # cargo-ox-ci — Design | ||
|
|
||
| > Status: **Draft**. | ||
| > Crate name: `cargo-ox-ci`. |
There was a problem hiding this comment.
"CI" is a particular methodology and does not mean "automated builds" or "PR validation", so we are misusing this term here in my opinion. I suggest ox-automation instead and removing the word "ci" from everywhere (e.g. naming the entrypoints just validate and just validate-full etc).
There was a problem hiding this comment.
Renamed to cargo-ox-check. Validate seemed too long. The ox- prefix on recipes is intentional to keep the "root namespace" free for project use.
|
|
||
| 1. **One opinionated build profile** for Rust repos, with sane defaults distilled from the | ||
| strongest patterns observed across the existing repos. | ||
| 2. **Two tiers**: `pr` (blocking on every pull request) and `nightly` (slow, scheduled). |
There was a problem hiding this comment.
I would call these validate-mini, validate and validate-full to emphasize what they do rather than what triggers them (which might ultimately be customized by users).
There was a problem hiding this comment.
My thinking was exactly to tie them to the triggers - one of the common complaints we see is that there isn't sufficient clarity on what to run to get a green PR build. I'd prefer to stick the "pr/nightly" into the recipe name to clearly make this connection.
Addresses review feedback (#25) about `CI` misuse for what is really a local+CI validation tool rather than continuous-integration methodology. The rename is identifier-scoped; tier names (`pr`, `nightly`, `full`) and prose use of `CI` stay since the trade-off there is less clear-cut. Renamed: - crate: cargo-ox-ci -> cargo-ox-check (binary, package, folder) - recipes: ox-ci-* -> ox-check-* (ox-check-pr, ox-check-clippy, ...) - region IDs: ox-ci-managed: ox-ci-* -> ox-check-managed: ox-check-* - env vars: OX_CI_* -> OX_CHECK_* - manifest: .ox-ci.lock -> .ox-check.lock - proposal files: .ox-ci-proposed -> .ox-check-proposed Not renamed: 'CI' in prose, 'ci' in crates.io keywords, the description string's industry-shorthand use of CI scaffolding. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
martin-kolinek
changed the title
Addresses review feedback (#25): the previous `--backend github|ado|both|none` surface bakes in the assumption of exactly two backends. Replace with a repeatable `--backend <name>` flag (clap `Vec<Backend>`) plus a `--no-backends` switch for the CI-less case. Adding a third backend in the future is now a catalog change, not a CLI-syntax change. Semantics preserved: - omitted -> autodetect from origin URL (unchanged) - --backend github --backend ado -> both (was: --backend both) - --no-backends -> emit no CI files (was: --backend none) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3 participants
Design document for
cargo-ox-ci, an opinionated Rust build/CI scaffolding tool intended to unify build infrastructure across the Oxidizer family of repos (oxidizer, oxidizer-github, ox-tools, ox-tools-gh, assistants-oxide, ox-docs) and ship as OSS via crates.io.No code yet — this PR introduces a binary-crate skeleton (
crates/cargo_ox_ci/) and the design undercrates/cargo_ox_ci/docs/design/.cargo check -p cargo-ox-cipasses; the binary currently just exits with a "not yet implemented" message.Design summary
Six documents under
crates/cargo_ox_ci/docs/design/:pr-fast,pr-test,pr-mutants) + 4 nightly groups (nightly-test,nightly-advisories,nightly-runtime,nightly-exhaustive); per-check invocations; impact-scoping check → env-var mapping.justfiles/ox-ci/recipe tree, tool-version policy, pass-through env-var protocol (excludes + skip), customization at the recipe level..ox-ci.lock), checksum-driven three-way state machine, dirty-file handling, opt-out via emptiness, proposal full-file emission.ox-ci-{pr,nightly}-impl.yml(owned), per-group composite actions (owned). Uniform exclude+skip inputs.ox-ci/{pr,nightly}.yml(owned), per-group step templates (owned). 1ESPT composition stays user-side; ox-ci's templates contain no compliance-harness references.Key design choices
justas the local runtime; CI invokes the same recipes. No tool dependency at CI runtime.cargo-deltaimpact scoping passed via env vars; recipes choose what to consume from the catalog..ox-ci.locktracks last-rendered checksums per owned file and per managed region. Eliminates in-file checksum noise and makes claim-with-no-upstream-change a silent no-op.<path>.ox-ci-proposed) even for region-scoped updates, so users candiff/mvcleanly.pwshis the single non-cargo runtime dep (used bypr-titleonly; other previously-scripted checkslicense-headers/ensure-no-*are plain cargo subcommands from the ox-tools family).Status
Draft. Open for feedback on:
cargo-ox-ci) — confirm before crates.io publication.pr-titleregex (Conventional Commits, hardcoded with disable escape).cargo ox-ci-pr-titlecargo subcommand to drop thepwshdep entirely.