deploy.yml

# Deploy naar ZAD (Operations Manager) via RijksICTGilde/zad-actions.
#
# DRIE losse ZAD-projecten (deployments zijn geïsoleerd; cross-project bereik je via de
# https-ingress-URLs `<component>-<deployment>-<projectid>.rig.prd1.gn2.quattro.rijksapps.nl`):
#
#   uitvraag       (mpfb-8wh)     componenten: redis + uitvraag in de deployments
#                                 `test`/`pr-<n>`, plus logius-fsc{pg,mgr,ctl,outway,inway,
#                                 txlog} (FSC-peer van de uitvraag-organisatie) in de EIGEN,
#                                 preview-loze deployment `fsc-logius` — zie
#                                 demo/environment/logius/
#   externe-stubs  (mpfpsm-lcl)   componenten: profiel + notificatie (WireMock-stubs)
#   magazijnen     (mpfm-w3h)     componenten: magazijna + magazijnb in de deployments
#                                 `test`/`pr-<n>`, plus magazijna-fsc{pg,mgr,ctl,inway,
#                                 txlog} (FSC-provider-peer) in de EIGEN, preview-loze
#                                 deployment `fsc-magazijna` — zie
#                                 demo/environment/magazijn-a/
#
# Redis (sessiecache) draait per project intern (centrale ZAD-Redis v7 mist RediSearch);
# interne calls zijn http: redis via redis://…:6379. Het LDV-logboek draait op de
# PostgreSQL die het ZAD-platform per component levert (service `postgresql-database`,
# niet in de component-payloads hieronder — het platform provisioneert 'm zelf); de
# interne JDBC-verbinding daarheen is plaintext, waarvoor
# FBS_LDV_UNSAFE_ALLOW_PLAINTEXT_ENDPOINT aan blijft staan (rationale + voorwaarden in de
# KDoc van OutboundTlsValidator.requireHttps).
#
# HARDE VOORWAARDE voor plaintext-LDV met echte persoonsgegevens: het ZAD-project levert
# pod-to-pod transport-encryptie (mesh-mTLS), niet enkel netwerk-isolatie — de BSN in het
# LDV-dataSubjectId gaat anders onversleuteld over de draad (BIO 13.2.1 / AVG art. 32). De
# applicatie kan dit niet verifiëren; bevestig het per project in het deployment-runbook
# vóór je de override aanzet. Zonder die bevestiging: alleen synthetische test-data.
#
# App-config staat NIET hier (de deploy-action draagt geen env). Configureer de runtime-env
# éénmalig per component op de `test`-deployment van elk project in Operations Manager;
# previews erven via `clone-from: test`. Cross-project-URLs templaten op de ZAD-systeemvar
# `$DEPLOYMENT_NAME` (door ZAD geïnjecteerd + geëxpandeerd), zodat een preview met ZIJN EIGEN
# pr-<n>-buren praat — het doel-project-id staat vast in de URL. Bv. op uitvraag:
#   MAGAZIJN_A_URL=https://magazijna-$DEPLOYMENT_NAME-mpfm-w3h.rig...    (en magazijnb)
#   PROFIEL_SERVICE_URL=https://profiel-$DEPLOYMENT_NAME-mpfpsm-lcl.rig...
# En op magazijnen: AANMELD_URL → uitvraag-webhook (POST /api/v1/aanmeldingen),
# NOTIFICATIE_URL → notificatie-stub (POST /events).
#
# GESTAPELDE PR'S (base != main) deployen niet — zie het `branches`-filter hieronder. Hun
# wijzigingen belanden alsnog in een preview zodra ze de PR bereiken die wél op main mikt: die
# krijgt dan een `synchronize` en rolt zijn eigen pr-<n> opnieuw uit. Wat zo'n PR aan controles
# houdt: test, detekt-gate en infra-image-pins — die workflows draaien zichzelf op elke PR
# BEHALVE die naar main (`branches-ignore: [main]`), en worden voor een PR naar main juist hier
# aangeroepen. CodeQL en de fuzz-check draaien er NIET: codeql.yml filtert op main en
# cflite_pr.yml draait uitsluitend als aangeroepen workflow vanuit deze. Die dekking komt dus pas
# bij de PR naar main. Een gestapelde PR is inhoudelijk getoetst maar niet security-gescand; weeg
# dat mee bij het reviewen ervan.
#
# OPRUIMEN STAAT IN cleanup-preview.yml: het `branches`-filter hieronder mag niet op teardown
# drukken (rationale daar). De omgekeerde beweging — GitHub's automatische retarget náár main bij
# het mergen van de parent — is veilig: de checks zijn dan afwezig i.p.v. groen, en `strict: true`
# op main dwingt sowieso een verse run af.
#
# TIMEOUT-MINUTES OP ELKE JOB: GitHub's default is 360 minuten. Een job die hangt (netwerkstall,
# vastgelopen Testcontainer, een herintroduceerde wachtlus) houdt dan zes uur een runner bezet
# voordat iemand het merkt. De waarden hieronder staan op ~3× de waargenomen maximumduur, dus ruim
# genoeg voor een trage runner maar kort genoeg om verspilling te begrenzen. Jobs die een andere
# workflow aanroepen kunnen de sleutel niet dragen; die staat daar in de aangeroepen workflow.
#
# Repo-secrets (Settings → Secrets and variables → Actions):
#   ZAD_API_KEY_UITVRAAG    — API-key project mpfb-8wh
#   ZAD_API_KEY_PROFIEL     — API-key project mpfpsm-lcl (externe-stubs)
#   ZAD_API_KEY_MAGAZIJNEN  — API-key project mpfm-w3h
# (GH_ADMIN_TOKEN hoort bij het opruimen en staat beschreven in cleanup-preview.yml.)

name: Deploy ZAD

