Files
mod/.hanzo/workflows/cicd.yml
T
zooqueen 23753a4cfe state the toolchain this binary is built with, and keep the caller on v1
go.mod said `go 1.26`, a floor of 1.26.0, while the Dockerfile pins
golang:1.26.5-bookworm. Nothing imports this — it is a binary — so the directive
constrains only its own build, and naming the patch says which toolchain it is
actually built and tested with rather than one it happens to clear.

The caller goes back to @v1. Pinning an immutable tag there looked like a canary
and is not one: this forge leaves GITHUB_WORKFLOW_REF unset, so build.yml clones
its own bin/ tools from `v1` whatever ref the caller named. A caller pinned
elsewhere gets that build.yml against v1's tools, which is the skew the
pipeline's own tool check exists to catch.
2026-08-19 22:54:16 -07:00

31 lines
1.1 KiB
YAML

name: CI/CD
# The caller, and deliberately nothing else: triggers plus the import. All real
# config is the repo-root hanzo.yml, which platform.hanzo.ai reads too.
#
# `.hanzo/workflows`, NOT `.github/workflows`: the `git-runner` StatefulSet
# registers against the forge only, and that is the pool advertising the
# `hanzo-build-linux-amd64` label. A job asking for it on github.com is never
# claimed — it waits out the timeout rather than failing.
on:
push:
branches: [main]
# A `v*` tag is a RELEASE and publishes an image named after it, verbatim.
tags: ['v*']
workflow_dispatch:
concurrency:
group: cicd-${{ github.ref }}
cancel-in-progress: true
jobs:
cicd:
# `@v1`, and pinning an immutable tag here would be worse than useless: this
# forge leaves GITHUB_WORKFLOW_REF unset, so build.yml clones its own bin/
# tools from `v1` whatever the caller asked for. A caller pinned elsewhere
# gets that build.yml against v1's tools — the skew the pipeline's own tool
# check exists to catch. One ref or none.
uses: hanzoai/ci/.hanzo/workflows/build.yml@v1
secrets: inherit