dcf1b59586
Some checks failed
lane-shas / verify pinned lane SHAs (pull_request) Failing after 33m18s
The self-hosted Actions runner is aarch64 (Apple M1 Linux); the CI toolchain
assumed x86_64, so every workflow has been failing at environment setup — on
main and every PR, not a code regression.
Two root causes, both arm64:
* pyrage==1.2.3 publishes no linux-aarch64 wheel, so uv fell back to an sdist
build and modern uv rejects pyrage's own pyproject.toml ("[project] without
project.version") — "TOML parse error at line 5". Bump to pyrage==1.2.4, the
first release shipping a cp39-abi3 manylinux_2_17_aarch64 wheel (x86_64 and
macOS wheels retained). No source build -> no parse error. Fixes smoke,
full-pytest, contemplation, ratify-proposal.
Verified: age/X25519 encrypt+decrypt round-trips on 1.2.4, and the committed
sealed-holdout artifacts (sealed under 1.2.3) still decrypt
(tests/test_holdout_encryption.py, tests/test_adr_0119_7_sealed_gsm8k.py —
7 passed). No ADR pins the patch version; only a size-tally doc referenced
it (updated).
* lane-shas used actions/setup-python@v5, which has no arm64 build for the
pinned 3.12.13 ("version '3.12.13' with architecture 'arm64' was not found"
-> "python: command not found"). Switch to astral-sh/setup-uv@v5 + uv (uv
provisions arm64 Python reliably), matching the other four workflows.
Files: pyproject.toml (pyrage 1.2.3->1.2.4), docs/model_dependency_size_tally.md,
.github/workflows/lane-shas.yml. uv.lock is gitignored (uv re-resolves per run).
Separate pre-existing issue (NOT addressed here): with setup fixed, lane-shas
now reaches its SHA check, where 2 demo lanes (demo_composition, public_demo)
drift from their pins. This is content drift on main, unrelated to the toolchain
(public_demo is a known wall-clock/env flake). Left for an explicit re-pin vs
degate decision rather than silently re-pinning.
|
||
|---|---|---|
| .. | ||
| workflows | ||
| CODEOWNERS | ||
| copilot-instructions.md | ||
| FUNDING.yml | ||