Files
zooqueen 3da8f28e31 hanzo.yml: drop the deploy: block, which no longer does anything
hanzoai/ci no longer has a deploy step. It cloned a universe repo that 404s,
wrote to a CR directory that universe deleted, and fell back to a kubectl patch
the cluster rejects — so this block has been declaring a rollout that never
happened.

What runs is declared in hanzo/universe, which cd.hanzo.ai reads and applies
within one poll. The build still publishes the image.
2026-08-11 16:28:18 -07:00

44 lines
2.1 KiB
YAML

# Hanzo CI/CD — canonical build/test/deploy config for the O11y OTel Collector.
#
# ONE file, read by BOTH GitHub Actions (via .github/workflows/cicd.yml, which
# imports the reusable hanzoai/ci workflow) AND platform.hanzo.ai. The build runs
# on our self-hosted arc pool (hanzo-build-linux-amd64) — ZERO GitHub-hosted
# minutes; GitHub only orchestrates, our infra does the work.
#
# This is the going-forward pattern for every native-PaaS repo: a root hanzo.yml
# + a ~7-line cicd.yml. See README.md § "CI/CD — canonical pattern".
images:
# The ZAP-native O11y collector. filelog / OTLP / ZAP in, ClickHouse
# (hanzoai/datastore) out. Dockerfile.selfbuild is a self-contained multi-stage
# build that COMPILES the collector in-image — including receiver/zapreceiver +
# exporter/zapexporter — so no CI pre-build step is needed (unlike ./Dockerfile,
# which COPYs a pre-built binary). tag-suffix qualifies every tag, e.g.
# ghcr.io/hanzoai/otel-collector:zap-native-latest
# ghcr.io/hanzoai/otel-collector:sha-<short>-amd64-zap-native (immutable)
- name: collector
repo: ghcr.io/hanzoai/otel-collector
context: .
dockerfile: cmd/o11yotelcollector/Dockerfile.selfbuild
tag-suffix: zap-native
# ClickHouse schema migrator — creates/updates the o11y_logs / o11y_traces /
# o11y_metrics DDL in hanzoai/datastore. Self-building (mirrors the collector).
- name: schema-migrator
repo: ghcr.io/hanzoai/o11y-schema-migrator
context: .
dockerfile: cmd/o11yschemamigrator/Dockerfile.selfbuild
# NOTE: no `test:` here. The reusable runs `test:` on a bare arc runner (no Go
# toolchain; DinD daemon, so bind-mounts don't cross), so the ZAP-surface gate
# (`go test ./receiver/zapreceiver/... ./exporter/zapexporter/...`) lives in the
# collector's Dockerfile.selfbuild build stage instead — where the toolchain and
# source already are, and a failing test fails the image. One gate, one place.
# Deploy credentials (KUBECONFIG) are org-scoped in KMS; the build/push path uses
# the automatic GitHub workflow token, so KMS is only needed for the deploy step.
kms:
org: hanzo
environment: prod
path: /deploy