# Pipeline: a rolling-upgrade RELEASE GATE (m11p8) runs FIRST; only if it passes
# does Kaniko build the tidal-server image and push it to the in-cluster zot
# registry. DEPLOYMENT IS MANUAL (kustomize, from the orchard9-k3sf ops repo) —
# the old auto-`kubectl set image deployment/tidaldb` step was removed because it
# coupled every image build to a standalone roll and the cluster ops repo's
# contract is "manual deploy via scripts, no CI/CD deploy". The same
# `tidal-server` binary serves every subcommand (standalone AND multi-process
# `cluster --region`), so one image covers both deployments.
when:
  branch: main
  event: push

steps:
  # m11p8 release gate: prove a rolling upgrade under load loses no acknowledged
  # write and never stalls (mp_rolling_upgrade_no_loss_no_stall — a tier-3 test
  # spawning three real OS processes with a graceful SIGTERM → version-tagged
  # restart → heal-until-converged → fixpoint cycle). Serial (--test-threads 1):
  # the harness binds fixed ports and spawns real processes, so suites must not
  # overlap. A failure here BLOCKS the image build below — the gate, not the start.
  rolling-upgrade-gate:
    image: rust:1-bookworm
    commands:
      - apt-get update && apt-get install -y --no-install-recommends protobuf-compiler cmake clang
      - cargo test -p tidal-server --features cluster-e2e --test cluster_lifecycle
        mp_rolling_upgrade_no_loss_no_stall -- --nocapture --test-threads 1

  build:
    image: woodpeckerci/plugin-kaniko
    settings:
      repo: tidal/server
      dockerfile: docker/standalone/Dockerfile
      context: .
      tags:
        - latest
        - m8p10
        - ${CI_COMMIT_SHA}
      registry: registry.threesix.ai
      build_args:
        - TARGETPLATFORM=linux/amd64
      extra_args: --customPlatform=linux/amd64