mirror of
https://github.com/hanzoai/cli.git
synced 2026-10-30 15:00:27 +00:00
Four places named hanzoai/cloud, and that path now serves the re-rooted OSS core -- twelve commits, no ancestor in common with the product, and no openapi.yaml at all. So every fetch 404s: hanzo.yml's client lane on each push, and the nightly re-pin on each run. It reads as a rejected credential, which is the failure mode the Makefile comment two lines above already warns about for a different reason. hanzo.yml, the Makefile default and drift.yml now name hanzo-inc/cloud. The test stops restating it: it reads repo= from .spec-lock with the same field() it already uses for ref and sha256, so which cloud a capture came from is one fact with one reader. That is what would have caught this -- the lock could move to the product line while the assertion went on checking the old one. The lock itself is left for the nightly to move, which writes ref, sha256 and repo together and regenerates the capture behind `make verify`. Committed, the lock and the capture still agree, so the gate is green either way. Co-authored-by: Hanzo Dev <[email protected]>
76 lines
4.4 KiB
YAML
76 lines
4.4 KiB
YAML
# Canonical CI config for hanzoai/cli — read by the hanzoai/ci reusable
|
|
# (.github/workflows/cicd.yml) and by platform.hanzo.ai. This repo had neither
|
|
# this file nor a Makefile, which is why `genspec` — the one thing that keeps
|
|
# the CLI's command surface honest — was reachable only by a maintainer typing
|
|
# it. A capture nothing re-asks goes stale silently, and this one did: it was
|
|
# 7 operations short and 8 operations wrong against the document cloud had
|
|
# already committed.
|
|
#
|
|
# NO images: the CLI is a binary a person installs, not a container a cluster
|
|
# runs. NO binaries: this repo's binaries are the five-target cross-build in
|
|
# .hanzo/workflows/release-matrix.yml (cargo-zigbuild + a vendored macOS SDK) —
|
|
# that is genuinely per-repo build logic and it is already correct; the generic
|
|
# Go-shaped lane here cannot produce it. NO deploy: nothing here rolls out.
|
|
#
|
|
# That path is `.hanzo/`, not `.github/`: the runners belong to git.hanzo.ai and
|
|
# github.com has none, so a pipeline under `.github/` queues forever instead of
|
|
# building. Both CI files in this repo live under `.hanzo/workflows/` for that
|
|
# one reason.
|
|
#
|
|
# What CI owns for this repo is the two gates below and the client lane.
|
|
|
|
client:
|
|
# The document, by value at a pinned ref: the lane fetches openapi.yaml at the
|
|
# ref .spec-lock names and refuses on a digest mismatch. It does not choose the
|
|
# ref and does not write the lock — on a push it is check-only at the locked
|
|
# one. What MOVES the pin is the nightly re-pin in .hanzo/workflows/drift.yml,
|
|
# which reads hanzo-inc/cloud's main and commits the result once `make verify`
|
|
# rules on it. Reading api.hanzo.ai here would name whatever is serving now
|
|
# rather than a release.
|
|
spec: { repo: hanzo-inc/cloud, path: openapi.yaml }
|
|
generate: ./scripts/generate.sh
|
|
# PATCH only, derived. The command surface is the document's; this crate only
|
|
# restates it, so it never earns a minor or a major.
|
|
version: "Cargo.toml:grep -m1 '^version' Cargo.toml | sed -E 's/.*\"(.*)\".*/\\1/'"
|
|
|
|
# THE CAPTURE GATE is NOT here, and that is the point: hanzoai/ci's `client:` lane
|
|
# asks it for all eight client repos in one place, on every push — fetch the
|
|
# document .spec-lock names, refuse if the ref moved under it, re-run the
|
|
# derivation, refuse any delta, write nothing. `make spec-check` is the same
|
|
# question a human asks locally, through the same script.
|
|
#
|
|
# THE DRIFT GATE is a different question — a capture can equal its inputs exactly
|
|
# and still describe a surface production stopped serving, or miss a product
|
|
# production started — and it IS here, inside `cargo test`, because it stopped
|
|
# needing the network. It rules on `spec/live.json`: the raw answers the live
|
|
# server gave to every probe and to a nonsense-sibling CONTROL for each, captured
|
|
# by `make live` and committed. So the push gate asks both directions on every
|
|
# push, in the one lane, with nothing to fail for a reason that is not drift.
|
|
#
|
|
# It used to need the wire, and that is what made it fragile: a gate needing the
|
|
# network in CI gets switched off, and this one first sat in the list below where
|
|
# a failure in the client step or the KMS login meant it was never reached at all.
|
|
# It was never asked once that way.
|
|
#
|
|
# What still needs the wire is the OTHER half — has production moved under the
|
|
# committed evidence? — and that has its own job, its own triggers and nothing
|
|
# else in it: `.hanzo/workflows/drift.yml`, nightly and on a click, `make
|
|
# live-check`. One predicate per place, and neither shares its fate with anything.
|
|
#
|
|
# `make test`, never a bare `cargo test`: the gates below exec maintainer
|
|
# binaries that `cargo test` does not build, and a gate that dies on NotFound
|
|
# reads exactly like a gate that passed. One invocation, in the Makefile.
|
|
#
|
|
# THE LINT GATE HAS TO INSTALL WHAT IT LINTS WITH. `dtolnay/rust-toolchain@stable`
|
|
# provisions rustc and cargo and no components, so `cargo clippy` answered
|
|
# "'cargo-clippy' is not installed for the toolchain" and every main build went
|
|
# red on it — six in a row, while `make test` above passed every one of them. A
|
|
# gate that cannot run is worse than no gate whichever way it lands: red, it
|
|
# teaches people the build lies; green, it teaches them nothing at all. It asks
|
|
# for the component first now, which is idempotent and costs a cached download.
|
|
test:
|
|
- name: cargo-test
|
|
run: make test
|
|
- name: clippy
|
|
run: rustup component add clippy && cargo clippy --locked --all-targets -- -D warnings
|