mirror of
https://github.com/ruvnet/RuVector.git
synced 2026-05-30 12:13:34 +00:00
Audit found two related issues:
1. Iter 177 added deny.toml to BOTH the cluster and hailo crates,
but CI only audited the cluster's. The hailo crate's
candle / tokenizers / safetensors chain (cpu-fallback feature)
and hailort-sys FFI surface (hailo feature) were ungated.
2. Both deny.toml files set `wildcards = "deny"`, which
cargo-deny applies to path deps too. The cluster has path
deps on ruvector-hailo, ruvector-mmwave, hailort-sys — so the
`bans` check would fail on `cargo deny check` if anyone ran
it. The CI step ran but apparently never gated; running it
locally now surfaces:
error[wildcard]: found 1 wildcard dependency for crate
'ruvector-hailo' ...
bans FAILED
Fix:
- Add `allow-wildcard-paths = true` to both deny.toml [bans]
sections. cargo-deny only honors this on non-publishable
crates, so also mark both crates `publish = false`. Both
are internal-only (path deps to hailort-sys make them
unpublishable to crates.io anyway), so the publish flip is
correct hygiene independent of cargo-deny.
- Add a second `cargo deny` step in the hailo-backend-audit
workflow that runs in `crates/ruvector-hailo` with
`--all-features` so the cpu-fallback + hailo feature surfaces
are audited.
- Add three new test/clippy steps for the hailo crate so iter-198's
hef_verify cases (and iter-186 host_embeddings, iter-191
hef_pipeline patches) are explicitly gated:
cargo test (default features)
cargo test --features cpu-fallback (hef_verify + tokenizer)
cargo clippy --all-targets -D warnings
Validated locally:
Both crates: cargo deny check → advisories ok, bans ok,
licenses ok, sources ok
hailo lib : 19 tests pass (default)
26 tests pass (--features cpu-fallback)
hailo clippy: clean
cluster lib: 108 tests still pass
No production code changed; pure CI + crate-config hygiene. Pi
worker untouched.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|---|---|---|
| .. | ||
| benchmarks | ||
| workflows | ||