Previews opruimen als een PR sluit, en weer uitrollen voor elke PR (#… #606

Workflow file for this run

	# 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 legs van de opruim-matrix in
	# cleanup-preview.yml zitten in dezelfde groepen; de opruim-job voor de GitHub-kant deelt de
	# uitvraag-groep en draait daarom ná die matrix, zodat die twee teardowns nooit samen in de
	# wachtrij van één groep staan (GitHub annuleert dan de eerst-wachtende).

	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

	# 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`.
	# De eerste drie (test, detekt, pin-consistency) dragen daarnaast hun eigen `pull_request`-trigger
	# 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.
	# `cflite_pr.yml` heeft géén eigen trigger en draait uitsluitend als aangeroepen workflow.
	#
	# 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 een geaccepteerde status geven → de wachtlus zou timen out. Aanzetten
	# kan pas met een per-component health-endpoint of een Quarkus-only deployment; tot dan 'false'.
	deploy-preview-uitvraag:
	# Expliciete statusfunctie i.p.v. de impliciete success(), om dezelfde reden als bij
	# deploy-test-*: die kijkt transitief door naar de needs van `gate`, en `checks-fuzz` is
	# 'skipped' zodra de PR niets fuzz-relevants raakt. Die overgeslagen grootouder in de
	# needs-keten sloeg de previews over terwijl `gate` zelf groen was — een preview die stil
	# uitblijft terwijl de required check als 'skipped' meetelt.
	#
	# GitHub documenteert de impliciete vorm als "alle directe needs geslaagd"; dat de evaluatie
	# transitief doorwerkt is hier waargenomen, niet gedocumenteerd. Vereenvoudig dit dus niet
	# terug naar `github.event_name == 'pull_request' && needs.changes.outputs.deploy == 'true'`,
	# ook al lijkt dat gelijkwaardig.
	if: >-
	!cancelled()
	&& needs.meta.result == 'success'
	&& needs.build.result == 'success'
	&& needs.build-externe-stubs.result == 'success'
	&& needs.gate.result == 'success'
	&& 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:
	# Zelfde reden als bij deploy-preview-uitvraag: de impliciete success() struikelt over
	# het transitief overgeslagen `checks-fuzz` onder `gate`.
	if: >-
	!cancelled()
	&& needs.meta.result == 'success'
	&& needs.build.result == 'success'
	&& needs.build-externe-stubs.result == 'success'
	&& needs.gate.result == 'success'
	&& 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:
	# Zelfde reden als bij deploy-preview-uitvraag: de impliciete success() struikelt over
	# het transitief overgeslagen `checks-fuzz` onder `gate`.
	if: >-
	!cancelled()
	&& needs.meta.result == 'success'
	&& needs.build.result == 'success'
	&& needs.build-externe-stubs.result == 'success'
	&& needs.gate.result == 'success'
	&& 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 }}"}
	]

Navigation Menu

Previews opruimen als een PR sluit, en weer uitrollen voor elke PR (#… #606

Workflow file

Previews opruimen als een PR sluit, en weer uitrollen voor elke PR (#… #606

Uh oh!

Workflow file for this run