not
0a97fa4bf7
## What & why S-18b, second of the S-18 (#19) split (after S-18a #139/#142). Stands up the upstream Maykin **Objecten API** in the compose stack and wires it to the Objecttypen API — the authoritative object store the ACL will write register records to (S-19). Closes #140 ### What - **Compose** (main + local): `objecten-db` (**PostGIS** — objects carry geometry), `objecten-redis`, `objecten-init` (RUN_SETUP_CONFIG → migrate + provision token + register the Objecttypen service), `objecten` web (health on `/admin/`, host `:8021`). Verbatim upstream image `maykinmedia/objects-api` pinned to `3.4.0` (nearest release to objecttypes-api `3.4.2`; the two speak over the stable Objecttypes API v2). - **Seed**: `infra/seed-config.sh objecten` streams `infra/objecten/setup_configuration/data.yaml` into the external `rr-objecten-config` volume — same pattern as S-18a. The data.yaml (1) registers **Objecttypen** as a trusted `zgw_consumers` service (`api_type: orc`, api-key auth with the S-18a dev token) so an object can reference its objecttype, and (2) provisions a dev **static API token** so peers (the ACL, S-19) can write objects. - **Wiring**: added to `WAIT_SVCS`, `CFG_VOLS`, the `SEED` invocations, `seed-config.sh`, and the CI log-dump. `objecten-init` waits on `objecttypen` being healthy so the service registration is meaningful end to end. - **Smoke**: `verify-objecten` (`infra/run-objecten-check.sh` + `objecten-check.py`) asserts unauth → 401, token → 200 on `/api/v2/objects`; added as a verify-stack step + a row in the #136 check-summary table. ## Verified locally (end to end, real compose) Seeded + brought up the real `infra/docker-compose.yml` objecten chain (pulls in objecttypen via `depends_on`): `objecten-init` ran setup_configuration — `token_configuration_success` **and** "Successfully executed step: Configuration to connect with external services" — the web reached healthy, and `make verify-objecten` → **"OK — no-auth 401, token 200"**. Confirmed the registered service via the Objecten django shell: ``` objecttypen | orc | http://objecttypen:8000/api/v2/ | api_key ``` YAML (both compose files + ci.yaml) + shell + python all validated; `docker compose config` clean on both files. ## Definition of Done - [x] Failing smoke committed first (`test(infra): …`, "no running objecten container"); implementation makes it pass. - [x] Conventional Commits referencing #140. - [ ] CI green (verify-stack objecten step). - [x] `docker compose up` reaches health (objecten healthy on first poll locally). - [x] Demo note in `docs/demo-script.md`. - [x] Closed by the merging PR (`closes #140`). No new ADR: follows the established verbatim-image + seed-config CG-module pattern (S-18a/ADR-0023-era). 🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #143
58 lines
2.9 KiB
Bash
Executable File
58 lines
2.9 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, nrc, kc, fl, objecttypen, objecten }
|
|
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|objecttypen|objecten> ..." >&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/." ;;
|
|
objecttypen) populate rr-objecttypen-config "$here/objecttypen/setup_configuration/." ;;
|
|
objecten) populate rr-objecten-config "$here/objecten/setup_configuration/." ;;
|
|
fl) d="$(mktemp -d)"; stage_flowable_workflows "$d"; populate rr-fl-bpmn "$d/." ;;
|
|
*) echo "unknown seed key: $key" >&2; exit 2 ;;
|
|
esac
|
|
done
|