fix(ci): restart registry post-GC + canari pullabilité client #34

Merged

kevin merged 1 commit from fix/registry-cache-canary into main

2026-07-21 16:47:33 +00:00

kevin commented

2026-07-21 16:19:16 +00:00

Owner

Contexte — 2e couche de l'incident registre du 21-07

Le re-publish de la v5.134.2 n'avait pas réparé le registre : 7 couches partagées avec les anciennes versions restaient à 0 octet. Cause : le cache blobdescriptor: inmemory du registre ne voit pas les suppressions disque du GC → HEAD répondait 200 sur des blobs détruits → docker push les sautait (« déjà là ») et les vérifications HEAD mentaient. Réparé à la main (restart registry + re-push, vérifié en GET : gungnir 28/28, updater 7/7).

Les deux garde-fous

Restart du registre après chaque GC (étape rétention) — purge le cache menteur. Coupure pull de ~2 s, aucun impact prod (la prod ne pull jamais).
Étape canari en fin de release — suit le chemin exact d'un docker pull anonyme via nginx : tag → manifest/index → manifests feuilles → config + chaque couche en GET avec comptage d'octets vs la taille déclarée (un HEAD ne prouve rien), sur les deux images × VERSION + latest. Échec = release rouge : le deploy prod est déjà fait à ce stade, mais la casse se voit dans le run au lieu d'être découverte par un self-hosteur.

La boucle du canari est celle utilisée trois fois aujourd'hui pour diagnostiquer puis prouver la réparation — testée sur le vrai registre dans les deux états (cassé et sain). set +e explicite pour lister TOUS les blobs KO au lieu d'avorter au premier. Validé : YAML parse + bash -n des deux steps ; $VERSION disponible via GITHUB_ENV (posé en début de workflow).

🤖 Generated with Claude Code

## Contexte — 2e couche de l'incident registre du 21-07 Le re-publish de la v5.134.2 n'avait pas réparé le registre : 7 couches partagées avec les anciennes versions restaient à 0 octet. Cause : le cache `blobdescriptor: inmemory` du registre ne voit pas les suppressions disque du GC → HEAD répondait 200 sur des blobs détruits → `docker push` les sautait (« déjà là ») et les vérifications HEAD mentaient. Réparé à la main (restart registry + re-push, vérifié en GET : gungnir 28/28, updater 7/7). ## Les deux garde-fous 1. **Restart du registre après chaque GC** (étape rétention) — purge le cache menteur. Coupure pull de ~2 s, aucun impact prod (la prod ne pull jamais). 2. **Étape canari en fin de release** — suit le chemin exact d'un `docker pull` anonyme via nginx : tag → manifest/index → manifests feuilles → config + **chaque couche en GET avec comptage d'octets** vs la taille déclarée (un HEAD ne prouve rien), sur les deux images × `VERSION` + `latest`. Échec = release **rouge** : le deploy prod est déjà fait à ce stade, mais la casse se voit dans le run au lieu d'être découverte par un self-hosteur. La boucle du canari est celle utilisée trois fois aujourd'hui pour diagnostiquer puis prouver la réparation — testée sur le vrai registre dans les deux états (cassé et sain). `set +e` explicite pour lister TOUS les blobs KO au lieu d'avorter au premier. Validé : YAML parse + `bash -n` des deux steps ; `$VERSION` disponible via `GITHUB_ENV` (posé en début de workflow). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kevin added 1 commit

2026-07-21 16:19:17 +00:00

fix(ci): restart registry post-GC + canari pullabilité client

CI / Backend — pytest (pull_request) Successful in 47s

Details

CI / i18n — usage → locales (pull_request) Successful in 5s

Details

79b8780468

2e couche de l'incident du 21-07 : le cache blobdescriptor inmemory du
registre ne voit pas les suppressions du GC → HEAD 200 sur des blobs
détruits, les pushes suivants les sautent (« déjà là ») et 7 couches
partagées sont restées à 0 octet malgré le re-publish — réparé à la main
(restart + re-push). Deux garde-fous :

- restart du registre après chaque GC dans l'étape rétention (purge le
  cache menteur ; coupure pull ~2 s, aucun impact prod) ;
- nouvelle étape canari en fin de release : suit le chemin exact d'un
  docker pull anonyme via nginx (tag → manifests feuilles → config +
  chaque couche en GET avec comptage d'octets vs taille déclarée) sur
  les deux images × VERSION + latest. Échec = release rouge — on voit
  la casse au lieu de l'apprendre d'un self-hosteur.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

kevin merged commit 75ead4c3fc into main

2026-07-21 16:47:33 +00:00

kevin deleted branch fix/registry-cache-canary

2026-07-21 16:47:33 +00:00

kevin referenced this pull request from a commit

2026-07-21 16:47:34 +00:00

fix(ci): restart registry post-GC + canari pullabilité client (#34)