feat(versiebeheer): build_sources.py — manifest-gedreven multi-versie build (Fase 1a)#411
Draft
robbertbos wants to merge 1 commit into
Draft
Conversation
… 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.
This was referenced Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: leestsources/manifest.yaml, loopt elke(type, version), hergebruikt de bestaandeSchemaValidator+DefinitionEnricher(exact dezelfde transform alsrun_all.py), en schrijft:sources/generated/<type>/<version>.json— geneste, versie-gerichte outputsources/generated/manifest.json— de runtimeSourceManifestdie frontend/standalone consumeren (voor/modellen+ "nieuwere versie"-detectie)ValueError) als een bron de definitie-schema-validatie niet haalt — geen half-valide registry.Bewust NIET in deze PR (CI-rakend → aparte stap)
Containerfile.dev+ het productie-COPY-pad) vanrun_all.py×3 naarbuild_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.sources/dpia.yaml→sources/dpia/3.0.yaml): de platte output + de 3 hardcoded app-imports blijven nu intact; verhuizen kan pas als de buildsites + imports mee-switchen.Aandachtspunten
build_sources.pywordt nog nergens aangeroepen. Het is de geteste fundering waarop de buildsite-migratie (vervolg-PR) bouwt.manifest.jsonmatcht 1-op-1 deSourceManifest-types inpackages/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).