Remove the armhf binary from the release

[alexellis]

Motivation

faas-cli-armhf is the least-used artifact we publish, and it is the only build target that cannot fail anywhere except during a release. Both of those came to a head this week: a compile error affecting only the 32-bit Arm target broke the 0.18.12 publish and the release had to be retracted.

Why it doesn't make sense to keep building it

Nobody is downloading it. Asset download counts for the last five releases:

Release	armhf	arm64	amd64	.exe
0.18.11	2	11	101	17
0.18.10	15	68	2466	228
0.18.9	4	4	29	9
0.18.8	19	189	8936	689
0.18.7	15	31	1106	102

That is ~55 downloads against ~12,600 for linux/amd64 — around 0.4%, and roughly a fifth of arm64. It is the least-downloaded binary in every single release. These counts include bots and mirrors, so treat them as an upper bound.

Nothing else in the project ships armhf. The faas-cli container images are already limited to linux/amd64,linux/arm64. The language templates dropped armhf when they moved to multi-arch buildx. OpenFaaS itself does not support armhf, so an armhf user could only ever run the CLI against a remote cluster — they could not run a gateway or build a function for that architecture.

It is the only target that can fail at release time and nowhere else. The armhf cross-compile lives in Dockerfile.redist, which only the publish workflow builds. build.yaml covers linux/amd64 and a linux/amd64,linux/arm64 multi-arch check, and never touches the redistributable binaries. So a compile error specific to a 32-bit target is undetectable until a tag is pushed. That is exactly what happened with 0.18.12:

commands/local_run_resources.go:138:78: cannot use math.MaxInt64
  (untyped int constant 9223372036854775807) as int value in argument
  to fmt.Errorf (overflows)

An untyped constant passed to a variadic interface{} takes its default type of int, which is 32 bits on armhf. go build, go test, and the whole build workflow all passed.

What changes

• Dockerfile.redist — drop the arm build stage and its COPY into the release stage
• extract_binaries.sh — stop copying faas-cli-armhf out of the image
• Makefile — remove the ci-armhf-build / ci-armhf-push targets
• build_integration_test.sh — remove the armv6l/armv7l binary selection
• npm/lib.js — armv6l / armv7l now report Unsupported platform instead of fetching a binary that will not exist. This is a clearer failure than a 404 partway through an install.
• .gitignore, CONTRIBUTING.md — housekeeping

The second commit adds Dockerfile.redist to the build workflow, so the remaining cross-compiled targets — Windows, macOS x86_64, macOS arm64, Linux arm64 — are compiled on every push rather than only at release. The image is built and discarded, not loaded or pushed. This is what would have caught the 0.18.12 failure in the PR that introduced it.

Impact on users

Anyone still on 32-bit Arm can stay on 0.18.11 or earlier. Those binaries remain published and downloadable indefinitely; nothing is being deleted from existing releases. They simply will not receive new versions.

In practice this is a very small group. 32-bit Arm means ARMv6 hardware — Pi 1, Pi Zero, Pi Zero W — or a 32-bit Pi OS image on a 64-bit board. Raspberry Pi OS has defaulted to 64-bit since 2022, and the Pi Zero 2 W is ARMv8. Anyone on 64-bit Arm continues to use faas-cli-arm64, which is unaffected.

No change for users on amd64, arm64, macOS or Windows.

Testing

• Dockerfile.redist builds clean and produces exactly the expected set, with no armhf: faas-cli, faas-cli-arm64, faas-cli-darwin, faas-cli-darwin-arm64, faas-cli.exe
• go build ./..., go test ./... and gofmt -l clean
• npm suffix resolution verified: x64 → "", aarch64 → -arm64, Darwin → -darwin, Windows_NT → .exe, and armv61 / armv71 now throw Unsupported platform
• build.yaml validated as parseable YAML

Raised as a PR rather than pushed to master so it is visible and open to comment.

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• Removes the Linux ARMHF redistributable binary from the release image and extraction script.
• Removes ARMHF-specific CI Makefile targets and ignore entries.
• Updates npm suffix behavior so 32-bit Arm platforms fail as unsupported instead of targeting a missing asset.
• Adds coverage in the build workflow for the redistributable Dockerfile cross-compile path.
• Updates contributor documentation to match the reduced release artifact set.
• No blocking correctness, release, or publishing issues were found in the scoped diff.

Approval rating (1-10)

9/10. The change is focused, consistent across release paths, and adds useful CI coverage for the remaining redistributable targets.

Summary per file

Summary per file

File path	Summary
.github/workflows/build.yaml	Adds Dockerfile.redist build coverage to regular CI.
.gitignore	Stops ignoring the removed ARMHF binary.
CONTRIBUTING.md	Updates release binary documentation to omit ARMHF.
Dockerfile.redist	Removes the ARMHF build stage and release copy.
Makefile	Removes ARMHF image build and push targets.
build_integration_test.sh	Removes ARMHF binary selection for Linux armv6/armv7.
commands/local_run_resources.go	Generalizes the 32-bit overflow comment.
extract_binaries.sh	Stops extracting the removed ARMHF artifact.
npm/lib.js	Stops mapping 32-bit Arm to an ARMHF release suffix.
npm/test.js	Updates suffix tests to expect unsupported 32-bit Arm.

Overall Assessment

The PR consistently removes the ARMHF CLI release artifact from the redistributable build, extraction, local ignore list, contributor docs, and npm install suffix handling. Adding Dockerfile.redist to the regular build workflow directly addresses the prior gap where cross-compiled release binaries were only validated during publishing. I did not find a concrete regression in the scoped diff.

Detailed Review

Detailed Review

No blocking findings.

The release path remains internally consistent: Dockerfile.redist no longer produces faas-cli-armhf, extract_binaries.sh no longer copies it, and the GitHub release upload glob will publish the remaining faas-cli* assets.

The npm behavior now fails before attempting to download a removed 32-bit Arm artifact. That matches the stated user impact better than leaving installers to fail with a release-asset 404.

The build workflow addition targets the release stage of Dockerfile.redist, which forces the remaining Linux, macOS, Windows, and arm64 binary stages referenced by that stage to compile before release time.

The documentation update in CONTRIBUTING.md matches the final artifact set and does not introduce a reader-facing inconsistency.

AI agent details.

Agent processing time: 1m14.76s
Environment preparation time: 3.279s
Total time from webhook: 1m23.547s