CI: linux-arm job sometimes fails on taiki-e/install-action@nextest with checksum error

[samuelburnham]

The checksum error appears to happen when installing nextest via cargo-binstall on the buildjet-16vcpu-ubuntu-2204-arm runner. A cursory issue search of the relevant repos didn't turn up anything, perhaps we should open an issue in taiki-e/install-action, cargo-binstall, or nextest?

It seems to work when re-running the job, so it's low priority.

Error message:

 info: host platform: aarch64_linux
info: install-action does not support cargo-nextest; fallback to cargo-binstall
info: installing cargo-binstall@latest (1.5.0)
info: downloading https://github.com/cargo-bins/cargo-binstall/releases/download/v1.5.0/cargo-binstall-aarch64-unknown-linux-musl.tgz
info: verifying sha256 checksum for cargo-binstall-aarch64-unknown-linux-musl.tgz
info: cargo-binstall installed at /home/runner/.cargo/bin/cargo-binstall
+ cargo-binstall binstall -V
1.5.0
info: syncing channel updates for '1.73-aarch64-unknown-linux-gnu'
info: latest update on 2023-10-05, rust version 1.73.0 (cc66ad468 2023-10-03)
<...>
WARN Failed to retrieve token from `gh auth token` err=Custom { kind: Other, error: "process exited with `exit status: 1`" }
 WARN Failed to read git credential file
 INFO resolve: Resolving package: 'cargo-nextest'
ERROR Fatal error:
  × For crate cargo-nextest: Expected checksum
  │ `ac507820d4c46e1665426cd5dfbb3b0253d6e01f292ca7846b4c3a90d5fa697a`, actual
  │ checksum `cd9b2669f92a6e80cac50d37db0fd5ed10d57ba36d9e0ba3328600c4a1b37025`
  ╰─▶ Expected checksum
      `ac507820d4c46e1665426cd5dfbb3b0253d6e01f292ca7846b4c3a90d5fa697a`,
      actual checksum
      `cd9b2669f92a6e80cac50d37db0fd5ed10d57ba36d9e0ba3328600c4a1b37025`

Failing runs:
https://github.com/lurk-lab/lurk-rs/actions/runs/7465629665/job/20315228042
https://github.com/lurk-lab/lurk-rs/actions/runs/7455516468/job/20284729620

[huitseeker]

Do we have evidence of failures outside of the 4-6PM UTC time frame today?
https://www.githubstatus.com/history?page=19

[samuelburnham]

Yes, the second linked run was from approx. 1:44am UTC today. Could be the GitHub service outages/degradation were present then.

[samuelburnham]

Closing as a spurious error, as it hasn't happened since