Publish prebuilt FlowScope CLI binaries
Problem
Installing flowscope-cli with Cargo compiles the CLI and all native dependencies from source:
cargo install --locked --version 0.9.0 --no-default-features flowscope-cli
On a standard GitHub-hosted Ubuntu runner, this did not complete within 20 minutes. Compilation includes dependencies such as DuckDB, Apache Arrow, and SQLParser.
This makes using FlowScope in CI expensive and can require caching or maintaining a separate internal binary build process.
The GitHub releases currently publish the Rust and npm packages but do not include native CLI binaries. There also does not appear to be a Python wheel or another package containing a prebuilt native executable.
Proposed solution
Publish prebuilt flowscope CLI binaries as GitHub release assets for supported platforms and architectures.
Suggested initial targets:
x86_64-unknown-linux-gnu
aarch64-unknown-linux-gnu
x86_64-apple-darwin
aarch64-apple-darwin
x86_64-pc-windows-msvc
Each release should include:
- A compressed executable archive for each target
- A SHA-256 checksum file
- The FlowScope version in the archive or executable name
- Build provenance or an attestation where practical
Example asset names:
flowscope-v0.9.0-x86_64-unknown-linux-gnu.tar.gz
flowscope-v0.9.0-aarch64-apple-darwin.tar.gz
flowscope-v0.9.0-x86_64-pc-windows-msvc.zip
flowscope-v0.9.0-SHA256SUMS
Package-manager support
The release binaries could subsequently support installers such as:
cargo-binstall
- Homebrew
- Scoop or Winget
- A Python wheel that bundles the executable, if Python-based installation is wanted
Publishing the release assets first would provide a common source for these installation methods.
Expected outcome
CI consumers could download and verify a pinned FlowScope executable instead of compiling the Rust project for each fresh runner.
For example, a GitHub Actions workflow could:
- Download the binary for its runner platform.
- Verify its SHA-256 checksum.
- Place it on
PATH.
- Run
flowscope --version.
- Generate the required lineage report.
Alternatives considered
- Cache Cargo build outputs: Reduces repeated compilation but the first run remains slow, cache storage is large, and invalidation can be expensive.
- Cache the installed executable: Works within one repository but each consumer must maintain similar setup logic.
- Use
@pondpilot/flowscope-core: The published WASM package avoids native compilation, but existing CLI integrations must be rewritten as Node.js applications.
- Increase CI timeout: Allows compilation to finish but consumes runner time on cache misses and does not address distribution.
Additional context
Observed environment:
- FlowScope CLI:
0.9.0
- Runner: GitHub-hosted
ubuntu-latest
- Rust installation: stable toolchain
- Cargo options:
--locked --no-default-features
- Result: compilation was canceled after approximately 20 minutes before the CLI installation completed.
Publish prebuilt FlowScope CLI binaries
Problem
Installing
flowscope-cliwith Cargo compiles the CLI and all native dependencies from source:On a standard GitHub-hosted Ubuntu runner, this did not complete within 20 minutes. Compilation includes dependencies such as DuckDB, Apache Arrow, and SQLParser.
This makes using FlowScope in CI expensive and can require caching or maintaining a separate internal binary build process.
The GitHub releases currently publish the Rust and npm packages but do not include native CLI binaries. There also does not appear to be a Python wheel or another package containing a prebuilt native executable.
Proposed solution
Publish prebuilt
flowscopeCLI binaries as GitHub release assets for supported platforms and architectures.Suggested initial targets:
x86_64-unknown-linux-gnuaarch64-unknown-linux-gnux86_64-apple-darwinaarch64-apple-darwinx86_64-pc-windows-msvcEach release should include:
Example asset names:
flowscope-v0.9.0-x86_64-unknown-linux-gnu.tar.gzflowscope-v0.9.0-aarch64-apple-darwin.tar.gzflowscope-v0.9.0-x86_64-pc-windows-msvc.zipflowscope-v0.9.0-SHA256SUMSPackage-manager support
The release binaries could subsequently support installers such as:
cargo-binstallPublishing the release assets first would provide a common source for these installation methods.
Expected outcome
CI consumers could download and verify a pinned FlowScope executable instead of compiling the Rust project for each fresh runner.
For example, a GitHub Actions workflow could:
PATH.flowscope --version.Alternatives considered
@pondpilot/flowscope-core: The published WASM package avoids native compilation, but existing CLI integrations must be rewritten as Node.js applications.Additional context
Observed environment:
0.9.0ubuntu-latest--locked --no-default-features