🔒️ build-push construit et scanne sur toute référence, PR comprise ; il ne publie que sur develop et les tags (RF_CICD#7) #5

2026-10-08T13:20:23+02:00

george-claude commented

2026-10-08 13:20:23 +02:00

Refs raggaroth-factory/RF_CICD#7. Ta demande du 2026-10-08 : « il faut que le scan se fasse au build pour empêcher le build ».

Le trou qu'elle comble

Jusqu'ici, le scan ne tournait que dans le job publication, qui ne démarre qu'après la fusion sur develop. Aucune PR n'était scannée : une dépendance vulnérable passait la revue, et on ne l'apprenait qu'une fois fusionnée.

Ce qui change

Référence	Construction et scan	Publication
`develop`	✅	`:dev` et `:<sha>`
`vX.Y.Z`	✅	`:vX.Y.Z`
PR, autre branche, `main`	✅ nouveau	rien

Avant, ces dernières références faisaient échouer l'action sans rien construire.

Identifiants du registre facultatifs : ils ne sont lus que pour publier, et sont alors exigés. Une PR ne se connecte pas au registre.
REGISTRY_AUTH_FILE n'est plus exporté quand on ne publie pas. Pointé sur un fichier absent, il faisait échouer buildah jusque dans l'export local de l'image vers le scan. Le banc l'a révélé.
Nouvelle sortie publie. tags est vide quand rien n'est publié.

Banc (2026-10-08)

Les deux étapes sont extraites du YAML et enchaînées, avec trivy 0.75.0 et un registre jetable. Le frontend de develop sert d'image : avec son .trivyignore.yaml pour l'image saine, sans pour l'image vulnérable.

#	Cas	Résultat
A	PR, sans identifiants, saine	code 0, « ne publie rien », registre vide
B	PR, sans identifiants, vulnérable	code 1, image refusée, registre vide
C	`develop`, identifiants	code 0, `:dev` et `:<sha>` publiés
D	`develop`, sans identifiants	code 1, erreur explicite
E	`main`	code 0, rien publié

La suite

Fusionner cette PR, puis la release vers main.
Tu poses le tag v1.0.0 sur main, et tu protèges v*.
Dans chaque consommateur, une PR : le job publication devient image. Il tourne sur chaque événement, PR comprises, et passe à @v1.0.0.

La lisibilité du rapport fait l'objet de RF_CICD#32, en cadrage lointain.

🤖 Generated with Claude Code

Refs raggaroth-factory/RF_CICD#7. Ta demande du 2026-10-08 : « il faut que le scan se fasse au build pour empêcher le build ». ## Le trou qu'elle comble Jusqu'ici, le scan ne tournait que dans le job `publication`, qui ne démarre qu'**après la fusion** sur `develop`. **Aucune PR n'était scannée** : une dépendance vulnérable passait la revue, et on ne l'apprenait qu'une fois fusionnée. ## Ce qui change | Référence | Construction et scan | Publication | |---|---|---| | `develop` | ✅ | `:dev` et `:<sha>` | | `vX.Y.Z` | ✅ | `:vX.Y.Z` | | PR, autre branche, `main` | ✅ **nouveau** | rien | Avant, ces dernières références faisaient échouer l'action sans rien construire. - **Identifiants du registre facultatifs** : ils ne sont lus que pour publier, et sont alors exigés. Une PR ne se connecte pas au registre. - `REGISTRY_AUTH_FILE` n'est plus exporté quand on ne publie pas. Pointé sur un fichier absent, il faisait échouer `buildah` jusque dans l'export local de l'image vers le scan. Le banc l'a révélé. - Nouvelle sortie `publie`. `tags` est vide quand rien n'est publié. ## Banc (2026-10-08) Les deux étapes sont extraites du YAML et enchaînées, avec trivy 0.75.0 et un registre jetable. Le frontend de `develop` sert d'image : avec son `.trivyignore.yaml` pour l'image saine, sans pour l'image vulnérable. | # | Cas | Résultat | |---|---|---| | A | PR, sans identifiants, saine | code 0, « ne publie rien », registre vide | | B | PR, sans identifiants, vulnérable | **code 1, image refusée**, registre vide | | C | `develop`, identifiants | code 0, `:dev` et `:<sha>` publiés | | D | `develop`, sans identifiants | code 1, erreur explicite | | E | `main` | code 0, rien publié | ## La suite 1. Fusionner cette PR, puis la release vers `main`. 2. **Tu poses le tag `v1.0.0`** sur `main`, et tu protèges `v*`. 3. Dans chaque consommateur, une PR : le job `publication` devient `image`. Il tourne sur **chaque** événement, PR comprises, et passe à `@v1.0.0`. La lisibilité du rapport fait l'objet de **RF_CICD#32**, en cadrage lointain. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

george-claude added 1 commit 2026-10-08 13:20:23 +02:00

🔒️ build-push construit et scanne sur toute référence, PR comprise ; il ne publie que sur develop et les tags (raggaroth-factory/RF_CICD#7 ) 50e0e9e258

Demande de Benjamin, 2026-10-08 : « il faut que le scan se fasse au build
pour empêcher le build ». Jusqu'ici, le scan ne tournait que dans la
publication, après la fusion : une PR n'était jamais scannée, et une
dépendance vulnérable passait la revue.

- Toute référence : construction + scan bloquant. Seules develop et
  vX.Y.Z publient ; une PR, une autre branche ou main s'arrêtent après le
  scan, sous un tag local « controle-<sha> » jamais poussé.
- Identifiants du registre facultatifs : lus et exigés seulement si la
  référence publie. Une PR ne se connecte pas au registre.
- REGISTRY_AUTH_FILE n'est exporté que pour publier : pointé sur un
  fichier absent, il faisait échouer buildah jusque dans l'export local
  vers le scan (constaté au banc, « credential file is not accessible »).
- Sortie « publie » ; « tags » vide quand rien n'est publié.

Banc, 2026-10-08, les deux étapes extraites du YAML et enchaînées :
  A. PR, sans identifiants, saine      → code 0, registre vide
  B. PR, sans identifiants, vulnérable → code 1, image refusée
  C. develop, identifiants             → :dev et :<sha> publiés
  D. develop, sans identifiants        → code 1, erreur explicite
  E. main                              → code 0, rien publié

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VyxLNGHojdXeRMQgWFgzRV

bbaudouin approved these changes

2026-10-08 13:30:17 +02:00

bbaudouin merged commit 3874a35e91 into develop

2026-10-08 13:30:24 +02:00

bbaudouin deleted branch ci/7-scan-a-chaque-construction

2026-10-08 13:30:24 +02:00

george-claude referenced this pull request

2026-10-08 13:31:12 +02:00

🔖 Release v1.0.0 : main reçoit le scan à chaque construction (RF_CICD#7, #8) #6

Sign in to join this conversation.