name: docker-control

# Builds the control-layer image (the `handler` CLI / CI poller) from Dockerfile.control
# and publishes it to GHCR alongside the API image built by docker.yml.

on:
  push:
    branches: [main]
    tags: ["v*"]
  pull_request:
    branches: [main]

env:
  IMAGE: ghcr.io/${{ github.repository }}/control

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to GHCR
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Tags: branch name on branch pushes, semver on v* tags, short SHA always,
      # `latest` only on the default branch. metadata-action lowercases the repo
      # name (GHCR requires lowercase).
      #
      # The <timestamp>-<sha> tag is what Flux's ImagePolicy sorts on to pick the
      # newest build (see Talos: apps/handler/image-automation/imagepolicy.yaml).
      # It must be monotonic and sortable — `sha-<short>` has no ordering and
      # `latest` is mutable, so neither can drive image automation. UTC keeps it
      # monotonic across DST. Same scheme as apps/devbox.
      #
      # This image is built by a workflow SEPARATE from docker.yml and resolved by
      # a separate ImagePolicy. If this build fails while docker.yml succeeds, the
      # api container rolls and control stays behind, with both policies green —
      # the handler README's health check compares the two resolved tags for this
      # reason.
      #
      # Caveat: this is BUILD time, not commit time. Re-running an old commit's
      # build publishes <now>-<oldsha>, which sorts newest and would deploy older
      # code. Accepted (the sha in the tag makes it obvious after the fact) — but
      # prefer pushing a revert over re-running a stale build.
      - name: Docker metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.IMAGE }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha
            type=raw,value={{date 'YYYYMMDDHHmmss'}}-{{sha}},enable={{is_default_branch}}
            type=raw,value=latest,enable={{is_default_branch}}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          file: Dockerfile.control
          platforms: linux/amd64,linux/arm64
          # PRs build (to catch Dockerfile breakage) but never push.
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha,scope=control
          cache-to: type=gha,mode=max,scope=control