floci native ARM64 binary

[igfasouza]

Today release.yml already builds the native binary for linux/arm64 (runner ubuntu-24.04-arm, Mandrel/GraalVM), but we only consume it to assemble the multi-arch Docker images. The binary itself isn't distributed outside the container.

I'd like to propose attaching a .tar.gz package of the ARM64 binary to the GitHub Release created by release-cut.yml, so that people running on ARM (Graviton, Ampere, Apple Silicon via Linux, Raspberry Pi 64-bit, etc.) can download and run Floci without going through Docker.

What the proposal includes

• New publish-arm64-package job in release.yml, triggered by the x.y.z tag push.
• Depends on build-native-arm64 (reuses the existing artifact — no extra build).
• Packages the binary as floci-<version>-linux-arm64.tar.gz, together with the Quarkus native side files (.properties, .so).
• Reproducible tarball: mtime pinned to the tag commit's SOURCE_DATE_EPOCH, owner/group=0, --sort=name.
• Also publishes the matching .sha256.
• Upload via gh release upload "$GITHUB_REF_NAME" ... --clobber with least-privilege scope (permissions: contents: write only on this job).

Points I'd like to discuss

1. Scope — ARM64 only, or AMD64 too? The main motivation is ARM (we don't have great coverage outside Docker today), but if symmetry is worth it I can extend the job to produce both packages.
2. Asset naming. I went with floci-<version>-linux-arm64.tar.gz. Alternatives: floci_<version>_linux_arm64.tar.gz (GoReleaser-style), floci-<version>-linux-aarch64.tar.gz (canonical arch name). Preferences?
3. Signing. For now we only publish sha256. Does it make sense to bring in cosign / minisign already, or leave that for a follow-up?
4. Tarball contents. I packaged the binary renamed to floci plus the native files that show up in target/. Anyone sees a case where the Quarkus .so/.properties don't need to ship alongside?
5. Ordering with the semantic-release Release. The Release already exists when release.yml runs (the tag is pushed only after @semantic-release/github), so gh release upload finds the target. If we ever flip that order, this needs revisiting.

Feedback welcome.

https://github.com/igfasouza/floci/blob/feat/publish-arm64-release-asset/.github/workflows/release.yml

[hectorvent]

Hi @igfasouza,
Sorry for the delayed reply, and thanks for the proposal.

This is a great idea and something I've been evaluating for a while. I'll put together a plan and share it here so we can agree on the approach before implementing anything. I've used JReleaser in the past and think it would be a good fit here as well. I'll share the plan as soon as I have it ready.

Thanks!