billing/.hanzo/workflows/deploy.yml

# billing — build the image, then ship it.
#
#   git.hanzo.ai push → act_runner (in-cluster, privileged dind)
#   → docker build → ghcr.io/hanzoai/billing:<semver>
#   → universe pin → cd.hanzo.ai reconciles
#
# GitHub Actions is disabled account-wide, so `.github/workflows/*` cannot build.
# This is the real pipeline. No GitHub builders — and since
# actions-runner-controller was decommissioned 2026-07-27, it is the only CI
# this repo has.
#
# SEMVER, NEVER SHA. This built `sha-<sha7>` and stopped at "the image resolves",
# which broke the fleet rule twice over: a sha cannot be read, ordered, or rolled
# back to by a human, and nothing moved the pin afterward — so every build since
# 1.0.5 published a tag no values file has ever named.
#
# The old header argued CI should end at "the tag exists and resolves" because
# choosing which tag runs is a reviewed change. That safety now lives in pin.sh,
# which applies the same rules on every release instead of relying on someone
# reading the log: it refuses a non-semver version, an image the registry cannot
# serve, a version older than the current pin, and a repository the caller chose
# rather than the one the values file declares.
#
# THE NEXT PATCH COMES FROM THE REGISTRY, NOT FROM `git tag`. What is published
# is the only authority on what has been used; deriving from git can re-emit a
# live tag and leave two digests behind one name.
#
# This service publishes a BARE tag (1.0.5, no leading v). The step below works
# in that shape, and pin.sh carries the convention through from the values file —
# which is what lets one script serve both halves of an inconsistent fleet.
name: deploy
on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: deploy-billing-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build:
    # Must name a label a runner ACTUALLY advertises. The git-runners offer
    # hanzo-build-linux-amd64; a label nothing offers does not fail, it queues
    # until the 24h timeout — silence, not an error.
    runs-on: [hanzo-build-linux-amd64]
    steps:
      - uses: actions/checkout@v4

      # Without this the push is unauthenticated and 403s at the registry.
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ secrets.GHCR_USER }}
          password: ${{ secrets.GHCR_TOKEN }}

      # Derived from what is PUBLISHED, then proven unused before anything is
      # pushed. The first half stops us colliding with a tag git does not know
      # about; the second stops us overwriting one at all.
      - name: Next patch semver
        id: ver
        env:
          GHCR_USER: ${{ secrets.GHCR_USER }}
          GHCR_TOKEN: ${{ secrets.GHCR_TOKEN }}
        run: |
          set -euo pipefail
          TOKEN=$(curl -fsSL -u "$GHCR_USER:$GHCR_TOKEN" \
            "https://ghcr.io/token?scope=repository:hanzoai/billing:pull&service=ghcr.io" | jq -r .token)

          LAST=$(curl -fsSL -H "Authorization: Bearer $TOKEN" \
            "https://ghcr.io/v2/hanzoai/billing/tags/list?n=10000" \
            | jq -r '.tags[]? | select(test("^[0-9]+\\.[0-9]+\\.[0-9]+$"))' \
            | sort -V | tail -1)

          # Fail loudly rather than guessing. A silent fallback would eventually
          # re-emit a live tag, which is what this step exists to prevent.
          if [ -z "${LAST:-}" ]; then
            echo "::error::could not read published semver tags from GHCR — refusing to guess the next patch"
            exit 1
          fi

          IFS=. read -r MAJ MIN PAT <<<"$LAST"
          NEXT="$MAJ.$MIN.$((PAT + 1))"

          # 404 is the ONLY acceptable answer: anything else means the tag is
          # taken (200) or we cannot tell (network/auth), and pushing on either
          # risks a second digest behind an existing name.
          CODE=$(curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $TOKEN" \
            -H 'Accept: application/vnd.oci.image.index.v1+json,application/vnd.docker.distribution.manifest.list.v2+json,application/vnd.docker.distribution.manifest.v2+json,application/vnd.oci.image.manifest.v1+json' \
            "https://ghcr.io/v2/hanzoai/billing/manifests/$NEXT")
          if [ "$CODE" != "404" ]; then
            echo "::error::refusing to push $NEXT — manifest probe returned $CODE, expected 404 (tag taken, or existence unverifiable)"
            exit 1
          fi

          echo "version=$NEXT" >> "$GITHUB_OUTPUT"
          echo "last published $LAST -> building $NEXT"

      - uses: docker/setup-buildx-action@v3
        with: { driver: docker-container, driver-opts: network=host }

      - uses: docker/build-push-action@v6
        with:
          context: .
          file: ./Dockerfile
          platforms: linux/amd64
          push: true
          provenance: false
          tags: ghcr.io/hanzoai/billing:${{ steps.ver.outputs.version }}
          # The commit rides the image, so dropping it from the tag loses
          # nothing: `docker inspect` still answers which source built this.
          labels: |
            org.opencontainers.image.revision=${{ github.sha }}
            org.opencontainers.image.version=${{ steps.ver.outputs.version }}
            # Canonical, not the redirect: this repo lives in the hanzo-inc org
            # and GitHub only resolves the old name until somebody creates a repo
            # there. This label is how a tool finds an image's source, so a stale
            # name here is provenance that quietly points somewhere else.
            org.opencontainers.image.source=https://github.com/hanzo-inc/billing
          secrets: |
            GIT_AUTH_TOKEN=${{ secrets.GH_PAT }}

      # build-push-action can exit 0 before the manifest resolves, so a green run
      # could still mean a future ImagePullBackOff. Prove it pulls BEFORE the pin
      # moves — pinning an image the registry cannot serve has no rollback path.
      - name: Verify the pushed image resolves
        run: |
          set -euo pipefail
          img="ghcr.io/hanzoai/billing:${{ steps.ver.outputs.version }}"
          for i in 1 2 3 4 5 6; do
            docker buildx imagetools inspect "$img" >/dev/null 2>&1 && { echo "resolved $img"; exit 0; }
            sleep 5
          done
          echo "::error::pushed image never resolved: $img"; exit 1

      # THE DEPLOY. Everything above publishes an image; this is what makes
      # production run it. cd.hanzo.ai watches hanzoai/universe, not the
      # registry, so an image nothing points at is just bytes in ghcr.
      - name: Ship it
        env:
          KMS_CLIENT_ID: ${{ secrets.KMS_CLIENT_ID }}
          KMS_CLIENT_SECRET: ${{ secrets.KMS_CLIENT_SECRET }}
          KMS_ENDPOINT: ${{ vars.KMS_ENDPOINT || 'https://kms.hanzo.ai' }}
          KMS_SECRET_ENV: ${{ vars.KMS_SECRET_ENV || 'prod' }}
          # pin.sh probes the registry before it moves anything; these let it read
          # a private manifest instead of falling back to anonymous.
          GHCR_USER: ${{ secrets.GHCR_USER }}
          GHCR_TOKEN: ${{ secrets.GHCR_TOKEN }}
        run: |
          set -euo pipefail
          VERSION="${{ steps.ver.outputs.version }}"

          # Secrets come from KMS, never from a file or a repo variable.
          KMS_TOKEN=$(curl -sS "${KMS_ENDPOINT}/v1/kms/auth/login" \
            -H 'Content-Type: application/json' \
            -d "{\"clientId\":\"${KMS_CLIENT_ID}\",\"clientSecret\":\"${KMS_CLIENT_SECRET}\"}" \
            | jq -r '.accessToken // empty' || true)
          [ -n "$KMS_TOKEN" ] || { echo "::error::KMS login failed at ${KMS_ENDPOINT}"; exit 1; }

          # THERE IS NO ORG IN A KMS PATH. The store root comes from the
          # validated claim, so the org is the credential's, not the URL's —
          # that is what makes another tenant's secret unnameable rather than
          # merely refused. The /orgs/<org>/ spelling was never a route the
          # broker has; it 404'd this step on every run (cloud's rollout had
          # the identical bug, fixed the identical way).
          PIN_TOKEN=$(curl -sS \
            "${KMS_ENDPOINT}/v1/kms/secrets/deploy/UNIVERSE_PIN_TOKEN?env=${KMS_SECRET_ENV}" \
            -H "Authorization: Bearer ${KMS_TOKEN}" | jq -r '.value // .secret.value // empty' || true)
          [ -n "$PIN_TOKEN" ] || { echo "::error::UNIVERSE_PIN_TOKEN missing in KMS at deploy/ (env ${KMS_SECRET_ENV}, org from the KMS credential)"; exit 1; }
          echo "::add-mask::${PIN_TOKEN}"

          # Shallow: universe is ~600MB of history and this needs one file from
          # the tip.
          git clone --quiet --depth 1 \
            "https://x-access-token:${PIN_TOKEN}@git.hanzo.ai/hanzo/universe" /tmp/universe

          # Another service can land its own pin between our clone and our push.
          # That is a normal race, not a failure — but a shallow clone has no
          # common history to rebase onto, so RE-APPLY rather than merge: reset to
          # the new tip and pin again. Pinning is idempotent and derives
          # everything from the file it finds, so the retry also re-checks the
          # monotonic guard against whatever just landed.
          for attempt in 1 2 3 4 5; do
            /tmp/universe/charts/app/pin.sh billing "$VERSION"

            if git -C /tmp/universe push --quiet origin HEAD:main 2>/dev/null; then
              echo "pinned billing to ${VERSION}"; exit 0
            fi

            echo "universe moved under us (attempt ${attempt}/5) — re-applying on the new tip"
            git -C /tmp/universe fetch --quiet --depth 1 origin main
            git -C /tmp/universe reset --hard --quiet FETCH_HEAD
          done
          echo "::error::could not push the pin after 5 attempts"; exit 1