Elke bouw van de sandbox-image blijft voorgoed in het register staan #149

Aanleiding

Elke keer dat er iets op de hoofdlijn landt, wordt de sandbox-image opnieuw gebouwd en gepubliceerd onder een eigen kenmerk. Die uitgaven blijven daarna allemaal staan. Voor voorstellen bestaat al een opruiming, voor de hoofdlijn niet.

Effect

Het register groeit onbeperkt met uitgaven die niemand meer gebruikt. Op dit moment staan er 644 uitgaven in, waarvan 466 losse onderdelen zonder kenmerk en 177 met een kenmerk per commit; de oudste is van 6 mei 2026. In augustus kwamen er 196 bij. Alleen de nieuwste en de uitgaven die bij een release horen worden nog geraadpleegd.

Dat kost opslag, maakt het overzicht in het register onbruikbaar, en het is niet meer te zien welke uitgaven er werkelijk toe doen.

Wenselijk gedrag

Uitgaven van de hoofdlijn worden na verloop van tijd opgeruimd, met uitzondering van wat aantoonbaar nog nodig is: de nieuwste, en alles wat bij een release hoort.

Acceptatiecriteria

• Uitgaven van de hoofdlijn ouder dan een af te spreken termijn worden automatisch opgeruimd
• De nieuwste uitgave en uitgaven die bij een release horen blijven altijd staan
• Bijbehorende onderdelen zonder kenmerk (handtekeningen, inhoudsopgaven, herkomstbewijzen) verdwijnen mee, zodat er geen weeskinderen achterblijven
• De opruiming meldt wat ze verwijdert, zodat een fout in de selectie opvalt voordat er iets weg is
• Wat er niet opgeruimd wordt en waarom, is vastgelegd

Technische details

De builds komen uit .github/workflows/build-image.yml; die publiceert per push naar main een sha-<commit>-tag plus latest, en bij een tag ook de versietag. provenance en sbom staan aan, dus per uitgave horen er ook attestatie-manifests bij — dat verklaart het grootste deel van de 466 uitgaven zonder tag.

Voor previews bestaat .github/workflows/cleanup-preview.yml, die bij het sluiten van een voorstel de bijbehorende pr-<n>-versies opruimt. Voor main is er geen equivalent.

Let op bij de selectie: een attestatie-manifest draagt een tag in de vorm sha256-<digest> en hoort bij precies één image-uitgave. Ruim je die los op, dan blijven er handtekeningen zonder image achter of andersom. actions/delete-package-versions kent min-versions-to-keep, maar houdt geen rekening met dat verband; de bestaande opruiming voor previews doet dat wel en is het patroon om te volgen.

Alternatief zonder eigen workflow: het register kent een bewaarbeleid per pakket. Dat is minder precies (het kent het verband tussen image en attestatie evenmin) maar vraagt geen onderhoud.

Gemeten op 27-08-2026 via de pakket-API van de organisatie.