|
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
Pipeline #8 failed and told us nothing. Both fixes here address that. WHY IT FAILED: Woodpecker gives each workflow a fresh 10Gi workspace PVC. The release gate alone fit (pipelines #5 and #6 passed), but the new `fast-suites` step builds eight test binaries ahead of it, and the gate's nested `cargo build --features fault-injection` then had no room. CARGO_INCREMENTAL=0 now applies to every Rust step: incremental artifacts are pure waste in CI since nothing is ever reused across pipelines, and they measured 11G of a 27G target tree locally — 41%. WHY IT SAID NOTHING: tests/support/multiproc.rs:1686 built with `stderr(Stdio::null())`, so the assert fired with "cargo build ... failed" and no compiler error, no ENOSPC, no exit code. A build failure whose reason is discarded costs more than the build. stderr is now captured and included in the panic message; the output is only read on the failure path. The env block is anchored on its first consuming step rather than a top-level `variables:` key. I initially used the top-level form and reverted it: the file is schema-validated and `when: branch: main` means only main triggers a pipeline, so a rejected key could not be caught on a throwaway branch and would break every push until reverted. Same rule the resource shapes already follow. |
||
|---|---|---|
| .. | ||
| benches | ||
| config | ||
| src | ||
| tests | ||
| BUILD.bazel | ||
| Cargo.toml | ||