on:
  # `branches` filtert op de DOELbranch: alleen PR's naar main bouwen en deployen. Een gestapelde
  # PR (base = een feature-branch) draait deze workflow dus helemaal niet — geen build, geen
  # preview, en daarmee ook niets te gaten. Bewust hier en niet als `if:` per job: een job die via
  # `if:` overslaat rapporteert `skipped`, en dat telt als succes voor branch protection. De drie
  # `deploy-preview-*` zijn required contexts op main, dus zouden gestapelde PR's groene vinkjes
  # verzamelen voor deploys die nooit gedraaid hebben. GitHub herricht een gestapelde PR
  # automatisch naar main zodra de parent merget, zónder nieuw event — die stale vinkjes zouden
  # dan blijven staan. Zonder run zijn de checks afwezig, wat de merge wél blokkeert.
  #
  # Let op de bewuste asymmetrie met test.yml/detekt.yml/pin-consistency.yml: die dragen het
  # complement (`branches-ignore: [main]`), want een gestapelde PR verdient wél inhoudelijke
  # toetsing. Alleen de deploy valt weg. Samen dekken de twee filters elke PR precies één keer.
  pull_request:
    branches: [main]
    # Geen `closed`: het sluiten van een PR heeft hier niets te doen sinds het opruimen in
    # cleanup-preview.yml staat. Elke job zou eraan moeten ontsnappen met een
    # `action != 'closed'`-clausule, en de run zelf zou een lege, volledig overgeslagen run zijn.
    types: [opened, synchronize, reopened]
  push:
    branches: [main]

# Least-privilege default voor GITHUB_TOKEN: read-only op workflow-niveau; elke job die schrijft
# declareert zijn eigen scopes.
permissions: read-all

# GEEN workflow-brede concurrency. De toetsende checks draaien sinds #173 als jobs ín deze
# workflow; een workflow-brede groep met `cancel-in-progress: false` zou een opvolgende push laten
# wachten tot de vorige deploy klaar is én de achterhaalde testrun helemaal uit laten draaien —
# precies de verspilling die we wegnemen. Met `cancel-in-progress: true` zou een lopende ZAD-deploy
# halverwege afgebroken kunnen worden, wat een deployment in een inconsistente staat achterlaat.
# Beide eisen tegelijk kan alleen per job:
#   * build/toetsing → eigen groep met cancel-in-progress: true (achterhaald werk stoppen);
#   * deploy → eigen groep PER PROJECT + doel-deployment met cancel-in-progress: false
#     (nooit halverwege afbreken; per project apart zodat de drie parallelle jobs elkaar niet
#     blokkeren, wat met één gedeelde groep wél zou gebeuren). De drie project-opruim-jobs in
#     cleanup-preview.yml zitten in dezelfde groepen.

env:
  REGISTRY: ghcr.io
  PROJECT_UITVRAAG: mpfb-8wh
  PROJECT_EXTERNE_STUBS: mpfpsm-lcl
  PROJECT_MAGAZIJNEN: mpfm-w3h
  # Publiek infra-image (niet door de cleanup verwijderd). Pin in sync met compose.yaml
  # (zie pin-consistency.yml).
  #
  # Redis draait op ZAD zónder persistence: zet op de redis-component de runtime-env
  # `REDIS_ARGS=--save "" --appendonly no` (in Operations Manager, net als de overige
  # runtime-env hierboven). Het restricted SecurityContext (willekeurige non-root UID)
  # mag niet in de image-datadir `/data` schrijven, dus RDB-snapshots falen met
  # "Permission denied". Kan uit: de sessiecache is ephemeral en rekent nergens op
  # persistence (idempotente RediSearch-bootstrap, TTL-entries, crash-safe vangnet-lock).
  REDIS_IMAGE: redis/redis-stack-server:7.4.0-v3
  # Verse preview-provisioning (`clone-from: test` maakt nieuwe volumes + ingress aan) duurt
  # structureel langer dan het bijwerken van een bestaande deployment. De action-default van
  # 300s is daarvoor te krap: uitvraag en externe-stubs time-outen er reproduceerbaar op
  # ("Task did not complete within 300s"), terwijl de test-deploys (bestaande deployment) in
  # <100s klaar zijn en de default houden. Gelijkgetrokken met de gate-timeout (900s) zodat
  # er één marge-getal in deze workflow rondgaat.
  # Let op: dit is de wachttijd van de runner op de OM-task. De melding "timed out waiting for
  # application to be created" komt daarentegen van OM zelf (Argo-Application-wait) en wordt
  # NIET door deze waarde beïnvloed — die deploys landen alsnog gezond; opnieuw draaien volstaat.
  PREVIEW_TASK_TIMEOUT: '900'
  # Beide workflows geven deze header expliciet mee in plaats van op de action-default te leunen:
  # cleanup-preview.yml zoekt de comment op deze tekst, dus drift tussen plaatsen en opruimen laat
  # hem stil achter op een gesloten PR.
  COMMENT_HEADER: '## 🚀 Preview Deployment'

