CI publishes prebuilt microhaplot-extract binaries as GitHub Release assets

[ltalignani]

Parent

Perl→Rust portage of the extraction core: microhaplot-extract spec

What to build

The release-publishing half of the local-install distribution story: at every version tag, CI builds microhaplot-extract natively (no QEMU) for macOS (arm64 + x86_64) and Linux (x86_64 + arm64), and publishes all four as GitHub Release assets on that tag — extending the same native-per-architecture approach already used for this repo's multi-arch Docker publish.

Acceptance criteria

• Pushing a version tag builds microhaplot-extract natively for all four platform/architecture combinations, using GitHub-hosted runners matched to each target (no cross-compilation, no emulation).
• All four binaries are attached as assets on the GitHub Release for that tag.
• The release/binary versioning follows this repo's existing convention of the git tag matching DESCRIPTION's Version field (e.g. tag v2.0.1 for Version: 2.0.1) — confirm this is still the intended convention before implementing; flag if not.
• A tag push that fails to build any one platform does not publish a partial/inconsistent set of release assets.

Blocked by

• Multi-sample batch orchestration, combined output, progress markers, and an R wrapper

[ltalignani]

Resolved in 6a5bc4a.

Adds .github/workflows/release-binaries.yml: at every version tag, builds microhaplot-extract natively for macOS (arm64 via macos-14, x86_64 via macos-15-intel) and Linux (x86_64 via ubuntu-latest, arm64 via ubuntu-24.04-arm) — one GitHub-hosted runner per platform, no cross-compilation or emulation, extending the same native-per-architecture approach docker-publish.yml already established for its own multi-arch build.

Two-phase build/publish split, mirroring docker-publish.yml's build/merge shape: each platform's binary is staged and uploaded as a short-lived build artifact first (matrix.fail-fast: false so one platform's failure doesn't hide the others' results); the publish job (needs: build, gated to real tag pushes only) only runs once every matrix entry has succeeded — a build failure on any one platform skips the whole publish step, so a tag push never leaves a partial/inconsistent set of release assets. Before publishing, verifies the pushed tag (vX.Y.Z) matches DESCRIPTION's Version field — confirmed against this repo's actual tag history (v2.0.1 ↔ Version: 2.0.1, v2.0.0 ↔ Version: 2.0.0, etc.).

workflow_dispatch is also wired for the build job alone, so the matrix can be smoke-tested without cutting a real tag or touching publish.

Verified: actionlint clean. The build job was run twice via manual dispatch to confirm all 4 platforms actually compile natively — the first run had one platform (linux-x86_64) get cancelled by CI infrastructure mid-build (unrelated to the workflow itself); a second dispatch confirmed all 4 platforms (linux-x86_64, linux-arm64, macos-arm64, macos-x86_64) build successfully, with publish correctly skipped in both runs (no tag ref set under workflow_dispatch). No git tag was pushed and no GitHub Release was actually published as part of this ticket — cutting a real release is an outward-facing, hard-to-reverse action outside an agent's remit to do unilaterally; the workflow's actual tag-triggered publish path is exercised for real the next time a version tag is pushed.

/code-review (Standards + Spec axes, diff cb7d0f1...HEAD): 0 findings on both axes.

[ltalignani]

Closing — resolved in 6a5bc4a, see comment above for verification details.