release: download the artifacts with the version that uploaded them

The upload was moved to v3 because this forge presents as GHES and v4
refuses it outright — the comment two lines above records the count, 0
of 72 against 132 of 133. The download was left on v4.

So every release built both binaries, published both images, cut the
manifest, and then failed at the last step. A tag whose image is already
live reads as a failed release, which is the worst shape the signal can
take: the thing everyone checks says no while the thing everyone needs
says yes.

Same version on both sides, for the same reason, which is also the only
arrangement that can work — a v4 download cannot read a v3 artifact even
where it is allowed to run.
This commit is contained in:
zooqueen
2026-08-20 14:00:57 -07:00
parent b6ab5f46c1
commit 3b00ddf40d
+7 -1
View File
@@ -166,7 +166,13 @@ jobs:
runs-on: [lux-build-linux-amd64]
timeout-minutes: 20
steps:
- uses: actions/download-artifact@v4
# v3 for the same reason the upload above is v3, and it has to be the SAME
# version: v4 refuses this forge outright, and a v4 download cannot read a
# v3 artifact even where it runs. Fixing one side and not the other left
# every release building both binaries, publishing both images, and then
# failing at the last step — which reads as a failed release for a tag
# whose image is already live.
- uses: actions/download-artifact@v3
with:
path: dist/
- uses: softprops/action-gh-release@v2