Files
register-referentie/infra/seed-config.sh
T
notandClaude Opus 4.8 dc4822e53d
CI / lint (pull_request) Successful in 1m18s
CI / build (pull_request) Successful in 1m3s
CI / unit (pull_request) Successful in 1m9s
CI / frontend (pull_request) Successful in 2m37s
CI / mutation (pull_request) Successful in 5m27s
CI / verify-stack (pull_request) Successful in 7m39s
fix(infra): deploy diploma-eligibility DMN via dmn-api, not a process .bar (refs #14)
flowable-rest does not cascade a .dmn bundled inside a process .bar into the
DMN engine: the resource is stored but no decision is created, so the DMN
service task fails at runtime with FlowableObjectNotFoundException. Deploy the
DMN to the DMN engine via /dmn-api/dmn-repository/deployments and the BPMN to
the process engine separately; the service task resolves the decision across
deployments by key (verified live: Buitenlands->CBGV_ADVIES, Binnenlands->DIRECT).

Also move the DMN's doc comment inside <definitions>: Flowable's DMN XML
converter rejects a comment between the <?xml?> declaration and the root element
(XMLStreamReader not in START_DOCUMENT/START_ELEMENT state), unlike its BPMN one.

seed-config.sh now seeds both raw workflow files instead of building a .bar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-20 09:05:41 +02:00

56 lines
2.7 KiB
Bash
Executable File

#!/usr/bin/env bash
#
# Populate the external named *config* volumes that the upstream services mount,
# by `docker cp`-ing files into a throwaway helper container that mounts each one.
#
# Why: the compose stack uses the upstream images verbatim (no build). On Gitea's
# containerized runner, `docker compose` starts the stack as SIBLING containers
# via the host daemon, so a workspace bind mount resolves to a path the daemon
# can't see and is mounted empty. `docker cp` instead streams bytes over the
# Docker API, so the files reach the volume regardless of where the daemon runs.
# We use plain docker primitives (volume create / run / cp / rm) rather than
# `docker compose create`, because podman-compose (local dev) lacks that
# subcommand. Fixed-name `external` volumes keep the names deterministic across
# both runtimes. See docs/runbooks/gitea-actions-gotchas.md.
#
# Usage: seed-config.sh <key> [<key> ...] where key ∈ { oz, kc, fl }
set -euo pipefail
here="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
HELPER="${SEED_HELPER_IMAGE:-docker.io/library/busybox:stable}"
populate() { # volume source(file or dir/.)
local vol="$1" src="$2" cid
docker volume rm -f "$vol" >/dev/null 2>&1 || true
docker volume create "$vol" >/dev/null
# A *created* (never started) helper is enough: the volume is attached at create
# time, `docker cp` writes through to it, and `docker rm` is instant (nothing to
# stop). `docker create` is a container subcommand both docker and podman have —
# unlike `docker compose create`, which podman-compose lacks.
cid="$(docker create -v "$vol:/dest" "$HELPER" true)"
docker cp "$src" "$cid:/dest/"
docker rm "$cid" >/dev/null
echo " seeded $vol"
}
[ "$#" -gt 0 ] || { echo "usage: seed-config.sh <oz|nrc|kc|fl> ..." >&2; exit 2; }
# The registratie process (BPMN) and its diploma-eligibility DMN are deployed as SEPARATE Flowable
# deployments — the process engine and the DMN engine each own theirs (S-13, ADR-0016). flowable-rest
# does not cascade a .dmn bundled in a process .bar into the DMN engine, so we seed both raw files and
# let flowable-init deploy each via its own REST app. We stage them in a temp dir and copy its contents.
stage_flowable_workflows() {
local dir="$1"
cp "$here/../workflows/registratie.bpmn" "$here/../workflows/diploma-eligibility.dmn" "$dir/"
}
for key in "$@"; do
case "$key" in
oz) populate rr-oz-config "$here/openzaak/setup_configuration/." ;;
nrc) populate rr-nrc-config "$here/opennotificaties/setup_configuration/." ;;
kc) populate rr-kc-realms "$here/keycloak/realms/." ;;
fl) d="$(mktemp -d)"; stage_flowable_workflows "$d"; populate rr-fl-bpmn "$d/." ;;
*) echo "unknown seed key: $key" >&2; exit 2 ;;
esac
done