jobs:
  # Bepaalt in één keer wát er voor deze revisie moet draaien. Levert vier onafhankelijke
  # uitkomsten: `run` (code-checks), `deploy` (bouwen en uitrollen), `demo-only` (test-scope)
  # en `fuzz` (fuzz-ronde). Voor een bot-PR valt alléén het uitrollen af — tests, detekt en
  # fuzz draaien juist wél, want een dependency-bump hoort getoetst te worden.
  #
  # De build-, gate- en deploy-preview-jobs hangen aan `deploy`; een via `if` overgeslagen job ín
  # deze workflow telt als 'skipped' = succes voor de required checks, dus de merge blijft
  # mogelijk. Op een push naar main staat alles aan.
  #
  # Twee gevallen rollen niet uit:
  # - Wijzigingen die de uitgerolde applicatie niet raken (docs, bruno, demo, demo-console).
  # - PR's van een bot: `zad-actions` weigert die zelf (`skip-bot-prs`, default true), dus de
  #   preview komt er toch niet. Zonder deze uitsluiting bouwden en pushten we er wél images voor
  #   die nooit een pod bereiken.
  changes:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    outputs:
      run: ${{ steps.filter.outputs.run }}
      deploy: ${{ steps.filter.outputs.deploy }}
      demo-only: ${{ steps.filter.outputs.demo-only }}
      fuzz: ${{ steps.filter.outputs.fuzz }}
    steps:
      # Eén plek waar de gewijzigde bestanden opgehaald en beoordeeld worden. De aangeroepen
      # workflows stelden dezelfde vraag elk apart; dat kostte per PR vier runner-allocaties
      # voor hetzelfde antwoord. Zij krijgen de uitkomst nu als input en slaan hun eigen
      # detectie over.
      - name: Bepaal wat er moet draaien
        id: filter
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          EVENT: ${{ github.event_name }}
          REPO: ${{ github.repository }}
          PR: ${{ github.event.pull_request.number }}
          # Het type komt van GitHub zelf (enum), niet uit door de indiener bepaalde tekst.
          PR_AUTHOR_TYPE: ${{ github.event.pull_request.user.type }}
        run: |
          set -euo pipefail

          # Alles aan op een push naar main: er is geen PR-bestandenlijst om tegen af te zetten.
          if [ "$EVENT" != "pull_request" ]; then
            {
              echo "run=true"
              echo "deploy=true"
              echo "demo-only=false"
              echo "fuzz=true"
            } >> "$GITHUB_OUTPUT"
            exit 0
          fi

          if [ "$PR_AUTHOR_TYPE" = "Bot" ]; then
            # Luid loggen: een overgeslagen deploy laat de required checks 'skipped' (= succes)
            # rapporteren, dus een onterechte overslag moet in de run-samenvatting zichtbaar zijn.
            # Alleen het uitrollen valt af; de code-checks draaien wél, want een bot-PR
            # (bv. een dependency-bump) hoort getoetst te worden. Welke checks nodig zijn volgt
            # uit dezelfde bestandsanalyse als bij een gewone PR — een action-pin-bump verdient
            # geen fuzz-ronde.
            echo "::notice::PR van een bot — zad-actions deployt die niet, dus bouwen we ook niet."
            BOT_PR=true
          fi
          # Fail-safe: kan de bestandenlijst niet opgehaald worden (API-hik, rate-limit), deploy
          # dan TÓCH i.p.v. stil overslaan — anders zou een overgeslagen deploy onterecht als
          # 'skipped' (= succes) doortellen in de required checks.
          if ! files=$(gh api --paginate "repos/$REPO/pulls/$PR/files" --jq '.[].filename'); then
            echo "::warning::Kon gewijzigde bestanden niet ophalen — alles draait fail-safe."
            {
              echo "run=true"
              echo "deploy=true"
              echo "demo-only=false"
              echo "fuzz=true"
            } >> "$GITHUB_OUTPUT"
            exit 0
          fi

          echo "Gewijzigde bestanden:"
          printf '%s\n' "$files"

          # Alle vier de vragen zijn dezelfde grep over de bestandenlijst. Herestring in plaats
          # van een pipe: `grep -q` sluit de pipe bij de eerste match, en met `pipefail` zou die
          # SIGPIPE als "geen match" doorgaan. `grep` geeft 1 bij geen match en 2 bij een echte
          # fout; alleen 1 mag tot overslaan leiden, want een overgeslagen job rapporteert
          # 'skipped' en telt als succes in de required checks. Een echte fout valt daarom terug
          # op wél draaien.
          grep_fail_safe() {
            local rc=0
            grep -q "$@" <<<"$files" || rc=$?

            case "$rc" in
              0) return 0 ;;
              1) return 1 ;;
              *)
                echo "::warning::Filter kon niet beoordelen (grep rc=$rc) — uitkomst fail-safe op draaien."
                return 0
                ;;
            esac
          }

          # `run`: raakt de PR iets anders dan documentatie? Poort voor de code-checks.
          if grep_fail_safe -vE '(^docs/|\.md$)'; then
            echo "run=true" >> "$GITHUB_OUTPUT"
          else
            echo "Alleen documentatie gewijzigd — code-checks en deploy overgeslagen."
            echo "run=false" >> "$GITHUB_OUTPUT"
          fi

          # `deploy`: kan de wijziging de uitgerolde applicatie raken? Strenger dan `run`, want
          # dit is de enige post die échte clustercapaciteit kost (pods, volumes, ingress) in
          # plaats van alleen runnertijd. Uitgesloten: documentatie, de Bruno-collectie, de
          # demo-stack, demo-console, de fuzz-configuratie en de workflows die uitsluitend
          # toetsen. Zonder dat filter kostte een PR aan bijvoorbeeld de fuzz-configuratie tóch
          # twee jib-builds plus drie previews — uitrollen van een image dat per definitie gelijk
          # is aan main. demo-console zit in geen enkel uitgerold image: het staat niet in de
          # build-matrix hieronder en heeft geen ZAD-component.
          #
          # deploy.yml zelf, .github/actions/ en de zad-actions staan er bewust NIET bij: die
          # bepalen de uitrol, dus juist daar is een preview het bewijs dat de wijziging klopt.
          #
          # Het contract-bootstrap-image komt óók uit demo/, maar wordt alleen op push naar main
          # uitgerold; op een PR bouwt en draait `fsc-harness-overlays.yml` hem. Een uitzondering
          # hier zou dus de hele deploy-keten (twee jib-images, de stubs en drie previews)
          # openzetten voor een wijziging die daar niets mee te maken heeft.
          niet_deploybaar='(^docs/|\.md$|^bruno/|^demo/|^services/demo-console/|^\.clusterfuzzlite/|^\.github/workflows/(test|detekt|codeql|scorecard|architecture|pin-consistency|cflite_pr|cflite_batch|cflite_cron|fsc-harness-overlays|fuzz-base-image)\.yml$)'

          if [ "${BOT_PR:-false}" = "true" ]; then
            echo "deploy=false" >> "$GITHUB_OUTPUT"
          elif grep_fail_safe -vE "$niet_deploybaar"; then
            echo "deploy=true" >> "$GITHUB_OUTPUT"
          else
            echo "Geen wijziging die de images of de uitrol raakt — bouwen en deployen overgeslagen."
            echo "deploy=false" >> "$GITHUB_OUTPUT"
          fi

          # `demo-only`: zie de toelichting in test.yml — demo-console is het enige blad in de
          # module-graaf zonder koppeling, dus dan volstaat een build van die ene module.
          if grep_fail_safe -vE '(^docs/|\.md$|^services/demo-console/|^demo/)'; then
            echo "demo-only=false" >> "$GITHUB_OUTPUT"
          else
            echo "Uitsluitend demo-console geraakt — test-job scoped naar die module."
            echo "demo-only=true" >> "$GITHUB_OUTPUT"
          fi

          # `fuzz`: alleen bronnen die de fuzz-doelen of hun build raken.
          if grep_fail_safe -E '(^libraries/|^services/|^pom\.xml$|^\.clusterfuzzlite/)'; then
            echo "fuzz=true" >> "$GITHUB_OUTPUT"
          else
            echo "Geen fuzz-relevante wijzigingen — fuzzing overgeslagen."
            echo "fuzz=false" >> "$GITHUB_OUTPUT"
          fi

      # DIAGNOSTIEK (gaat er weer uit): de preview-jobs slaan over terwijl `build` op dezelfde
      # uitkomst draait. Dit maakt de gelezen waarden zichtbaar, inclusief eventuele onzichtbare
      # tekens, zodat de `if`-evaluatie niet geraden hoeft te worden.
      - name: Rapporteer de uitkomst
        env:
          RUN: ${{ steps.filter.outputs.run }}
          DEPLOY: ${{ steps.filter.outputs.deploy }}
          DEMO_ONLY: ${{ steps.filter.outputs.demo-only }}
          FUZZ: ${{ steps.filter.outputs.fuzz }}
          EVENT_NAME: ${{ github.event_name }}
          EVENT_ACTION: ${{ github.event.action }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: |
          set -euo pipefail

          {
            echo "### changes-uitkomst"
            echo ''
            echo '```'
            printf 'run=[%s]\ndeploy=[%s]\ndemo-only=[%s]\nfuzz=[%s]\n' "$RUN" "$DEPLOY" "$DEMO_ONLY" "$FUZZ"
            printf 'event_name=[%s]\nevent.action=[%s]\npr.number=[%s]\n' "$EVENT_NAME" "$EVENT_ACTION" "$PR_NUMBER"
            echo '```'
          } >> "$GITHUB_STEP_SUMMARY"

  # Afgeleide waarden op één plek: image-tag + lowercase GHCR-owner (GHCR eist lowercase).
  #
  # De PR-tag draagt de head-sha en is dus UNIEK per commit — dat is de kern van de
  # preview-uitrol, geen cosmetica. De deploy zet de image-referentie in het door Operations
  # Manager gerenderde k8s-manifest, en Argo CD rolt alleen uit bij een verschil in dát
  # manifest. Met een vaste tag `pr-<n>` blijft het manifest bij elke volgende commit
  # byte-identiek: de deploy-check wordt groen terwijl de pod op de image-laag van de eerste
  # build blijft draaien. `imagePullPolicy: Always` vangt dat niet af — dat werkt pas bij een
  # herstart, en die komt niet vanzelf. Op main speelde het niet: `main-<sha7>` wijzigt al
  # per commit.
  #
  # Elke build krijgt zo zijn eigen tag; `cleanup-preview-images` in cleanup-preview.yml ruimt ze
  # bij PR-sluiten allemaal op — op prefix, plus de kale `pr-<n>` uit de tijd vóór de
  # per-commit-tags.
  meta:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    outputs:
      tag: ${{ steps.m.outputs.tag }}
      owner: ${{ steps.m.outputs.owner }}
    steps:
      - id: m
        # Variabele waarden via env i.p.v. inline interpolatie (defense-in-depth injectie).
        env:
          EVENT: ${{ github.event_name }}
          PR: ${{ github.event.number }}
          # Op een pull_request-event is GITHUB_SHA de (efemere) merge-commit; de head-sha is
          # wat in de PR-tijdlijn staat en waar een reviewer op kan matchen.
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          if [ "$EVENT" = "pull_request" ]; then
            tag="pr-${PR}-${HEAD_SHA::7}"

            # Een herdraai bouwt uit refs/pull/<n>/merge, dus met de main van dát moment. Is main
            # inmiddels verder, dan levert dezelfde head-sha andere inhoud op en zou de tag
            # verschuiven — precies de bevriezing die deze tagvorm moet voorkomen. Vanaf poging 2
            # dus een eigen tag. Poging 1 (het normale geval) blijft kaal en leesbaar.
            if [ "$GITHUB_RUN_ATTEMPT" -gt 1 ]; then
              tag="${tag}-r${GITHUB_RUN_ATTEMPT}"
            fi

            echo "tag=$tag" >> "$GITHUB_OUTPUT"
          else
            echo "tag=main-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
          fi
          echo "owner=${GITHUB_REPOSITORY_OWNER,,}" >> "$GITHUB_OUTPUT"

  # Bouw + push de service-images met jib (geen Dockerfile). Niet wanneer `changes` de keten heeft
  # uitgesloten: zo'n revisie deployt toch niet, dus twee volledige Maven/jib-builds + push kosten
  # dan alleen rekentijd, netwerk en een ghcr-versie die nooit een pod bereikt.
  build:
    if: github.event_name == 'push' || needs.changes.outputs.deploy == 'true'
    needs: [meta, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    # Een opvolgende push maakt deze build achterhaald: de preview rolt straks toch de nieuwere
    # commit uit, dus doorbouwen levert alleen runnertijd en een ghcr-versie op die nooit een pod
    # bereikt. Per matrix-service een eigen groep, anders blokkeren de twee parallelle builds van
    # dezelfde run elkaar.
    concurrency:
      group: build-${{ matrix.service }}-${{ github.event.pull_request.number || github.ref }}
      cancel-in-progress: true
    permissions:
      contents: read
      packages: write
    strategy:
      matrix:
        service: [berichtenuitvraag, berichtenmagazijn]
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-java@b6effb05e454b25005698d916606bdc6ffcbf961 # v5.7.0
        with:
          distribution: temurin
          java-version: '21'
          # Cache de Maven-dependency-tree tussen runs; elke PR-push bouwt anders de
          # volledige boom opnieuw (~/.m2 redownload) — onnodig netwerk/energie/CI-tijd.
          cache: maven
      - name: Build + push image (jib)
        # Variabele waarden via env i.p.v. inline interpolatie (defense-in-depth injectie).
        # Het GHCR-token gaat via de MicroProfile-env-vorm QUARKUS_CONTAINER_IMAGE_PASSWORD
        # i.p.v. een -D-flag, zodat het secret niet in de proceslijst (ps) of build-output
        # belandt. Quarkus mapt die env-var op quarkus.container-image.password.
        env:
          SERVICE: ${{ matrix.service }}
          GROUP: ${{ needs.meta.outputs.owner }}
          TAG: ${{ needs.meta.outputs.tag }}
          GHCR_USER: ${{ github.actor }}
          QUARKUS_CONTAINER_IMAGE_PASSWORD: ${{ secrets.GITHUB_TOKEN }}
        run: |
          ./mvnw -B package -DskipTests \
            -pl "services/$SERVICE" -am \
            -Dquarkus.container-image.build=true \
            -Dquarkus.container-image.push=true \
            -Dquarkus.container-image.registry="$REGISTRY" \
            -Dquarkus.container-image.group="$GROUP" \
            -Dquarkus.container-image.tag="$TAG" \
            -Dquarkus.container-image.username="$GHCR_USER"

  # Externe-stubs: één WireMock-image met de profiel- én notificatie-mappings erin gebakken
  # (plain docker, geen jib). Wordt als twee losse componenten gedeployd (profiel + notificatie).
  #
  # BEWUST GEEN paths-filter, hoewel de inhoud zelden wijzigt: de deploy-jobs verwachten een
  # image op de tag van déze run, en die tag draagt per commit de head-sha — precies wat de
  # preview-uitrol laat werken. Overslaan bij een ongewijzigde stub-map zou een
  # tag-hergebruikstrategie vergen die daarmee botst. De prijs is een herbouw per commit; de
  # opbrengst van een filter weegt daar niet tegenop zolang de per-commit-tag de basis is.
  build-externe-stubs:
    if: github.event_name == 'push' || needs.changes.outputs.deploy == 'true'
    needs: [meta, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: build-externe-stubs-${{ github.event.pull_request.number || github.ref }}
      cancel-in-progress: true
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - name: Build + push externe-stubs
        env:
          OWNER: ${{ needs.meta.outputs.owner }}
          TAG: ${{ needs.meta.outputs.tag }}
          GHCR_USER: ${{ github.actor }}
          GHCR_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          echo "$GHCR_TOKEN" | docker login "$REGISTRY" -u "$GHCR_USER" --password-stdin
          IMG="$REGISTRY/$OWNER/fbs-externe-stubs:$TAG"
          docker build -t "$IMG" wiremock/externe-stubs
          docker push "$IMG"

  # De contract-bootstrap draait op ZAD als component náást de manager van zijn eigen peer: de
  # interne manager-API heeft daar geen route en de tenant-baseline-NetworkPolicy laat alleen
  # verkeer binnen hetzelfde deployment toe. Eén image, twee rollen — welke, leest het entrypoint
  # uit FSC_ROL in de component-env.
  build-contract-bootstrap:
    if: github.event_name == 'push' || needs.changes.outputs.run == 'true'
    needs: [meta, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: build-contract-bootstrap-${{ github.event.pull_request.number || github.ref }}
      cancel-in-progress: true
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - name: Build + push contract-bootstrap
        env:
          OWNER: ${{ needs.meta.outputs.owner }}
          TAG: ${{ needs.meta.outputs.tag }}
          GHCR_USER: ${{ github.actor }}
          GHCR_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          echo "$GHCR_TOKEN" | docker login "$REGISTRY" -u "$GHCR_USER" --password-stdin
          IMG="$REGISTRY/$OWNER/fbs-fsc-contract-bootstrap:$TAG"
          # Context is demo/environment/ en niet de contracts-map: de scripts leunen op ../../lib.
          docker build -f demo/environment/federatie/contracts/Dockerfile -t "$IMG" demo/environment
          docker push "$IMG"

  # De vier toetsende workflows draaien als aangeroepen (`workflow_call`) job ín deze workflow,
  # zodat de deploy er met `needs:` aan kan hangen. Vóór #173 draaiden ze zelfstandig en wachtte
  # een `gate`-job er in een poll-lus op: ~461 s per run een runner die niets deed dan `sleep 15`.
  # Hun eigen `pull_request`-trigger staat nu op `branches-ignore: [main]` — het complement van de
  # `branches: [main]` hierboven — zodat een gestapelde PR ze zelfstandig draait en een PR naar
  # main ze precies één keer draait, hier.
  #
  # LET OP: door de aanroep krijgen de check-runs het caller-job-voorvoegsel: `checks-test / test`
  # in plaats van `test`. Branch protection op main pint op die namen; wijzig je hier een job-id,
  # dan moet de required context mee. Een required context die nooit meer verschijnt, blokkeert
  # elke merge.
  #
  # De caller-jobs staan bewust ALTIJD aan; het overslaan gebeurt binnen de aangeroepen
  # workflow. Een overgeslagen caller-job draait die workflow namelijk nooit, waardoor de
  # geneste check-run (`checks-test / test`) niet bestaat — en een required context die niet
  # verschijnt blokkeert de merge voorgoed. Anders dan een overgeslagen job ín deze workflow,
  # die wél als 'skipped' (= succes) doortelt.
  #
  # `!cancelled()` zodat een mislukte detectie de checks niet meesleept: de uitkomst is dan
  # leeg, en op een lege uitkomst zet de aangeroepen workflow zijn eigen detectie weer aan.
  # De uitkomst is daarmee fail-safe — hij wordt opnieuw bepaald, niet aangenomen.
  checks-test:
    needs: changes
    # `!` mag geen plain scalar beginnen (YAML-tagindicator), vandaar `${{ }}`; een blokscalar
    # (`>-`, zoals bij `checks-fuzz`) werkt net zo goed.
    if: ${{ !cancelled() }}
    uses: ./.github/workflows/test.yml
    with:
      wijzigingen-relevant: ${{ needs.changes.outputs.run }}
      demo-only: ${{ needs.changes.outputs.demo-only }}
    # De aangeroepen workflow mag nooit meer rechten hebben dan de caller-job toekent;
    # pull-requests: write is voor de JaCoCo-coverage-comment.
    permissions:
      contents: read
      pull-requests: write

  checks-detekt:
    needs: changes
    if: ${{ !cancelled() }}
    uses: ./.github/workflows/detekt.yml
    with:
      wijzigingen-relevant: ${{ needs.changes.outputs.run }}
    permissions:
      contents: read
      pull-requests: read
      security-events: write

  checks-pins:
    uses: ./.github/workflows/pin-consistency.yml
    # pull-requests: write voor de melding over een verouderde fuzz-basis-image-pin; een
    # aangeroepen workflow kan nooit meer krijgen dan de caller-job toekent.
    permissions:
      contents: read
      pull-requests: write

  # ClusterFuzzLite fuzzt alleen PR's: op een push naar main is er geen basis om code-change-fuzzing
  # tegen af te zetten. Deze job wordt daar dus overgeslagen, en de gate telt dat als OK.
  checks-fuzz:
    needs: changes
    if: >-
      !cancelled()
      && github.event_name == 'pull_request'
    uses: ./.github/workflows/cflite_pr.yml
    with:
      fuzz-relevant: ${{ needs.changes.outputs.fuzz }}
    permissions: read-all

  # Kwaliteitspoort vóór élke ZAD-deploy: geen cluster-capaciteit (en geen review-ruis van een
  # "geslaagde" preview) verspillen aan een revisie die de tests/kwaliteitsgates niet haalt.
  #
  # De poort zelf toetst niets — dat doen de checks-jobs hierboven. Hij aggregeert alleen hun
  # resultaat op één plek, zodat de "overgeslagen telt als OK"-regel één keer bestaat in plaats van
  # als `always() && ...`-formule op elk van de zes deploy-jobs, met zes kansen op drift.
  #
  # CodeQL en architecture bewust NIET in de set: CodeQL mag traag of tijdelijk rood zijn (bv.
  # extractor-lag op een nieuwe Kotlin-versie) zonder de preview te blokkeren, en architecture
  # triggert alleen op docs/architecture-wijzigingen.
  gate:
    # `!cancelled()` i.p.v. de impliciete success(): een overgeslagen `checks-fuzz` (push naar main)
    # zou deze job anders meeslepen in 'skipped' en de deploy stilzwijgend blokkeren. Bij een
    # geannuleerde run hoeft de poort juist niet meer te oordelen.
    # Niet wanneer `changes` de keten heeft uitgesloten (docs-only of bot-PR) — dan valt er niets
    # te bewaken.
    if: >-
      !cancelled()
      && (github.event_name == 'push' || needs.changes.outputs.deploy == 'true')
    needs: [changes, checks-test, checks-detekt, checks-pins, checks-fuzz]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Beoordeel de verplichte checks
        env:
          # Naam=resultaat per verplichte check. De namen zijn die van de check-runs zoals ze in
          # de PR verschijnen, niet de job-id's — dit is wat een lezer van het logboek zoekt.
          # De fuzz-check hoort er alleen bij op een pull_request; op een push naar main is hij
          # per definitie afwezig en zou hij elke run een 'overgeslagen'-waarschuwing opleveren.
          RESULTATEN: |
            test=${{ needs.checks-test.result }}
            detekt-gate=${{ needs.checks-detekt.result }}
            infra-image-pins=${{ needs.checks-pins.result }}
            ${{ github.event_name == 'pull_request' && format('PR={0}', needs.checks-fuzz.result) || '' }}
        run: |
          set -euo pipefail
          geblokkeerd=0

          while IFS='=' read -r naam resultaat; do
            [ -n "$naam" ] || continue

            case "$resultaat" in
              success)
                echo "Verplichte check '$naam' geslaagd."
                ;;
              skipped)
                # Legitiem wanneer de check zichzelf heeft overgeslagen via zijn eigen
                # relevantie-filter: de fuzz-`PR` bij een niet-fuzz-relevante wijziging of op een
                # push naar main, of een docs-only wijziging. (Een docs-only PR bereikt deze poort
                # niet eens — dan is de deploy zelf al overgeslagen.) Luid loggen zodat een
                # onbedoelde overslag auditbaar is i.p.v. stil als 'groen' doortelt.
                echo "::warning::Verplichte check '$naam' is overgeslagen — als OK geteld (check overgeslagen via eigen relevantie-filter)."
                ;;
              *)
                echo "::error::Verplichte check '$naam' eindigde als '$resultaat' — deploy geblokkeerd."
                geblokkeerd=1
                ;;
            esac
          done <<< "$RESULTATEN"

          if [ "$geblokkeerd" -ne 0 ]; then
            exit 1
          fi

          echo "Alle verplichte checks groen — deploy vrijgegeven."

  # PR-preview: één job PER project zodat ze PARALLEL draaien — bij een fout falen alle drie
  # projecten tegelijk (geen fail-fast tussen losse jobs), dus alle fouten in één run
  # zichtbaar i.p.v. één-voor-één. Config geërfd van `test`. wait-for-ready staat UIT: de
  # zad-action doet geen k8s-readinessprobe maar curlt vanaf de runner ELKE component-URL op
  # één health-endpoint (input `health-endpoint`, default '/'). De services bieden nu wél
  # /q/health/ready (smallrye-health), maar deze deployments mengen niet-HTTP-componenten
  # (redis) die op dat pad nooit 2xx geven → de wachtlus zou timen out. Aanzetten
  # kan pas met een per-component health-endpoint of een Quarkus-only deployment; tot dan 'false'.
  # DIAGNOSTIEK (gaat er weer uit): twee jobs met exact de `if` en `needs` van de preview-jobs,
  # die alleen in de `environment:`-sleutel verschillen. Draait de eerste en slaat de tweede over,
  # dan zit de oorzaak in de environment-sleutel (bv. een deployment-branch-policy) en niet in de
  # conditie. Slaan beide over terwijl `build` op dezelfde uitkomst draaide, dan liegt de
  # uitkomst — en dan staat in de run-samenvatting welke waarde de jobs lazen.
  # DIAGNOSTIEK (gaat er weer uit): dumpt de volledige needs-context vanuit een job met exact de
  # vijf `needs` van de preview-jobs. Daarmee is zichtbaar wat die jobs lezen — resultaat én
  # outputs per need — in plaats van het te moeten afleiden uit wie wel en niet draaide.
  # DIAGNOSTIEK (gaat er weer uit): vier keer dezelfde conditie, alleen de `needs`-verzameling
  # verschilt. `build` (matrix) en `gate` zijn de kandidaten: draait P3 wel en P2 niet, dan
  # vergiftigt de matrix-job de evaluatie; draait P4 wel en P2 niet, dan doet `gate` dat.
  diagnose-p1-alleen-changes:
    if: needs.changes.outputs.deploy == 'true'
    needs: [changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo "P1 (needs=[changes]) gedraaid"

  diagnose-p2-vijf-needs:
    if: needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo "P2 (vijf needs) gedraaid"

  diagnose-p3-zonder-matrixjob:
    if: needs.changes.outputs.deploy == 'true'
    needs: [meta, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo "P3 (zonder build-matrix) gedraaid"

  diagnose-p4-zonder-gate:
    if: needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo "P4 (zonder gate) gedraaid"

  diagnose-needs-context:
    if: always()
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - env:
          NEEDS: ${{ toJSON(needs) }}
          EVENT_NAME: ${{ github.event_name }}
          DEPLOY_DIRECT: ${{ needs.changes.outputs.deploy }}
        run: |
          set -euo pipefail

          echo "event_name=[$EVENT_NAME]"
          echo "needs.changes.outputs.deploy=[$DEPLOY_DIRECT]"
          echo "volledige needs-context:"
          printf '%s\n' "$NEEDS"

  diagnose-if-zonder-environment:
    if: github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - env:
          DEPLOY: ${{ needs.changes.outputs.deploy }}
          EVENT_NAME: ${{ github.event_name }}
        run: |
          echo "zonder environment gedraaid; deploy=[$DEPLOY] event_name=[$EVENT_NAME]" | tee -a "$GITHUB_STEP_SUMMARY"

  diagnose-if-met-environment:
    if: github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 5
    environment:
      name: pr-${{ github.event.pull_request.number }}
    steps:
      - env:
          DEPLOY: ${{ needs.changes.outputs.deploy }}
          EVENT_NAME: ${{ github.event_name }}
        run: |
          echo "met environment gedraaid; deploy=[$DEPLOY] event_name=[$EVENT_NAME]" | tee -a "$GITHUB_STEP_SUMMARY"

  deploy-preview-uitvraag:
    if: github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    # Eén ZAD-taak tegelijk op deze deployment; een nieuwe push wacht op de lopende i.p.v. die af
    # te breken — een halverwege afgebroken ZAD-deploy laat de deployment in een inconsistente
    # staat achter. De cleanup-job in cleanup-preview.yml draagt voor hetzelfde project + dezelfde
    # PR dezelfde groepsnaam (concurrency-groepen zijn repo-breed), zodat een PR-close een lopende
    # deploy niet onder handen wegtrekt.
    concurrency:
      group: zad-uitvraag-pr-${{ github.event.pull_request.number }}
      cancel-in-progress: false
    permissions:
      contents: read
      pull-requests: write
    # De GitHub-environment (één per PR) hangt aan déze job; de preview-URL komt uit de
    # uitvraag-deploy (de frontend). De andere projecten dragen geen environment.
    environment:
      name: pr-${{ github.event.pull_request.number }}
      url: ${{ steps.deploy.outputs.url }}
    steps:
      - name: Deploy uitvraag-project
        id: deploy
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_UITVRAAG }}
          project-id: ${{ env.PROJECT_UITVRAAG }}
          deployment-name: pr-${{ github.event.pull_request.number }}
          clone-from: test
          comment-on-pr: 'true'
          comment-header: ${{ env.COMMENT_HEADER }}
          wait-for-ready: 'false'
          task-timeout: ${{ env.PREVIEW_TASK_TIMEOUT }}
          components: |
            [
              {"name": "redis", "image": "${{ env.REDIS_IMAGE }}"},
              {"name": "uitvraag", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenuitvraag:${{ needs.meta.outputs.tag }}"}
            ]

  deploy-preview-externe-stubs:
    if: github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    concurrency:
      group: zad-externe-stubs-pr-${{ github.event.pull_request.number }}
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      # profiel + notificatie = zelfde image, losse componenten (eigen subdomein per stub).
      - name: Deploy externe-stubs-project
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_PROFIEL }}
          project-id: ${{ env.PROJECT_EXTERNE_STUBS }}
          deployment-name: pr-${{ github.event.pull_request.number }}
          clone-from: test
          wait-for-ready: 'false'
          task-timeout: ${{ env.PREVIEW_TASK_TIMEOUT }}
          components: |
            [
              {"name": "profiel", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-externe-stubs:${{ needs.meta.outputs.tag }}"},
              {"name": "notificatie", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-externe-stubs:${{ needs.meta.outputs.tag }}"}
            ]

  deploy-preview-magazijnen:
    if: github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'
    needs: [meta, build, build-externe-stubs, gate, changes]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    concurrency:
      group: zad-magazijnen-pr-${{ github.event.pull_request.number }}
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      - name: Deploy magazijnen-project
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_MAGAZIJNEN }}
          project-id: ${{ env.PROJECT_MAGAZIJNEN }}
          deployment-name: pr-${{ github.event.pull_request.number }}
          clone-from: test
          wait-for-ready: 'false'
          task-timeout: ${{ env.PREVIEW_TASK_TIMEOUT }}
          components: |
            [
              {"name": "magazijna", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenmagazijn:${{ needs.meta.outputs.tag }}"},
              {"name": "magazijnb", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenmagazijn:${{ needs.meta.outputs.tag }}"}
            ]

  # Push naar main → per project de `test`-deployment (de baseline waarvan previews klonen;
  # env/secrets configureer je daar in Operations Manager). Per project een eigen parallelle job.
  deploy-test-uitvraag:
    # Expliciete statusfunctie i.p.v. de impliciete success(): die kijkt niet alleen naar de vier
    # directe needs hieronder, maar transitief door naar hún needs — en `checks-fuzz` (PR-only) is
    # bij een push naar main altijd 'skipped', wat de impliciete success() over de hele keten laat
    # falen. `gate` ontsnapt daar zelf al aan met `!cancelled()`, maar dat beschermt alleen `gate`
    # zelf, niet de jobs die van `gate` afhangen. Vandaar hier dezelfde `!cancelled()`-vorm, plus
    # expliciete per-need result-checks zodat een échte build-/gate-fout deze job wél overslaat.
    if: >-
      !cancelled()
      && needs.meta.result == 'success'
      && needs.build.result == 'success'
      && needs.build-externe-stubs.result == 'success'
      && needs.build-contract-bootstrap.result == 'success'
      && needs.gate.result == 'success'
      && github.event_name == 'push'
      && github.ref == 'refs/heads/main'
    needs: [meta, build, build-externe-stubs, build-contract-bootstrap, gate]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    # Eén ZAD-taak tegelijk op de `test`-deployment van dit project; twee snel opeenvolgende merges
    # naar main mogen elkaars deploy niet halverwege afbreken.
    concurrency:
      group: zad-uitvraag-test
      cancel-in-progress: false
    permissions:
      contents: read
    environment:
      name: test
    steps:
      - name: Deploy uitvraag-project (test)
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_UITVRAAG }}
          project-id: ${{ env.PROJECT_UITVRAAG }}
          deployment-name: test
          components: |
            [
              {"name": "redis", "image": "${{ env.REDIS_IMAGE }}"},
              {"name": "uitvraag", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenuitvraag:${{ needs.meta.outputs.tag }}"}
            ]

      # De FSC-peer draait in een EIGEN deployment `fsc-logius` binnen hetzelfde project, niet in
      # `test`. Previews klonen met `clone-from: test`; een gekloonde peer zou zich met dezelfde
      # federatie-OIN opnieuw aanmelden bij de gedeelde directory (en zonder de UI-only
      # cert-attachments direct crashloopen). Wat niet in `test` staat, kan niet meegekloond worden.
      # Deze stap doet alleen tag-updates; de eenmalige creatie (env/ports) loopt via
      # demo/environment/logius/deploy/zad/upsert-peer.sh.
      - name: Deploy uitvraag-project (fsc-logius — FSC-peer)
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_UITVRAAG }}
          project-id: ${{ env.PROJECT_UITVRAAG }}
          deployment-name: fsc-logius
          components: |
            [
              {"name": "logius-fscpg", "image": "docker.io/library/postgres:17"},
              {"name": "logius-fscmgr", "image": "ghcr.io/minbzk/moza-fsc-testnet-manager-migrate:v2.5.2"},
              {"name": "logius-fscctl", "image": "ghcr.io/minbzk/moza-fsc-testnet-controller-migrate:v2.5.2"},
              {"name": "logius-fscoutway", "image": "docker.io/federatedserviceconnectivity/outway:v2.5.2"},
              {"name": "logius-fscinway", "image": "docker.io/federatedserviceconnectivity/inway:v2.5.2"},
              {"name": "logius-fsctxlog", "image": "ghcr.io/minbzk/moza-fsc-testnet-txlog-migrate:v2.5.2"},
              {"name": "logius-fscbootstrap", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-fsc-contract-bootstrap:${{ needs.meta.outputs.tag }}"}
            ]

  deploy-test-externe-stubs:
    # Zelfde reden als deploy-test-uitvraag hierboven: impliciete success() over de needs-keten
    # wordt vergiftigd door het op push altijd-geskipte `checks-fuzz`, ook al is `gate` zelf groen.
    if: >-
      !cancelled()
      && needs.meta.result == 'success'
      && needs.build.result == 'success'
      && needs.build-externe-stubs.result == 'success'
      && needs.gate.result == 'success'
      && github.event_name == 'push'
      && github.ref == 'refs/heads/main'
    needs: [meta, build, build-externe-stubs, gate]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    concurrency:
      group: zad-externe-stubs-test
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      - name: Deploy externe-stubs-project (test)
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_PROFIEL }}
          project-id: ${{ env.PROJECT_EXTERNE_STUBS }}
          deployment-name: test
          components: |
            [
              {"name": "profiel", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-externe-stubs:${{ needs.meta.outputs.tag }}"},
              {"name": "notificatie", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-externe-stubs:${{ needs.meta.outputs.tag }}"}
            ]

  deploy-test-magazijnen:
    # Zelfde reden als deploy-test-uitvraag hierboven: impliciete success() over de needs-keten
    # wordt vergiftigd door het op push altijd-geskipte `checks-fuzz`, ook al is `gate` zelf groen.
    if: >-
      !cancelled()
      && needs.meta.result == 'success'
      && needs.build.result == 'success'
      && needs.build-externe-stubs.result == 'success'
      && needs.build-contract-bootstrap.result == 'success'
      && needs.gate.result == 'success'
      && github.event_name == 'push'
      && github.ref == 'refs/heads/main'
    needs: [meta, build, build-externe-stubs, build-contract-bootstrap, gate]
    runs-on: ubuntu-latest
    timeout-minutes: 20
    # Dekt ook de tweede stap (deployment `fsc-magazijna`) — die hoort bij hetzelfde project.
    concurrency:
      group: zad-magazijnen-test
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      - name: Deploy magazijnen-project (test)
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_MAGAZIJNEN }}
          project-id: ${{ env.PROJECT_MAGAZIJNEN }}
          deployment-name: test
          components: |
            [
              {"name": "magazijna", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenmagazijn:${{ needs.meta.outputs.tag }}"},
              {"name": "magazijnb", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-berichtenmagazijn:${{ needs.meta.outputs.tag }}"}
            ]

      # De FSC-peer draait in een EIGEN deployment `fsc-magazijna` binnen hetzelfde project, niet in
      # `test`. Previews klonen met `clone-from: test`; een gekloonde peer zou zich met dezelfde
      # federatie-OIN opnieuw aanmelden bij de gedeelde directory (en zonder de UI-only
      # cert-attachments direct crashloopen). Wat niet in `test` staat, kan niet meegekloond worden.
      # Deze stap doet alleen tag-updates; de eenmalige creatie (env/ports) loopt via
      # demo/environment/magazijn-a/deploy/zad/upsert-peer.sh.
      - name: Deploy magazijnen-project (fsc-magazijna — FSC-peer)
        uses: RijksICTGilde/zad-actions/deploy@b844c76eba3502b40a19be868cdf0586e322f4b8 # v4
        with:
          api-key: ${{ secrets.ZAD_API_KEY_MAGAZIJNEN }}
          project-id: ${{ env.PROJECT_MAGAZIJNEN }}
          deployment-name: fsc-magazijna
          components: |
            [
              {"name": "magazijna-fscpg", "image": "docker.io/library/postgres:17"},
              {"name": "magazijna-fscmgr", "image": "ghcr.io/minbzk/moza-fsc-testnet-manager-migrate:v2.5.2"},
              {"name": "magazijna-fscctl", "image": "ghcr.io/minbzk/moza-fsc-testnet-controller-migrate:v2.5.2"},
              {"name": "magazijna-fscinway", "image": "docker.io/federatedserviceconnectivity/inway:v2.5.2"},
              {"name": "magazijna-fsctxlog", "image": "ghcr.io/minbzk/moza-fsc-testnet-txlog-migrate:v2.5.2"},
              {"name": "magazijna-fscbootstrap", "image": "${{ env.REGISTRY }}/${{ needs.meta.outputs.owner }}/fbs-fsc-contract-bootstrap:${{ needs.meta.outputs.tag }}"}
            ]