CCodeWhale Botci: isolate Buildkite tests from personal Fleet state
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
ci: isolate Buildkite tests from personal Fleet state Reuse the TUI hermetic-home convention through one shared command wrapper. Seal nextest and doctests, including the existing unprivileged Linux path, without changing selected-Fleet validation or runner configuration. Remove inherited canonical/legacy home and config overrides so per-test fixtures keep precedence. Preserve the real toolchain homes and explicit stack settings, defaulting to the existing 16 MiB CI stack. Point the TUI runner at its actual library tests instead of the empty executable target. Validation on macOS, with Cargo offline and synthetic outer state: - Old representative Fleet invocation: 0 passed / 1 failed (expected). - Isolated identical invocation: 1 passed / 0 failed; outer hashes unchanged. - Full Buildkite script: 14,231 passed / 0 failed / 15 skipped; no LEAK. - Doctests: 3 passed / 0 failed / 8 ignored. - Focused Fleet/settings/log tests: 105 passed / 0 failed. - Boundary shell cases: 3 passed / 0 failed. - Migrated TUI config-panel golden test: 1 passed / 0 failed; nonzero asserted. - Shell syntax, ShellCheck, and git diff --check passed. Preserved initial full run: 14,187 passed / 44 failed / 15 skipped (43 config/home assertions and one unproven-cause plugin PTY timeout). The initial library-target smoke overflowed the default thread stack; it passes with the existing CI default. Full Buildkite already used 16 MiB. Root npm test and npm run check:web both exit 1: missing scripts, zero tests. Hosted CI and the Linux uid transition were not executed locally. Signed-off-by: CodeWhale Bot <bot@codewhale.net> | 4 天前 | |
ci(buildkite): put the pipeline in the repo and run the real suite The `codewhale-ci` pipeline's steps lived in the Buildkite UI and ran a 67-second smoke test -- `cargo fmt` plus `codewhale-lane` and one `codewhale-workflow` filter -- on `linux-small`. A green build there proved almost nothing about this repository, and nothing in the merge path depended on it, so the pipeline has been reporting success on ~1% of the suite since July. Steps now live in the repo, reviewable in the same diff as the code they gate: fmt + clippy and the full workspace suite on Linux, and the full workspace suite on macOS. The clippy allow list is copied verbatim from .github/workflows/ci.yml; keeping the two in step matters, because a lint denied there and allowed here would make this a weaker gate that still reports green. Scope is stated in the file and is deliberately partial: Buildkite hosted agents are Linux and macOS, and there is no hosted Windows. `Test (windows-latest)` runs the installer PATH helper and an NSIS installer regression on a product that ships a Windows installer, so that leg stays on GitHub Actions. A green build here is not full platform coverage. Advisory only. The `protect-main` ruleset still requires the GitHub Actions contexts; moving them is a separate, deliberate change that should follow evidence from real pull requests, not this commit. bk pipeline validate --file .buildkite/pipeline.yml ✅ Pipeline file is valid Signed-off-by: CodeWhale Bot <bot@codewhale.net> | 8 天前 |