mirror of
https://github.com/hanzoai/mod.git
synced 2026-09-30 22:56:06 +00:00
zooqueen
3b922935a2
The estate is going fully open source, so the private-module credential problem is ending rather than being solved. Re-read against that, two reasons survive and one part of the design does not. Surviving, and neither depends on who may read a module: Authority — the forge answers for our module names, so a build does not need github.com to be up, willing, or still holding the repository. Retention — one cache, nothing prunes it. hanzoai/s3-go is 404 on GitHub and alive on the forge; builds only kept working because a cache elsewhere happened to still hold it. The 404 rule survives on a stronger argument than the one it was written for. It was about a module path travelling to a public service. The real reason is that 404 means "ask the next proxy" and the next proxy resolves github.com/hanzoai/x from github.com — so a 404 does not fail, it silently returns resolution to the host this exists to make unnecessary, and the build goes GREEN having used it. Behaviour unchanged; the test says why it is there. Not surviving: exempting our whole namespace from the public transparency log. That was privacy. The log is now asked about everything, ours included, and the check is worth more for our modules than anyone else's — this is the one place that reads the forge while the log remembers what was published under the same name. UNLOGGED replaces it: an explicit list, EMPTY by default, naming only what the log has never seen, shrinking to nothing as repositories are published. GOPRIVATE is gone from the server. It was redundant beside an explicit per-request GOPROXY, and it is the exact variable clients are told never to set. A test now asserts it is never set. FORGE_TOKEN becomes optional. Public forge repos are anonymously readable — verified, not assumed — so empty is a working configuration. The URL rewrite happens either way: reaching the forge and being allowed to read a given repository there are different questions, and dropping the rewrite would send our names back to github.com. Canary the caller on ci v1.0.75, which stopped gover reading `go 1.26` as a demand for Go 1.26.999 and refusing a builder that compiles it.
49 lines
1.7 KiB
YAML
49 lines
1.7 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, which resolves the name
|
|
# from github.com — so the build would go green having used the host this
|
|
# service exists to make unnecessary. That 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.
|