zeekayandHanzo AI f8e24bd1bd
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
ci: a runner label names the platform, not the org
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]>
2026-09-08 12:08:01 -07:00
2026-09-03 11:04:58 -07:00
2026-02-14 05:27:03 -08:00
2026-09-03 21:32:55 -07:00
2026-03-26 22:45:36 -07:00

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.

S
Description
Declared state for the zoo fleet: one values file per service, one ApplicationSet
Readme
1.2 MiB
Languages
TypeScript 70.1%
Shell 21.5%
Makefile 8.4%