# 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