Files
mod/hanzo.yml
T
zooqueen f20c02ec0a mod: answer for our module names, read from the forge
A module path is identity, not an address: `module github.com/hanzoai/o11y` is
what every dependent's go.mod names, so the toolchain took a direct VCS fetch to
github.com and needed a credential valid there. This answers for the name and
reads the source from git.hanzo.ai, so a build resolves the module it already
names with no GitHub credential in it.

Resolution is the toolchain's own — module zips have rules about nested modules,
vendor directories, symlinks, file modes and case collisions, and a zip that gets
one wrong hashes differently and fails every caller's go.sum.

Clients set GOPROXY and GONOSUMDB. Not GOPRIVATE: it means "bypass the proxy AND
the checksum database", and bypassing the proxy is what reaches for github.com.
Skipping the public checksum database for our namespaces is not skipping
verification — go.sum still pins every module and is checked against these bytes.

Inside our namespaces a failure answers 502, never 404: in this protocol 404
means "ask the next proxy", and the next proxy is public.
2026-08-19 22:32:24 -07:00

48 lines
1.6 KiB
YAML

# mod — the ONE file that says how this repo builds, gates and ships.
#
# The only workflow is `.hanzo/workflows/cicd.yml`, which imports hanzoai/ci.
# Everything real is here, and platform.hanzo.ai reads this same file.
# GOWORK=off so a go.work in a parent directory cannot change which modules
# resolve — CI must read this repo's go.mod and nothing else.
test:
- name: go-build
run: |
set -e
export GOWORK=off CGO_ENABLED=0
go build ./...
- name: go-vet
run: |
set -e
export GOWORK=off CGO_ENABLED=0
go vet ./...
- name: go-test
# The tests that matter here answer one question: what does this proxy tell
# the go command to do when it cannot resolve something. A 404 inside our
# namespaces sends the go command to the next proxy carrying the module
# path, and the next proxy is public — so the boundary is asserted, not
# assumed. They need no network: the fixture points at a forge that cannot
# resolve, which is exactly the failing case under test.
run: |
set -e
export GOWORK=off CGO_ENABLED=0
go test -count=1 ./...
version: 0.1.0
images:
- name: mod
context: .
dockerfile: Dockerfile
repo: ghcr.io/hanzoai/mod
# amd64 only: the cluster has no arm64 nodes. Add linux/arm64 when
# something pulls it.
platforms: [linux/amd64]
# No `deploy:`. Which build runs is a reviewed change in hanzoai/universe,
# synced by cd.hanzo.ai. Every Go build in the estate resolves through this
# service, so "which binary is answering for our module names" is not something
# that should move as a CI side effect.