Files
zeekayandHanzo Dev bbd701d1e0 Correct the architectures this lane publishes
The comment claimed declaring nothing gives both. Both lanes in hanzoai/ci
read `.platforms // ["linux/amd64"]`, so a repo that declares nothing
publishes one — which is how sql:18 went from a two-arch index in March to
a single amd64 manifest in August.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-08 22:22:35 -07:00

42 lines
2.2 KiB
YAML

# Canonical CI/CD config for hanzoai/git — read by both the hanzoai/ci reusable
# workflow (.github/workflows/cicd.yml) and platform.hanzo.ai. One image: the
# multi-stage root Dockerfile builds the web frontend and the `gitd` daemon and
# bakes in the Hanzo Git branding (logo, favicon, app name, footer). git.hanzo.ai
# runs this image via the `git` operator App CR in hanzoai/universe; config is
# injected via the GIT__<section>__<KEY> env contract. No deploy: here — the App
# CR pins a semver tag, bumped by a reviewed universe change, not auto-rolled.
#
# No platforms: yet, and that publishes amd64 alone — hanzoai/ci reads
# `.platforms // ["linux/amd64"]` on BOTH lanes, so 1.26.57 is a two-arch index
# only because it was built by hand. The Dockerfile is ready: the frontend stage
# pins $BUILDPLATFORM and the Go stages take the target. Getting both needs
# `platforms:` here plus `mode: delegate` in cicd.yml, and two things stop that
# lane today — the live cloud revision decodes runnerBuildReq.Platforms and drops
# it, and the delegate POST carries no args, so GIT_VERSION below would vanish
# and the daemon would report 0.0.0+unknown.
#
# GIT_VERSION reaches the Makefile as the VERSION file. The build context is an
# export rather than a clone, so without this arg the daemon reports
# 0.0.0+unknown and no running forge can name the build it came from.
version: 1.26.56
images:
- name: git
context: .
dockerfile: Dockerfile
repo: ghcr.io/hanzoai/git
args:
GIT_VERSION: ${VERSION}
# The Go + frontend compile happens inside the Dockerfile, so a broken tree fails
# the image build already. This gate stays light and targeted: the setting unit
# tests exercise the config-env prefix + work/custom path resolution the running
# deploy depends on.
test:
- name: go-test-setting
run: go test ./modules/setting/...
# Scoped by -run rather than taking the whole package: this gate exists for the
# task context a runner reads, and the actions suite is broad enough that an
# unrelated failure here would read as a config regression.
- name: go-test-actions-context
run: go test ./services/actions/ -run 'TestGitContext|Test_jobEmitterQueueHandler'