Remove Docker Buildx GHA cache config

[Kaiohz]

No description provided.

[Kaiohz]

Review PR #19 — Remove Docker Buildx GHA cache config

Score : 7/10 — PR correcte, ciblée et sans pollution, mais avec quelques points à clarifier/renforcer avant merge.

✅ Ce qui est bien

• Diff focalisé : 1 commit, 1 fichier, 3 lignes supprimées (+0 / -3). Aucun commit parasite, aucun reformat, aucun "WIP" mêlé au fix. C'est exactement ce qu'on attend d'un hotfix CI.
• Scope clair : le titre matche le contenu à la lettre, pas de surprise.
• compare main...fix/cahce-cd = 1 ahead, 0 behind : pas de rebase à faire, pas de conflit possible, merge trivial.
• Identifie bien le bon bloc : les 3 lignes supprimées sont celles qui touchent au cache GHA (cache-from sur le scan + cache-from + cache-to sur le build/push). C'est cohérent.
• Pas d'introduction d'un autre cache exotique en remplacement (donc pas de régression silencieuse type registry login oublié ou scope de cache élargi).

⚠️ Points à vérifier / clarifier

1. Body de PR vide — Le body: null sur la PR est un problème de process. Pour un changement de config CI, on veut au minimum :

   • Pourquoi le cache GHA est supprimé (cache miss systématique ? quota GHA ? warning sur cache-from: type=gha non supporté sur le runner ? restore d'une image non pinnée ?)
   • Impact attendu sur le temps de build/CD (estimation : +30s à +2min par run sans cache, à confirmer)
   • Action de suivi éventuelle (réintroduire un cache registry-based ? ticket Jira ?)

2. Conséquence sur la prod CD — Sans cache-from: type=gha, chaque exécution du step build-and-push repart d'un cold pull de toutes les couches. Sur une image Node/TS avec potentiellement des centaines de layers (ou une base lourde), ça peut faire passer le job de ~1min à 5-10min. À valider sur le prochain run CD après merge.

3. Cohérence avec le step Trivy — Le premier step (Trivy Image Scan) a aussi perdu son cache-from: type=gha mais ne le faisait qu'en lecture, donc l'impact est nul ici. Pas un bug, juste à noter dans la description de la PR.

4. Pas de reintroduction d'un cache-to — Bonne décision : si le cache GHA était défaillant, cache-to ne faisait que polluer le cache partagé. Le retirer des deux côtés est cohérent.

5. Typo dans le nom de branche — fix/cahce-cd au lieu de fix/cache-cd. Pas bloquant (le squash merge écrasera le nom de branche), mais c'est révélateur d'un manque de relecture avant push.

💡 Suggestions

• Court terme : merger la PR telle quelle si la décision "on supprime le cache GHA" est validée — le code est bon.
• Moyen terme : ajouter une issue / un ticket pour suivre la réintroduction d'un cache alternatif (registry local type type=registry,ref=... ou cache self-hosted). Le fait qu'on désactive sans alternative peut masquer un vrai problème de perf CI.
• Process : rappeler l'usage d'un template de PR avec sections "Pourquoi" / "Impact" / "Tests". Pour la config CI c'est encore plus important que pour le code applicatif.

Verdict

Approuvable après ajout d'un body de PR expliquant la motivation. Code propre, scope net, pas de régression identifiée. Le 7/10 plutôt que 9/10 vient du body vide + l'absence de plan de remplacement.