`Install Trunk` has never run to completion here, because the two steps
before it always failed first. With those cleared it becomes reachable,
and on this runner v0.5.0 would fetch the wrong binary.
v0.5.0 switches on PLATFORM alone and never consults the architecture:
case 'linux': arch = 'x86_64-unknown-linux-gnu'; break;
v0.5.1 reads it and maps it, failing loudly rather than wrongly:
const arch = process.env['ARCH'] || process.arch;
case 'x64': targetArch = 'x86_64'; break;
case 'arm64': targetArch = 'aarch64'; break;
default: core.setFailed(`Unsupported architecture: ${arch}`); return;
Node reports `arm64` here, so it resolves to `aarch64`, and upstream does
publish trunk-aarch64-unknown-linux-gnu.tar.gz. There is also an `ARCH`
env override if the mapping is ever wrong.
Read out of the two bundled dist/index.js files, not the release notes.
Counts moved as predicted: `x86_64-unknown-linux-gnu` 1 -> 0, `aarch64`
0 -> 1, `os.arch()` 5 -> 5. Confirmed independently on both machines.
Two further changes the bump carries, neither of them about architecture:
* the download host moves thedodd/trunk -> trunk-rs/trunk. Trunk moved
repositories and v0.5.0 still points at the old one -- arguably the
more durable half of the fix.
* `io.mv` 1 -> 0 and `io.cp` 2 -> 3. A cross-filesystem move throws
EXDEV; a copy does not. This is the fix for self-hosted runners whose
/tmp is a separate filesystem, which is ours. NOTE: the string EXDEV
appears zero times in either bundle, so this cannot be found by
grepping for the error it prevents -- it is visible only as the
primitive swap.
STILL UNVERIFIED: whether `trunk build --release` then succeeds. Everything
above concerns selecting and fetching the binary. The step after it has
never run in this repository's history, on any architecture, so there is no
basis to predict it. Expect to read that log fresh.
Refs #11
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`dtolnay/rust-toolchain@stable` installs a minimal profile. The `native`
job named no components, so every run that reached the Clippy step died
on
error: 'cargo-clippy' is not installed for the toolchain
'stable-aarch64-unknown-linux-gnu'
before clippy read a line of source. That is not a lint result; the step
had never run. The `fmt` job below always named `components: rustfmt`
correctly — this one never did.
Two lines of behaviour change. The rest is the comment explaining why the
step is left gating on `-D warnings` rather than softened: the workspace
is not clippy-clean (run 203's build alone emits ~13 rustc warnings that
`-D warnings` promotes to errors), and `continue-on-error` cannot tell
"debt not yet paid" from "debt paid". That debt is scoped in #13, the way
the rustfmt debt is in #12.
Run 203 is what made this visible. With the aarch64 fix in 64bb7da the
native job got all the way through:
cargo check --workspace ok 10m01s
cargo build --workspace ok 19m04s
cargo test --workspace ok 16m22s 214 passed, 0 failed
cargo clippy --workspace toolchain error
Refs #13
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
This workflow has never once gone green on this instance: 23 runs cancelled,
2 waiting, zero successes. Not a regression -- it has been decorative since it
was written, because it describes GitHub's hosted fleet and runs on one
self-hosted aarch64 Pi advertising ["ubuntu-latest","ubuntu-24.04",
"ubuntu-22.04"].
Two failures, both configuration rather than code:
`windows-latest` and `macos-latest` match no runner label, so those jobs sit in
WAITING for ever and the RUN never reaches a terminal state. A pull request's
checks therefore never resolve either way -- not red, just never finished, which
is worse than red because a red check tells you something. Removed: a second
architecture here needs a second runner, not a second matrix row.
`--target x86_64-unknown-linux-gnu` on an aarch64 host makes every build a
cross-compile, and `wayland-sys`'s build script dies on it with "pkg-config has
not been configured to support cross-compilation". Dropped; the native job now
builds for its host.
NOT touched, deliberately: the WASM and Formatting jobs still fail, on real code
state rather than on configuration -- `getrandom` needs the `wasm_js` backend
for wasm32-unknown-unknown, and `cargo fmt --check` reports a ~13,000 line diff
across the tree. Editing those two into passing is precisely the leniency with
an expiry date nobody sets that PROTOCOL.md now forbids. They are issues, not
workflow lines.
(One latent defect noted while reading: `jetli/trunk-action` fetches
trunk-x86_64-unknown-linux-gnu onto this aarch64 host. It has never been reached
because the WASM check fails first, and it will bite the moment that is fixed.)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
