mirror of
https://github.com/hanzoai/forge.git
synced 2026-10-30 15:00:39 +00:00
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]>
42 lines
2.2 KiB
YAML
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'
|