apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
# Single source of truth for every Plevion-built image's tag in the `local`
# environment. See plevion-docs/SPEC_K8S_DEPLOYMENT_HARDENING.md ("Tech Stack
# Decisions -> Versions mechanism") for why this is a Component (not a plain
# `images:` block in the top-level kustomization) and why it must be named
# `kustomization.yml` (Kustomize's Component requirement, not a free choice).
#
# Each `newTag:` line carries a Flux `$imagepolicy` marker comment so Phase 2
# (in-cluster image automation, not yet built) can write to this file directly
# without a shape change -- inert until Phase 2's ImagePolicy objects exist.
images:
  - name: ghcr.io/plevion-dev/auth
    newTag: v0.0.72-abc1234 # {"$imagepolicy": "flux-system:auth-policy:tag"}
  - name: ghcr.io/plevion-dev/orchestrator
    newTag: v0.0.81-bfa5a93 # {"$imagepolicy": "flux-system:orchestrator-policy:tag"}
  - name: ghcr.io/plevion-dev/sink
    newTag: v0.0.187-c9d5825 # {"$imagepolicy": "flux-system:sink-policy:tag"}
  - name: ghcr.io/plevion-dev/sink-capturer
    newTag: v0.0.187-c9d5825 # {"$imagepolicy": "flux-system:sink-capturer-policy:tag"}
  # Pinned to each repo's actual most-recently-published GHCR tag, confirmed
  # by matching manifest digests (registry API, not guessed from git log) --
  # see PLAN_K8S_DEPLOYMENT_HARDENING_PHASE1.md Task 1's notes. edge-controller/
  # frontend-admin/frontend-landing/authmtx/mediamtx's digests matched exactly
  # what the live cluster was already running under `:latest` (true no-op).
  # kong did NOT match any of its own published tags -- the locally-cached
  # `:latest` pull predates all 4 currently-published kong tags, so pinning it
  # to the newest one (v0.0.8-e237021) is a real upgrade, not a no-op; watched
  # closely on apply since Kong is on the critical path for all ingress.
  - name: ghcr.io/plevion-dev/edge-controller
    newTag: v0.0.44-beb8891 # {"$imagepolicy": "flux-system:edge-controller-policy:tag"}
  - name: ghcr.io/plevion-dev/frontend-admin
    newTag: v0.0.87-88ba3ab # {"$imagepolicy": "flux-system:frontend-admin-policy:tag"}
  - name: ghcr.io/plevion-dev/frontend-landing
    newTag: v0.0.33-1878333 # {"$imagepolicy": "flux-system:frontend-landing-policy:tag"}
  - name: ghcr.io/plevion-dev/authmtx
    newTag: v0.0.43-199dc84 # {"$imagepolicy": "flux-system:authmtx-policy:tag"}
  - name: ghcr.io/plevion-dev/mediamtx
    newTag: 1.19.1-b413fa9 # {"$imagepolicy": "flux-system:mediamtx-policy:tag"}
  - name: ghcr.io/plevion-dev/kong
    newTag: v0.0.8-e237021 # {"$imagepolicy": "flux-system:kong-policy:tag"}
# NOTE: the plevion-platform-version ConfigMap (platform-level release
# marker, see its own comment block) deliberately does NOT live in this
# Component -- it's generated inline in services/overlays/local/
# kustomization.yml instead. This Component is referenced from multiple
# build scopes (services/overlays/local, services/overlays/
# local-with-frontend, environments/local) -- images: is idempotent under
# repeat application, but a configMapGenerator is not: two references to
# the same generator within one accumulated build collide ("exists; behavior
# must be merge or replace"), which is exactly what happened when
# local-with-frontend referenced this Component directly while also pulling
# it in transitively via ../local. Keeping the generator inline, in the one
# place (services/overlays/local) every other build either targets directly
# or includes transitively exactly once, avoids the collision entirely.
