Build 1445 confirmed the re-exec works -- the suite reached uid 1000 -- and
then died on `cargo: command not found`. rustup had installed into
`/root/.cargo`, which mode 0700 makes unreadable the moment the job stops
being root.
Install the toolchain into /opt/cargo + /opt/rustup on the Linux agent and
mark it a+rX, pass an explicit HOME through the re-exec, and hand CARGO_HOME
and ./target to the build user so cargo can still write its registry, git
checkouts and target dir.
macOS is unaffected: it is not root, so it keeps the HOME-relative paths.
That leg has now passed twice at 328s (builds 1443 and 1445).
Signed-off-by: CodeWhale Bot <bot@codewhale.net>
Build 1443 gave the first real numbers, and they are good: macOS workspace
tests 328s and Linux fmt+clippy 159s on hosted agents, against 56 minutes and
11 minutes for the same work on GitHub Actions. Linux tests failed, but not
for a product reason.
Hosted Linux agents run the job as root; GitHub's ubuntu runner uses the
unprivileged `runner` user. Root ignores permission bits, so every test that
makes a path read-only and asserts the write is refused instead succeeds at
writing and fails its assertion. Exactly four failed that way:
launch::tests::an_unwritable_home_reports_the_failure_and_still_answers
tools::file::pdf_tests::contract_edit_rejects_read_only_target_before_atomic_replace
config_bundles::tests::failed_apply_rolls_back_to_the_prior_document
fleet::executor::tests::executor_runs_real_process_and_drains_stream_json_into_ledger_events
`launch.rs:331` is explicit about the contract it is checking -- "an unwritable
home must be reported, not swallowed" -- which root cannot violate.
Drop to an unprivileged user for the suite rather than skipping those cases or
allowing them to fail. They guard data-loss and permission behaviour; a lane
that structurally cannot exercise them is a weaker gate that still reports
green, which is the failure mode this whole pipeline change exists to remove.
common.sh now exports CARGO_HOME/RUSTUP_HOME explicitly so the toolchain
survives the user swap.
Signed-off-by: CodeWhale Bot <bot@codewhale.net>
The previous commit added .buildkite/pipeline.yml but not the scripts it
invokes. `.gitignore` line 59 ignores `*.sh` repo-wide, with negations for
`!scripts/**` and `!.github/scripts/**`; `.buildkite/**` had none, so
`git add .buildkite` staged the YAML and silently dropped all three scripts.
Buildkite proved it:
$ .buildkite/steps/lint.sh
/bin/bash: line 1: .buildkite/steps/lint.sh: No such file or directory
🚨 Error: The command exited with status 127
Add the negation in the same shape as the existing two rather than inlining
the commands into YAML: kept as scripts they stay `bash -n`-checkable and
shellcheck-able, which is how the `Workflow lint` job already treats
`.github/workflows`.
Signed-off-by: CodeWhale Bot <bot@codewhale.net>
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>
