Files
zeekay 2b14fd1659 Compute: the module, the binary and the image say so
Cloud's side of this rename landed some time ago — the app is apps/compute,
the env is COMPUTE_URL — and left a note saying the other half moves with
the manifest that names it. This is the half that does not touch the
cluster: the Go module is github.com/hanzoai/compute, the binary it builds
is compute, and the image is ghcr.io/hanzoai/compute. GitHub already
carries the new name.

What is deliberately NOT here is the cutover. The Service universe declares
is still visor, and so are visor-config, visor-kms-sync and visor-db-bucket.
Pointing anything at compute.hanzo.svc before those move resolves to
nothing, so they move together, in universe, not here.
2026-09-07 17:37:50 -07:00

35 lines
1.5 KiB
YAML

# Hanzo Visor — the one file that says how this repo builds, gates and ships.
#
# It replaces a caller of hanzoai/.github's docker-build.yml, which built and
# pushed to ghcr and stopped there. hanzoai/ci's build.yml does the same push and
# then copies the exact tag set to oci.hanzo.ai — server-side, no rebuild — so the
# image exists at both addresses. ghcr stays: it is the public mirror, the same
# arrangement source already has, where the forge is canonical and GitHub mirrors
# it. What changed is that ours gets a copy at all.
#
# The version is DERIVED, never typed. This repo carries no package.json,
# Cargo.toml, VERSION or pyproject.toml, so imgver reads the registry floor —
# the highest semver already published for this image — and publishes the next
# patch. ghcr.io/hanzoai/visor is at 1.108.30, so the next build is 1.108.31 and
# the series this repo has been on since 1.108.x continues unbroken. Adding a
# VERSION file later would take precedence; there is no reason to.
test:
- name: build-and-vet
run: |
set -e
go build ./...
go vet ./...
images:
- name: compute
context: .
dockerfile: Dockerfile
repo: ghcr.io/hanzoai/compute
# amd64-only, carried over from the previous caller and still true: DOKS has
# no arm64 droplets, so there is no arm64 deploy target, and a queued arm64
# job would block the manifest step behind a runner that never claims it.
platforms:
- linux/amd64
- linux/arm64