static/hanzo.yml

# Canonical CI config for hanzoai/static — read by platform.hanzo.ai (the forge
# system webhook, which schedules one BuildKit Job per declared image on a push)
# and the hanzoai/ci reusable that .hanzo/workflows/cicd.yml imports. Without this file the lane answers "declares no
# image to build" and nothing ships, which is why v0.5.6–v0.5.9 built no image.
#
# One image: the scratch-based Go edge server (cmd/static) that fronts every
# hanzoai static site. A main push builds ghcr.io/hanzoai/static:sha-<sha7>; a v*
# tag builds the bare semver. Pin site values files to the sha or the semver.
#
# source: forge — this repo is forge-primary. The GitHub original moved to a
# private org, so the builder's default context github.com/hanzoai/static no
# longer exists; the canonical tree is git.hanzo.ai/hanzoai/static.
source: forge
images:
  - name: static
    context: .
    dockerfile: Dockerfile
    repo: ghcr.io/hanzoai/static
    # Two architectures, one manifest list. This server fronts every hanzoai
    # static site, so it is the base layer under a large part of the estate:
    # when it ships amd64 only, every site built on it is unschedulable on an
    # arm64 node, and the kubelet's complaint names the base image rather than
    # the site — "no match for platform in manifest". 0.4.1 was multi-arch and
    # the series lost arm64 when the build lane moved to a single amd64 runner,
    # so this line is what stops it being lost again.
    platforms: [linux/amd64, linux/arm64]

# cmd/static is an edge server that fronts every hanzoai static site, and until
# now it shipped with nothing asserting it compiles: the image lane was the only
# lane, so a build failure and a test failure were the same event, discovered at
# the same time, by the same person — at deploy.
#
# This is the linux half of the go-cross matrix that used to live in
# .github/workflows. That matrix ran ubuntu, macOS and windows against Go 1.22
# and 1.x; the fleet is linux/amd64 containers, so the other five legs had no
# runner. They were not covering anything either — on GitHub the same workflow
# failed 28 of its last 33 runs.
#
# CGO_ENABLED=0 because that is how the Dockerfile builds it: the image is
# scratch-based and a cgo binary would not run in it, so a gate built any other
# way is not gating the artifact.
test:
  - name: test
    run: |
      set -euo pipefail
      CGO_ENABLED=0 go build ./...
      CGO_ENABLED=0 go vet ./...
      CGO_ENABLED=0 go test -cover ./...