[elixir] Release pipeline
- Dominant language
- Rust
- Stars
- 58
- Forks
- 50
- PR merge metrics
- No merged PRs in 30d
Description
### Search before asking
- [x] I searched in the [issues](https://github.com/apache/fluss-rust/issues) and found nothing similar.
### Description
Follow-up to #459 covering the release-side concerns. Consumers installing fluss from Hex should not need a Rust toolchain, protoc, or any native build environment - they should get a ready-to-load .so/.dylib for their platform. This is the standard rustler_precompiled pattern and matches what Scylla, Tantiex, and other Rust-backed Elixir libraries do.
On tag push we need to build the NIF for four targets: linux x86_64, linux aarch64, macOS x86_64, macOS aarch64, and attach the resulting shared libraries to a GitHub release as .tar.gz artifacts with a checksum.exs file, and then publish the Elixir package to Hex. The runtime code in bindings/elixir/lib/fluss/native.ex switches from use Rustler to use RustlerPrecompiled, declares the supported targets and their checksums, and falls back to local compilation only if the user opts in via FLUSS_BUILD env var.
We need: a new workflow triggered on v* tags with a matrix job that cross-compiles on the appropriate runners (ubuntu-latest + ubuntu-24.04-arm64 for Linux, macos-13 + macos-14 for macOS), a release job that assembles the checksum file and creates the GitHub release, and a final Hex publish job gated on HEX_API_KEY as a repository secret. The publish job should run mix hex.publish package --yes, docs publish can follow in the same step.
### Willingness to contribute
- [ ] I'm willing to submit a PR!
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.