mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
zeekayandHanzo Dev
f8f7a96592
An unqualified FROM takes the builder's architecture, so 0.1.23 came out arm64 while the values file pinned the pod to the amd64 node, where qemu-binfmt ran it rather than refusing it: Running, empty log, no listener. An index leaves the scheduler nothing to get wrong. Co-authored-by: Hanzo Dev <[email protected]>
67 lines
3.4 KiB
YAML
67 lines
3.4 KiB
YAML
# CI/CD config for hanzoai/team, read by the hanzoai/ci reusable workflow
|
|
# (.hanzo/workflows/cicd.yml) and by platform.hanzo.ai. One image: the root
|
|
# Dockerfile builds the web app and the server from this tree and assembles the
|
|
# runtime layout the binary looks for. hanzo.team runs it from a values file in
|
|
# hanzoai/universe.
|
|
#
|
|
# No deploy: here. cd.hanzo.ai runs with selfHeal, so a tag written anywhere but
|
|
# the universe pin is restored away on the next poll; recording it there is the
|
|
# only durable path.
|
|
#
|
|
# The build door takes an owned registry -- ghcr.io/{hanzoai,luxfi,zooai} -- and
|
|
# answers 403 for any other host, so the image name is where the org already
|
|
# keeps its packages.
|
|
images:
|
|
- name: server
|
|
context: .
|
|
dockerfile: Dockerfile
|
|
repo: ghcr.io/hanzoai/team
|
|
# ARG BUILD_NUMBER is ldflagged into model.BuildNumber and reported on
|
|
# /v1/workspace/config/client. Unpassed it stays 'dev', and a rollout then
|
|
# has no answer to which build is serving. hanzoai/ci substitutes
|
|
# ${VERSION} from the tag it builds.
|
|
args:
|
|
BUILD_NUMBER: '${VERSION}'
|
|
# Both, because the fleet runs both and a single-architecture image makes
|
|
# the values file carry a nodeSelector to keep the pod away from the node it
|
|
# cannot run on. It is nearly free: every builder stage in the Dockerfile
|
|
# names BUILDPLATFORM, so the npm install, the webpack bundle and the tools
|
|
# layer are built once and shared, and only the Go compile repeats — as a
|
|
# cross-compile, which costs nothing at CGO_ENABLED=0. Nothing runs emulated.
|
|
platforms: [linux/amd64, linux/arm64]
|
|
|
|
# The Go and web app compiles both happen inside the Dockerfile, so a broken
|
|
# tree already fails the image build. This gate covers the two things the image
|
|
# build cannot catch, because both are behaviour rather than compilation: the
|
|
# claim mapping that decides who a signing-in user is, and the tenant boundary
|
|
# that decides which team they land in. Getting either wrong puts a user in
|
|
# another org's channels.
|
|
test:
|
|
- name: iam-provider
|
|
run: cd server && go test ./channels/app/oauthproviders/hanzo/...
|
|
|
|
- name: boots
|
|
# The one thing a compile cannot answer: does the program START.
|
|
#
|
|
# A renamed Go module put two copies of server/public in the binary, and
|
|
# public/plugin registers []*model.SlackAttachment with gob from each — a
|
|
# duplicate name, so the panic fires in init, before main. `go build ./...`
|
|
# and `go vet ./...` were both clean over it; `mattermost version` was not,
|
|
# and the deployment answered from an older build for a fortnight. Nothing
|
|
# else here reads that difference, and the image build least of all, since a
|
|
# Dockerfile that compiles is a Dockerfile that succeeds.
|
|
#
|
|
# `-tags production`, because that is how the image is built, and the tag
|
|
# selects a different service environment in server/public/model. A gate
|
|
# compiling the other one is testing a program we do not ship.
|
|
#
|
|
# GOWORK is left ALONE. The estate's other manifests export GOWORK=off, and
|
|
# here that resolves ./public from the proxy instead of this tree: the build
|
|
# then dies on go.sum entries no module in the graph can supply.
|
|
run: |
|
|
set -e
|
|
cd server
|
|
CGO_ENABLED=0 go build -tags production -o "${RUNNER_TEMP:-/tmp}/" ./cmd/mattermost ./cmd/mmctl
|
|
"${RUNNER_TEMP:-/tmp}/mattermost" version
|
|
"${RUNNER_TEMP:-/tmp}/mmctl" version
|