apache / apache/fluss-rust

[elixir] Release pipeline

Open
#498 0 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.