mirror of
https://github.com/hanzoai/otel-collector.git
synced 2026-10-30 18:26:25 +00:00
zeekayandHanzo Dev
b02b745126
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 Dev <[email protected]>
53 lines
2.7 KiB
YAML
53 lines
2.7 KiB
YAML
# Hanzo CI/CD — canonical build/test/deploy config for the O11y OTel Collector.
|
|
#
|
|
# ONE file, read by BOTH the forge caller (.hanzo/workflows/cicd.yml, which
|
|
# imports the reusable hanzoai/ci workflow) AND platform.hanzo.ai. The build runs
|
|
# on the git-runner fleet at git.hanzo.ai — the only pool serving
|
|
# linux-amd64. There is no arc pool; arc was retired 2026-08-01, and
|
|
# github.com has no runner for that label, which is why the caller lives under
|
|
# .hanzo/workflows and not .github/workflows.
|
|
#
|
|
# 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, datastore
|
|
# (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
|
|
|
|
# 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
|
|
# imgver DERIVES each tag as published+1, but this image has never been
|
|
# published, so there was nothing to derive from and it refused rather than
|
|
# ship a sha — correctly. The collector beside it needs no `version:` because
|
|
# the registry already answers for it (declared=none published=1.3.0 -> 1.3.1).
|
|
# This seeds the sequence once; every later tag comes from the registry, not
|
|
# from this line, so it does not need bumping by hand.
|
|
version: 0.1.0
|
|
|
|
# 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
|