ci(publish-binary): rolling develop build covers all 6 linux arches (386, riscv64, armv6) - #4087
Merged
Conversation
The rolling develop/master binary archives (consumed by the binary-develop / binary-master auto-update channels) built only amd64/arm64/arm — and that single 'arm' archive was GOARM=7, while release.yml names GOARM=6 'arm' and GOARM=7 'armhf'. So the develop channel was missing 386, riscv64 and armv6 entirely, and an armv6 host mapping to the 'arm' archive would download a GOARM=7 binary that can't run. Build the same six archives release.yml does, with matching names + GOARM (arm=GOARM6, armhf=GOARM7, plus 386 and riscv64). CGO_ENABLED=0 keeps it a plain cross-compile — no per-arch musl toolchain needed for the pure-Go rolling build.
0pcom
force-pushed
the
ci/develop-binary-all-linux-arches
branch
from
August 22, 2026 23:55
e799d1d to
5043cec
Compare
0pcom
added a commit
that referenced
this pull request
Aug 23, 2026
…d not found) (#4110) #4087's all-arches build_arch put a conditional ${goarm:+GOARM="..."} expansion in the env-assignment prefix. Bash only recognizes assignment prefixes for LITERAL words at parse time, so the expanded GOARM=... (and then the trailing CGO_ENABLED=0) were treated as COMMANDS — "CGO_ENABLED=0: command not found", exit 127 — breaking the rolling develop-latest binary the fleet's binary auto-updater pulls. Split into an explicit if so every env prefix is literal for both the GOARM arches (arm/armhf) and the no-GOARM arches (amd64/arm64/386/riscv64). Verified the shell logic locally: the old form reproduces the exact error; the new form sets the correct GOOS/GOARCH/GOARM/CGO_ENABLED for every arch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
binary-develop/binary-masterauto-update channels pull the rolling<branch>-latestarchives from publish-binary.yml, which built only amd64/arm64/arm — missing 386, riscv64, and armv6 that tagged releases (release.yml) produce. Worse, the singlearmarchive was GOARM=7 while release.yml names GOARM=6armand GOARM=7armhf, so an armv6 host mapping toarmwould get an unrunnable GOARM=7 binary.This builds the same six archives release.yml does, with matching names + GOARM (
arm=GOARM6,armhf=GOARM7, +386,riscv64).CGO_ENABLED=0keeps it a plain cross-compile (no musl toolchain needed for the pure-Go rolling build). Now every fleet arch can auto-update from develop.