De testsuite controleert alleen of een sjabloon geldige YAML oplevert. Een
depends_on in de verkeerde vorm of network_mode naast networks is prima YAML en
een kapotte stack — dat merkte je pas als iemand de app installeerde.
- tools/render_voor_validatie.py rendert elk sjabloon naar echte
compose-bestanden; sjablonen met schakelbare onderdelen leveren meerdere
varianten op (standaard, alles aan, met en zonder VPN), zodat ook de
conditionele blokken langskomen die met alleen de standaardwaarden nooit
gerenderd worden
- Nieuwe stap in build.yml, deploy.yml en deploy-prod.yml die er
`docker compose config` overheen haalt. Renderen gebeurt in de
python-container, valideren op de runner zelf: Python en Docker staan in CI
niet op dezelfde plek
145 bestanden uit 142 sjablonen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De testsstap die ik in v0.5.00 toevoegde blokkeerde de deploy: de runner heeft
geen python3-venv, dus `python3 -m venv` faalde en alle volgende stappen werden
overgeslagen.
- Tests draaien nu in python:3.12-slim via docker, dat de runner sowieso heeft.
Bijkomend voordeel: dezelfde Python-versie als waarop de app in productie
draait, in plaats van wat er toevallig op de runner staat.
- PYTHONDONTWRITEBYTECODE en -p no:cacheprovider voorkomen dat de container
root-eigen __pycache__/.pytest_cache in de werkmap achterlaat, wat de
rsync-stap en volgende checkouts zou kunnen hinderen.
- Pip-cache in een named volume, zodat een herhaalde run niet opnieuw downloadt.
Toegepast in deploy.yml, deploy-prod.yml en build.yml.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7oLCRYzY5ixJ5Sv8Y8EFb
- Update-kanalen stable/beta in plaats van het vinkje "pre-releases meenemen".
Stable ziet alleen releases, beta ook pre-releases; een release telt hoger
dan zijn eigen beta (0.5.10-beta1 < 0.5.10). UPDATE_INCLUDE_PRERELEASE
migreert automatisch naar het beta-kanaal.
- Nieuw core/selfupdate.py: image uit de registry ophalen, SU_TAG wegschrijven
en de eigen container laten hercreeren door een korte helper-container die op
het nieuwe image draait (bevat de docker- en compose-CLI al). Een container
kan zichzelf niet hercreeren, vandaar de helper.
- Deploy-map wordt uitgelezen uit de compose-labels van de eigen container.
Ontbreken die, draait de container niet vanaf een registry-image of is de
docker-socket er niet, dan meldt de UI waarom bijwerken niet kan.
- Vorige tag wordt onthouden; terugrolknop in de instellingen.
- Update-check een uur gecached, met geforceerde check via de knop; eerder deed
elke paginalading een netwerkverzoek. Laatst-gecontroleerd zichtbaar.
- Registry-inloggegevens instelbaar; het token komt net als de git-tokens nooit
terug via de API en leeg laten betekent ongewijzigd.
- docker-compose.yml gebruikt ${SU_IMAGE:-server-up}:${SU_TAG:-latest}; zonder
SU_IMAGE blijft lokaal bouwen werken zoals voorheen.
- deploy-prod.yml bouwt en pusht het image in dezelfde job wanneer SU_IMAGE
ingesteld is; build.yml is nu alleen handmatig. Bewust geen aparte
build-workflow op dezelfde tag: bij een runner met een job tegelijk zou de
deploy wachten op een build die zelf nog in de wachtrij staat.
- docs/updates.md: werking, complete Forgejo-instelling (registry, tokens,
variables, secrets, runners), release-procedure voor stable en beta,
terugrollen en probleemoplossing.
- Tests uitgebreid naar 148 (kanaallogica, cache, image-afleiding incl.
registry-poortnummers, tag-validatie, .env-schrijven, tokenlek).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7oLCRYzY5ixJ5Sv8Y8EFb
