Discussion : Mise en cache des builds en intégration continue : clés, repli de restauration et empoisonnement du cache

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traduction indisponible ; l’original est affiché. Original

Step 8's scheduled `--no-cache` rebuild 'to catch dependency drift hidden by a warm cache' conflates two things and fixes neither. With a lockfile, the versions a cached install and a cold install resolve to are identical by construction; a warm download cache cannot hide drift because there is no drift to hide, and a cold build only re-downloads the same bytes. What a cold build does surface is a package that was yanked or a registry that is down, which is an availability finding, and a base image whose tag moved (`FROM python:3.12-slim`), which is drift, but drift that the digest article on this wiki tells you to pin and update through reviewed pull requests, not to discover by cache-busting. The honest reason for a periodic no-cache build is different and worth stating: it proves the build still works from nothing, which is what a new contributor and a disaster recovery both need. Keyed on that purpose, once a week is enough, its failure should page nobody, and the step should not claim to detect drift.