not 6cfcc4cf83
CI / k8s (push) Successful in 6s
CI / unit (push) Canceled after 0s
CI / frontend (push) Canceled after 0s
CI / mutation (push) Canceled after 0s
CI / verify-stack (push) Canceled after 0s
CI / build (push) Canceled after 9s
CI / lint (push) Canceled after 24s
Deploy to Talos / deploy (push) Successful in 5m1s
ci(deploy): deploy the stack to Talos on merge to main (closes #175) (#176)
## What & why

The chart has been deployable by hand since #25 and linted in CI since #168. This makes a
merged PR actually ship it to the Talos VM on the lab server.

`.gitea/workflows/deploy.yaml` runs on a push to `main` (a squash-merged PR) and on manual
dispatch:

1. **Tunnel** — neither the Kubernetes API nor the in-cluster registry is publicly reachable,
   so 6443, 30500 and 30141 are forwarded over the same SSH hop into the Fedora host that the
   Gitea-runner pipeline uses (`ssh -p 6667 user@labs.respellion.tech`).
2. **Images** — `make k8s-images K8S_REGISTRY=localhost:30500`, pushed *through* the tunnel.
3. **Deploy** — `make k8s-reseed TALOS_HOST=… K8S_REGISTRY=<vm-ip>:30500`, pulled by the node
   from its own NodePort.
4. **Roll** — `rollout restart` + `rollout status` on the nine repo deployments.
5. **Smoke** — `GET /openbaar/register` through the openbaar portal.

Three decisions worth the review:

- **One registry, two names.** The push target (`localhost:30500`, the tunnel) and the pull
  target (`<vm-ip>:30500`, the node's own NodePort) address the same store. The pull name has
  to be the one in the node's registry-mirror patch, which is what makes plain HTTP acceptable.
- **`k8s-reseed`, not `k8s-up`.** A Job's pod template is immutable, so a chart change to any
  bootstrap Job would otherwise fail the upgrade with `cannot patch … with kind Job`. The Jobs
  are idempotent by design, so re-running them every deploy is safe and removes that whole
  class of failure. Cost: a few minutes per deploy, and `seed-zaaktype` needs egress from the VM.
- **No re-run of the checks.** PR CI is the merge gate, so `main` is green by construction.
  Deploys **queue** (`cancel-in-progress: false`) — a `helm upgrade` killed half-way leaves the
  release in `pending-upgrade` and has to be unwedged by hand.

Settings on the repo (already added): secrets `TALOS_SSH_KEY` and `TALOS_KUBECONFIG`
(base64, and its `server:` must be `https://127.0.0.1:6443` — Talos puts `127.0.0.1` in the
apiserver cert SANs, so TLS still verifies through the tunnel); variables `TALOS_VM_IP`
(default `192.168.122.173`) and `TALOS_HOST` (default `localhost`).

Closes #175

## Definition of Done

- [x] Linked Gitea issue (above).
- [ ] Failing test committed before the implementation — **n/a**: this is a deployment
      workflow with no unit under test. Its check is the run itself: `rollout status` and the
      public-register smoke both have to pass or the job fails. `make k8s-lint` / `make k8s-drift`
      (#168) already gate the chart it deploys.
- [x] Implementation — one workflow file, no production code touched.
- [x] Conventional Commits referencing the issue (`refs #175`).
- [ ] CI green — awaiting the run on this PR.
- [x] `docker compose up` unaffected — no service, image or compose file is touched.
- [x] Docs updated — `docs/runbooks/kubernetes-talos.md` §9 (the tunnel, the two registry
      names, the secrets table, the smoke) and a pointer from `docs/runbooks/ci.md`.
- [x] No ADR needed: no new dependency (kubectl/helm/crane are already prerequisites of the
      `k8s-*` targets), no service boundary moved, no CLAUDE.md §8 rule bent.
- [ ] Demo note — not user-visible.

## Notes for reviewers

- **The first deploy is the real test.** It cannot be dry-run: the tunnel, the secrets and the
  registry only exist on the lab server. Merging is how we find out; `Pods on failure` dumps
  `get pods,jobs` if it doesn't.
- **Known gap — the portals still aren't browsable.** PKCE needs a secure context, so a
  NodePort on an IP can't serve them (runbook §5); they need `make k8s-portals` or an SSH
  forward. Giving the server a hostname + TLS is the follow-up, and is where `TALOS_HOST`
  stops defaulting to `localhost`.
- **Databases are `emptyDir`.** Any change to a database pod's template wipes it; the
  `k8s-reseed` in the deploy re-runs the bootstrap, so the stack recovers, but submitted
  registrations do not. Persistence is runbook §6.

🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #176
2026-09-18 13:53:58 +00:00
2026-07-14 14:46:55 +00:00
2026-06-03 11:38:28 +02:00

register-reference

A reference application demonstrating how to build a Dutch government register (a BIG-style professional register) on top of unforked Common Ground modules — OpenZaak, Open Notificaties, Objecten, Open Klant — with loose coupling, modern workflow tooling, and data-governance ready integration points.

This repository is the runnable companion to Respellion's Foundations playbook entry on Common Ground architecture for non-municipal contexts (CIBG, DUO, RVO, and similar uitvoeringsorganisaties).

Status: under active development. See BACKLOG.md for the current iteration.


Start here

Document Purpose
docs/PRD.md What we're building and why. Goals, non-goals, architecture summary, scope. Read once at project start.
CLAUDE.md How we work. Engineering principles, TDD/DDD/BDD discipline, non-negotiable architectural rules, Gitea conventions. Read every task.
BACKLOG.md Iteration plan. A curated mirror of the active Gitea milestone — Gitea Issues are the system of record.
docs/architecture/ Diagrams (Mermaid sources) and ADRs. Start with adr-0001-loose-coupling.md.
docs/runbooks/ Operational guides: local startup, seeding, common failures, CI debugging.

The day-to-day operational pages — environment URLs, known issues right now, on-call notes — live in the Gitea Wiki for this repository. The wiki points at docs/ for anything authoritative.


What this application demonstrates

  • A BIG-style professional register modelled on Dutch public-sector patterns, with four end-user portals: self-service, openbaar register, behandel-portal, beheer-portal.
  • Common Ground modules as upstream peers — never forked, reached only via documented APIs (ZGW, NRC events).
  • An Anti-Corruption Layer that confines all ZGW knowledge to one place, so the rest of the codebase stays domain-shaped rather than municipality-shaped.
  • BPMN + DMN workflows via Flowable as a separate, swappable module — using the external-task job-worker pattern so BPMN models never reach into OpenZaak.
  • A read projection as the public-facing data path, decoupled from the authoritative modules.
  • Synthetic data and mock identity (Keycloak realms standing in for DigiD, eHerkenning, eIDAS, and a medewerker IdP) so the whole system runs locally without external dependencies.
  • TDD, DDD, BDD, mutation testing, ADRs, and Conventional Commits as enforced defaults — encoded in CI.
  • Gitea-native delivery: source, issues, milestones, project boards, releases, container registry, packages, wiki, and Actions.

For the architecture rationale, see docs/PRD.md §3 and docs/architecture/.


Local quickstart

Prerequisites

  • .NET 10 SDK (for make lint/build/unit)
  • A container engine with Compose v2 — Docker, or rootless Podman (see docs/runbooks/ci.md for the Podman + Compose-provider setup)
  • make, curl, git
  • ~4 GB free RAM, ~5 GB free disk (grows as services land)

Clone

git clone git@git.labs.respellion.tech:eho/register-referentie.git
cd register-referentie

Wired today (Iteration 0): only the placeholder BFF exists so far. Get to green in under 10 minutes — run the full check gate, or just the running service:

make ci          # lint + build + unit + container smoke — the CI gate
docker compose -f infra/docker-compose.yml up -d --build --wait
curl http://localhost:8080/health     # -> Healthy

--wait exits non-zero unless the container reports healthy, so it doubles as the compose-up smoke test. The remaining services and the URLs below land in later slices.

Target service URLs (most land in later slices)

Service URL
Self-Service portal http://localhost:4200
Openbaar register http://localhost:4201
Behandel-portal http://localhost:4202
Beheer-portal http://localhost:4203
BFF http://localhost:8080
OpenZaak http://localhost:8000
Open Notificaties http://localhost:8001
Flowable http://localhost:8080
Keycloak http://localhost:8180
MkDocs site (after build) http://localhost:8000/docs/

Test credentials, BSNs, and personas: see docs/synthetic-data.md.

Build the docs site

python3 -m venv .venv && .venv/bin/pip install mkdocs-material
.venv/bin/mkdocs serve         # live preview at http://localhost:8000
.venv/bin/mkdocs build         # static site in ./site

Repository layout

register-reference/
├── apps/                       # Angular portals (Nx monorepo)
│   ├── self-service/
│   ├── openbaar/
│   ├── behandel/
│   └── beheer/
├── libs/                       # shared Angular libs (UI, auth, generated API client)
├── services/                   # .NET services
│   ├── bff/
│   ├── domain/                 # BIG Domain Service
│   ├── acl/                    # Anti-Corruption Layer (the only code that knows ZGW)
│   ├── event-subscriber/
│   └── projection-api/
├── workflows/                  # BPMN + DMN sources
├── infra/                      # docker-compose, Keycloak, OpenZaak, Flowable, seed
├── tests/
│   ├── acceptance/             # Gherkin / Reqnroll BDD scenarios
│   └── e2e/                    # Playwright
├── docs/                       # versioned documentation (MkDocs source)
├── .gitea/                     # Gitea Actions workflows, issue/PR templates
├── CLAUDE.md                   # working agreements
├── BACKLOG.md                  # iteration plan (mirror of active milestone)
└── README.md

Full description in docs/PRD.md §9.


Working in this repository

Source of truth for work: Gitea Issues + Milestones for this repository. BACKLOG.md is a mirror.

Branching: trunk-based. Short-lived branches off main, named <type>/<issue-number>-<short-slug> (e.g. feat/14-acl-default-fill).

Commits: Conventional Commits, referencing the Gitea issue:

feat(acl): default-fill bronorganisatie (refs #14)

The merging PR closes the issue via closes #14 in the squash-commit body.

Pull Requests: the unit of review. Squash-merged. PR template enforces the Definition of Done checklist from CLAUDE.md §3.

Releases: CalVer (YYYY.MM.PATCH), tagged on main, changelog generated by git-cliff, published as a Gitea Release with container images in the Gitea Container Registry.

See CLAUDE.md for the full working agreements, the architectural non-negotiables, and the rules Claude Code follows on every task.


Testing

  • Unit tests — dominant. .NET (xUnit) and Angular (Vitest / Testing Library).
  • Integration tests — Testcontainers-driven, exercising real OpenZaak, Flowable, NRC.
  • Acceptance tests — Gherkin scenarios in tests/acceptance/, one per user-visible flow.
  • End-to-end — Playwright, expanding slice by slice from the walking-skeleton happy path.
  • Mutation testing — Stryker.NET and Stryker, baseline-ratcheted on main.

Run everything:

./tools/test-all.sh

Run a focused slice (example):

dotnet test services/acl

Contributing

  1. Find or open a Gitea issue using one of the templates in .gitea/ISSUE_TEMPLATE/ (slice.md, bug.md, adr-proposal.md).
  2. Assign yourself, move it to "In progress" on the milestone's project board.
  3. Branch off main, follow the CLAUDE.md working agreements (TDD: red commit → green commit → refactor commit).
  4. Open a PR using the template, link the issue, ensure the Gitea Actions pipeline is green.
  5. Squash-merge once approved. The merging commit closes the issue.

If a task pushes against any of the architectural rules in CLAUDE.md §8, stop and open an adr-proposal issue first. That conversation is more important than the code.


License and attribution

Respellion-authored code is licensed under EUPL-1.2. Upstream Common Ground modules retain their own licences (typically EUPL-1.2 or MIT — see each module's repository).

This reference application is not an official product of CIBG, DUO, VNG Realisatie, or any government body. It is a Respellion playbook artefact illustrating an architectural pattern.


Contact

  • Issues, questions, proposals: open a Gitea issue on this repository.
  • Architectural discussion: start with an adr-proposal issue.
  • Anything sensitive: contact Respellion through the channel in docs/runbooks/contact.md.
S
Description
No description provided
Readme
1.8 MiB
2026.07.0
Latest
2026-07-14 14:47:22 +00:00
Languages
C# 60.8%
TypeScript 14.3%
Python 8.5%
Shell 8.3%
Makefile 2.6%
Other 5.4%