feat(zgw): docker OpenZaak integration-test harness (WP-54)

Opt-in docker-compose (postgres+redis+OpenZaak, no celery/nginx) + bootstrap-catalogus.sh seed a real OpenZaak instance; OpenZaakIntegrationTests (Category=Integration, excluded from default dotnet test/CI) proves the ZGW seam against it for the first time. That live run caught a real bug: ZgwHttpClient never sent Content-Crs/Accept-Crs headers, so every write would 412 against a spec-compliant OpenZaak — fixed alongside the harness. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 09:08:35 +02:00
parent 73172510ea
commit 5cb3e1a9f0
12 changed files with 471 additions and 15 deletions
@@ -0,0 +1,72 @@
+# WP-54 — a real OpenZaak to develop/test the ZGW seam against, kept OUT of the root
+# docker-compose.yml on purpose (see backend/openzaak/README.md): OpenZaak is a full Django
+# stack (postgres + redis), heavy compared to this repo's own FE+BFF, and nobody who isn't
+# touching the ZGW slice should have to pull/boot it.
+#
+# ponytail: trimmed vs. open-zaak's own published compose — no celery/celery-beat/celery-flower
+# (async notification delivery, never asserted by the integration test) and no nginx (the test
+# hits web's port directly). Add them back only if a later WP needs an actual notification
+# round-trip against this harness (NRC delivery is already covered by fixture tests, WP-52).
+services:
+  db:
+    image: postgis/postgis:17-3.5
+    environment:
+      - POSTGRES_HOST_AUTH_METHOD=trust
+      - POSTGRES_DB=openzaak
+      - POSTGRES_USER=openzaak
+    healthcheck:
+      test: ['CMD-SHELL', 'pg_isready -U openzaak']
+      interval: 5s
+      timeout: 5s
+      retries: 10
+
+  redis:
+    image: redis:8
+    healthcheck:
+      test: ['CMD', 'redis-cli', 'ping']
+      interval: 5s
+      timeout: 5s
+      retries: 10
+
+  # One-shot: migrate the schema, then apply setup_configuration/data.yaml (JWTSecret +
+  # Applicatie for the bootstrap script below) — the documented, scripted alternative to
+  # clicking through the Django admin (see openzaak_config_cli in upstream docs).
+  web-init:
+    image: openzaak/open-zaak:1.29.1
+    environment: &app-env
+      DJANGO_SETTINGS_MODULE: openzaak.conf.docker
+      SECRET_KEY: wp-54-local-harness-not-for-prod
+      DB_HOST: db
+      DB_NAME: openzaak
+      DB_USER: openzaak
+      IS_HTTPS: 'no'
+      SITE_DOMAIN: localhost:8000
+      ALLOWED_HOSTS: localhost,127.0.0.1,web
+      CACHE_DEFAULT: redis:6379/0
+      CACHE_AXES: redis:6379/0
+      DISABLE_2FA: 'true'
+      CELERY_BROKER_URL: redis://redis:6379/0
+      CELERY_RESULT_BACKEND: redis://redis:6379/0
+      RUN_SETUP_CONFIG: 'true'
+      # No celery worker in this trimmed harness (see the top-of-file note) to actually
+      # deliver a notification — without this, OpenZaak 500s (and rolls back!) every create
+      # on a notified resource (zaaktype, zaak, ...) because NotificationsConfig has no
+      # client configured (see notifications_api_common.viewsets.NotificationMixin.notify).
+      NOTIFICATIONS_DISABLED: 'true'
+    command: /setup_configuration.sh
+    volumes:
+      - ./setup_configuration:/app/setup_configuration:ro
+    depends_on:
+      db:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+
+  web:
+    image: openzaak/open-zaak:1.29.1
+    environment: *app-env
+    ports:
+      - '8000:8000'
+    depends_on:
+      web-init:
+        condition: service_completed_successfully