mirror of
https://github.com/hanzoai/zip-rs.git
synced 2026-10-30 18:16:57 +00:00
zeekay
3bf4a72129
Workflows are collected from .hanzo/workflows when it exists, so ci.yml has been running nothing since the forge pipeline arrived. fmt, clippy and the library suite were already carried by hanzo.yml; the wasm build was not, and that is the gate that matters most here — the examples compiled to wasm32-wasip1 are the product, so a macro or ABI change that breaks the target shows up nowhere else. It now runs with the rest. The integration lane does not come back. It checked out hanzoai/base, built a harness from tools/wasmvm-run and executed each module through it. Loading the modules in the host runtime is no longer covered; the build proves they compile, not that they run.
40 lines
1.9 KiB
YAML
40 lines
1.9 KiB
YAML
# Canonical CI/CD config for hanzoai/zip-rs — read by the hanzoai/ci reusable
|
|
# (.hanzo/workflows/cicd.yml) and by platform.hanzo.ai.
|
|
#
|
|
# A Rust workspace of two published crates (zip-rs, zip-rs-macros) plus three
|
|
# wasm example crates: ships from a tag to crates.io, builds no image, so no
|
|
# `images:` and no `deploy:`.
|
|
#
|
|
# `rustup component add` first, because the toolchain this workflow provisions
|
|
# (dtolnay/rust-toolchain@stable) installs the compiler ALONE — no rustfmt, no
|
|
# clippy — and a gate whose tool is missing dies with
|
|
# "'cargo-fmt' is not installed for the toolchain" before it ever reads the
|
|
# code. That is a red run that says nothing about the repo, which is worse than
|
|
# no run. The repo's own ci.yml buys the same thing with `components:` on the
|
|
# toolchain action; this buys it from inside the gate, since the provision step
|
|
# above is not ours to configure. Both adds are idempotent.
|
|
#
|
|
# The three gates are the repo's own (.github/workflows/ci.yml), cheapest
|
|
# first. `cargo test` names the two library crates rather than --workspace
|
|
# because the examples/ members are wasm32 targets — CI builds them with
|
|
# --target wasm32-unknown-unknown, and testing them on the host would fail for
|
|
# the target, not for the code.
|
|
|
|
test:
|
|
- name: fmt
|
|
run: rustup component add rustfmt && cargo fmt --all -- --check
|
|
- name: clippy
|
|
run: rustup component add clippy && cargo clippy --workspace --all-targets -- -D warnings
|
|
- name: test
|
|
run: cargo test -p zip-rs -p zip-rs-macros
|
|
- name: wasm
|
|
# The examples are the product: extensions compiled to wasm32-wasip1 and
|
|
# loaded by the host runtime. Building them is what proves a change to the
|
|
# macros or the ABI has not broken the target the crates exist to hit.
|
|
run: |
|
|
rustup target add wasm32-wasip1
|
|
cargo build --release --target wasm32-wasip1 \
|
|
-p zip-rs-example-hello \
|
|
-p zip-rs-example-validate-email \
|
|
-p zip-rs-example-policy-eval
|