Download vexctl instead of compiling it on Linux/Windows

[Mikola Lysenko (mikolalysenko)]

Problem

The test job in ci.yml compiles vexctl v0.3.0 with go install on every OS, on every CI run. Here is how long the Install vexctl step took across the last 7 successful CI runs:

leg	durations (s)	median
test (windows-latest)	134, 155, 159, 177, 190, 196, 230	177s
test (macos-latest)	87, 108, 111, 112, 120, 122, 125	112s
test (ubuntu-latest)	77, 77, 80, 81, 83, 86, 90	81s

test (windows-latest) is the slowest job in the workflow: 1656s on main run 36899292199. yarn-classic-matrix, yarn-berry-e2e, cargo-vex-matrix and cargo-old-toolchains all wait on it with needs: test, so in that run they started only at 18:13, after Windows finished. That makes the windows compile part of every run's wall-clock. The compile also builds sigstore/cosign and reads dozens of sum.golang.org tiles. That has failed the step on otherwise-green runs; the step's own comment records the 2026-08-20 incident and already suggested this fix as the follow-up.

Fix

The Install vexctl step in .github/workflows/ci.yml:

• Linux / Windows: downloads vexctl-linux-amd64 / vexctl-windows-amd64.exe from the v0.3.0 release and checks each against a sha256 pinned in the workflow (copied from the release's vexctl_checksums.txt). It runs vexctl version once as a smoke test and puts the binary's directory on PATH. On Windows the file is named vexctl.exe, which is the name find_vexctl_on_path in tests/e2e_vex.rs looks for.
• macOS: keeps the retried go install exactly as before. The release's darwin binaries are built with go1.22.7 and have no LC_UUID load command: I parsed the Mach-O header of vexctl-darwin-arm64 (17 load commands, no 0x1b). The runner's dyld refuses such a binary, which is why the Go 1.24 pin exists.
• The vexctl version and both digests are in the step's env. Go setup is unchanged, since the Go e2e suites still need it.

Proof

• I downloaded all three assets and sha256sum -c vexctl_checksums.txt passed. go version -m vexctl-darwin-arm64 reports go1.22.7, which confirms macOS has to keep compiling.

• I ran the step's script locally with RUNNER_OS=Linux. It downloaded the binary, passed the checksum, printed GitVersion: v0.3.0 … GoVersion: go1.22.7 and wrote the directory to GITHUB_PATH. When I set a wrong digest, the step exits 1 at sha256sum -c and writes nothing to GITHUB_PATH.

• With that binary on PATH, cargo test -p socket-patch-cli --test e2e_vex gives 16 passed, and no skipping vexctl validation line is printed, so the vexctl merge validation really ran.

• actionlint v1.7.7 reports no issues on ci.yml.

• Expected saving: about 4.3 job-minutes per CI run (≈177s + ≈81s, minus a few seconds of download). On the Windows leg it cuts ~3 min from the job that ends the run.

• Measured on this PR. On CI run 36926566381 (head ec0d507), every workflow is green: CI, PDM, vlt, Pin check and Audit GHA Workflows. Here is how long Install vexctl took:

  • windows: 3s (median was 177s)
  • ubuntu: 1s (median was 81s)
  • macos: 108s (still compiles, unchanged)

  test (windows-latest) took 1320s in total, down from 1656s on the main run cited above. The whole CI run took 25 minutes.

Where tests run

Nothing moved or removed. All three test legs still validate the vex output with vexctl v0.3.0. Job and check names are unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LPCZKE7kADjPbgE9NrbgdS

---

Generated by Claude Code

---

Note

Low Risk
Workflow-only change with checksum-verified release binaries; application code and test semantics stay the same aside from faster, more reliable CI installs.

Overview
Speeds up CI by changing the test job’s Install vexctl step in ci.yml: on Linux and Windows it now downloads the pinned v0.3.0 release asset from GitHub, verifies sha256 digests from env, runs vexctl version, and prepends the temp bin dir to PATH instead of running go install (~minutes per leg).

macOS still uses the existing retried go install path because release darwin binaries lack LC_UUID and fail under the runner’s dyld; the compile loop now references $VEXCTL_VERSION like the download path.

Go setup and e2e behavior are unchanged—tests still resolve vexctl / vexctl.exe on PATH for OpenVEX validation.

^{Reviewed by Cursor Bugbot for commit ec0d507. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: ready for review at ec0d507 (ec0d50742bcc6422dd5b79f3b8f0ac2f9e9249de).

• CI: 338/338 non-skipped check runs green (6 skipped) on the head.
• Bugbot: reviewed cec1cda with no findings. The head ec0d507 only merges main on top of it, and the PR diff differs from cec1cda only in comment text that came in from main. No unresolved review threads.
• Reviewer focus: .github/workflows/ci.yml. Linux/Windows now download the sha256-pinned vexctl release binary instead of compiling it from source.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit ec0d507. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Reviewed ec0d50742bcc. Ready to merge from this code review; no changes requested.

No blocking findings. The Linux/Windows download paths fail closed on checksum mismatch, preserve the executable names expected by the tests, and publish PATH only after the version smoke test succeeds. The macOS source-build path remains intact.

Validation: Verified both pinned SHA-256 values against the upstream v0.3.0 release checksum manifest. Compared actionlint output against the PR merge base: the same 55 existing matrix-property diagnostics occur on both, with no added diagnostics. Current Linux/Windows/macOS CI checks pass; I did not locally execute the Linux/Windows binaries.