Skip to content

feat(versiebeheer): build_sources.py — manifest-gedreven multi-versie build (Fase 1a)#411

Draft
robbertbos wants to merge 1 commit into
feat/sources-versiebeheerfrom
feat/sources-versiebeheer-fase1-build
Draft

feat(versiebeheer): build_sources.py — manifest-gedreven multi-versie build (Fase 1a)#411
robbertbos wants to merge 1 commit into
feat/sources-versiebeheerfrom
feat/sources-versiebeheer-fase1-build

Conversation

@robbertbos

Copy link
Copy Markdown
Member

Fase 1a — manifest-gedreven multi-versie build (build_sources.py)

De testbare kern van Fase 1: de build-orchestrator die meerdere versies naast elkaar produceert. Dit is de bouwsteen die de registry (#408) en de pin (#410) pas écht laat werken — zonder meerdere gebouwde versies is resolve-by-pin gedrag-loos.

Wat

  • script/build_sources.py: leest sources/manifest.yaml, loopt elke (type, version), hergebruikt de bestaande SchemaValidator + DefinitionEnricher (exact dezelfde transform als run_all.py), en schrijft:
    • sources/generated/<type>/<version>.json — geneste, versie-gerichte output
    • sources/generated/manifest.json — de runtime SourceManifest die frontend/standalone consumeren (voor /modellen + "nieuwere versie"-detectie)
  • Faalt hard (ValueError) als een bron de definitie-schema-validatie niet haalt — geen half-valide registry.
  • 3 pytest-tests (echte build van de echte bronnen + het error-pad); python-suite 57 groen, ruff schoon.

Bewust NIET in deze PR (CI-rakend → aparte stap)

  • De 6 buildsites omhangen (4 workflows + 2 Containerfile.dev + het productie-COPY-pad) van run_all.py×3 naar build_sources.py. Dit raakt deploy-workflows en is niet lokaal volledig te valideren (GHA draait op GitHub) — daarom geïsoleerd, met actionlint + zorgvuldige review als vervolg.
  • Bronbestand-verhuizing (sources/dpia.yamlsources/dpia/3.0.yaml): de platte output + de 3 hardcoded app-imports blijven nu intact; verhuizen kan pas als de buildsites + imports mee-switchen.
  • Concept-autonummer + content-digest per entry: toevoegen zodra er een concept-versie in het manifest staat (nu nog geen).

Aandachtspunten

  • Additief & risicovrij: deze PR verandert niets aan de bestaande build/CI/apps — build_sources.py wordt nog nergens aangeroepen. Het is de geteste fundering waarop de buildsite-migratie (vervolg-PR) bouwt.
  • De runtime manifest.json matcht 1-op-1 de SourceManifest-types in packages/assessment-core/src/versioning/manifest.ts.

Stapelt op de epic-branch feat/sources-versiebeheer (#406). Onafhankelijk van de Fase-2 pin-stack (#408/#409/#410).

… build (Fase 1a)

Nieuwe orchestrator die per (type, version) uit sources/manifest.yaml dezelfde
validate->enrich-transform als run_all.py draait en sources/generated/<type>/<version>.json
produceert, plus een runtime sources/generated/manifest.json (de SourceManifest die de
apps consumeren). Additief: de platte output en de 6 buildsites blijven ongewijzigd; het
inhaken van de buildsites is een aparte, CI-rakende vervolgstap. Python 57 tests groen.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant