Wrong Build in the arm64 Archive Caught Before a Go CLI Release Went Out

Say a small team maintains a command-line tool in Go called tidy. Each release ships five archives, for Linux on Intel and ARM, macOS on Apple silicon and Intel, and Windows, plus a SHA256SUMS file. A release workflow builds them in a matrix of jobs and a final job uploads everything.

One day a refactor of the workflow moves the build output into a shared folder. The Linux ARM job now packs whatever tidy binary is in that folder, and on the runner where it lands, that’s the Intel build. Meanwhile the Intel Mac job hits a cache from the previous release and doesn’t rebuild. Every job is green. The archives have the right names and plausible sizes.

The Check

The team added rmqa to the workflow when they wrote the manifest from their last good release with rmqa init. The step runs after packing and before the upload:

- name: Check the release
  uses: softdevstudio/[email protected]
  with:
    dir: dist
    version: ${{ github.ref_name }}

This time it stops the release:

Checking dist for tidy 2.3.0

  FAIL  tidy_darwin_amd64.tar.gz  darwin/amd64
          tidy: doesn't contain the version string 2.3.0; it may be an old build [version-missing]
  ok    tidy_darwin_arm64.tar.gz  darwin/arm64
  FAIL  tidy_linux_amd64.tar.gz   linux/amd64
          tidy: is byte-for-byte the same program as tidy_linux_arm64.tar.gz:tidy, which is meant for a different platform [duplicate-binary]
  FAIL  tidy_linux_arm64.tar.gz   linux/arm64
          tidy: is built for linux/amd64, but this download is for linux/arm64 [wrong-arch]
          tidy: is byte-for-byte the same program as tidy_linux_amd64.tar.gz:tidy, which is meant for a different platform [duplicate-binary]
  ok    tidy_windows_amd64.zip    windows/amd64
  ok    SHA256SUMS

Not ready: 4 errors, 0 warnings in 6 files.

Reading the Report

Three different checks found two mistakes, and each points at the cause.

wrong-arch comes from the program’s ELF header. The file in tidy_linux_arm64.tar.gz says it’s built for x86-64, and the archive is for ARM64. Nobody would see that from the file name or the size.

duplicate-binary backs it up from another angle: the program in the arm64 archive is byte-for-byte the same as the one in the amd64 archive. Two platforms should never share a build, so this alone says something was copied.

version-missing is the stale cache. rmqa searched the macOS Intel program for the string 2.3.0 and didn’t find it. The program runs, it just isn’t this release. Running rmqa inspect on the archive confirms it’s a perfectly good Mach-O build for Intel Macs, which is exactly why it would have slipped through.

Why Not Just Run the Binaries

The release runner is Linux on Intel. It can run one of the five builds. rmqa runs that one when the manifest says run = ["version"], and for the other four it reads the headers and searches for the version string, which works for programs built for any platform. That covers the cross-compiled builds, which are the ones most likely to go wrong, because nobody runs them before users do.

After the Fix

The team pinned each job to its own output folder and keyed the cache on the platform. The next run passed with no errors and no warnings, and the release went out. The check adds a few seconds to a workflow that takes several minutes.