f8e24bd1bdfdff73795b87bdc061b4af58122f76
CI/CD / render (push) Waiting to run
Universe CI / Resolve Environment (push) Successful in 0s
Universe CI / Update Manifest (push) Skipped
Universe CI / E2E (push) Failing after 10m20s
hanzo-build-linux-amd64, lux-build-linux-amd64, zoo-build-linux-amd64 and every other org-prefixed spelling all meant the same machine. Which org a job belongs to does not change which host can build it, so the org bought one pool name per org per arch and each could go stale on its own -- the evo host alone answered to fourteen names for one label. One vocabulary now: linux-amd64, linux-arm64, macos-arm64, win-amd64. The generic labels every plain workflow uses (ubuntu-latest, self-hosted) are untouched, so naive CI keeps working. Co-authored-by: Hanzo AI <[email protected]>
Zoo Universe — retired
Read-only from here. Canonical: https://git.hanzo.ai/zoo/universe
This tip is an ancestor of canonical main, so no commit reachable from this
branch is unique to it — the canonical repo is a strict superset. Nothing was
lost by stopping here.
Two universes for one org is a split brain: a push lands somewhere real, reports
success, and never reaches a cluster, because CD reconciles the other one
(deploy/applicationset.yaml names the canonical URL). One repo per org means
that failure cannot happen.
Description
Declared state for the zoo fleet: one values file per service, one ApplicationSet
1.2 MiB
Languages
TypeScript
70.1%
Shell
21.5%
Makefile
8.4%