Build a Hook release for Honeycomb#

Install the released CLI with honeycomb install 'tos>hook', then run hook login <slt> and hook webhook <webhook-url>. Honeycomb owns installation and updates. The Rust client remains a normal Cargo dependency and never modifies a consuming project at runtime.

Build all targets#

The release workflow builds these native executables:

For each Rust target, run cargo build --locked --release -p silicon-hook-cli --target <rust-target> on the corresponding build runner. Collect each executable as artifacts/<honeycomb-target>/<executable>. Windows ARM64 uses the Windows runner's cross compiler. The checked-in Cargo configuration statically links the Visual C++ runtime for both Windows targets.

Validate and pack#

Keep the app version in honeycomb.yaml equal to crates/cli/Cargo.toml. A release tag must be v<version>. With Honeycomb available:

python3 scripts/package-cli.py --artifacts artifacts --output dist

The packager requires all six nonempty native executables and checks their OS and CPU headers, stages honeycomb.yaml at the archive root, runs honeycomb validate <staging-directory>, then honeycomb pack <staging-directory> --output <archive>. It then validates the finished archive, checks its exact file inventory and writes a SHA-256 sidecar. It fails without a complete set. The output is one silicon-hook-<version>.tar.gz containing every platform. The GitHub release workflow uploads that archive and checksum as build artifacts; publication is a separate release action.

A docs build only renders documentation. It does not build binaries, publish a release or substitute a source archive for the prebuilt package. See Honeycomb's package documentation for its manifest contract.

Local cross builds on macOS#

Install the six Rust targets above, Xcode's macOS SDK, cargo-zigbuild with Zig, and cargo-xwin with LLVM. With their executables on PATH:

cargo build --locked --release -p silicon-hook-cli --target aarch64-apple-darwin --target x86_64-apple-darwin --target-dir target/honeycomb-macos
cargo zigbuild --locked --release -p silicon-hook-cli --target x86_64-unknown-linux-gnu.2.28 --target aarch64-unknown-linux-gnu.2.28 --target-dir target/honeycomb-linux
cargo xwin build --locked --release -p silicon-hook-cli --target x86_64-pc-windows-msvc --target aarch64-pc-windows-msvc --target-dir target/honeycomb-windows

The Linux cross builds target glibc 2.28 or newer. Collect the outputs from each build directory's <rust-target>/release/ into the artifact layout above before packaging. Native CI builds use the system libraries of their listed runners.

Locally staged executables can also live at the paths declared by the root manifest: targets/<honeycomb-target>/bin/<executable>. Then honeycomb validate . verifies the complete local package. Generated targets/ and dist/ are kept on disk and excluded from source commits.

0.7.0: event payload without summary#

REST history/deliveries, WebSocket new_event metadata and local recipient payloads no longer contain the generated summary. The event ID, provider, receipt time, request and delivery sequence remain available. No database migration is needed; existing stored event rows are preserved.

Update Rust consumers to silicon-hook-client 0.7.0. Update the CLI with honeycomb update 'tos>hook' and restart existing relay daemons before using the new backend. Earlier clients require the removed field when decoding events. The separate DM-style protocol proposal in understanding/api.yaml is not part of this release; existing WebSocket message names and ACK/replay behavior remain.