🔒️ 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)

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
This commit is contained in:
2026-10-08 13:20:09 +02:00
co-authored by Claude Opus 5.5
parent 9d88bc3639
commit 50e0e9e258
2 changed files with 97 additions and 46 deletions
+30 -16
View File
@@ -14,27 +14,41 @@ entrées des actions, depuis les secrets du dépôt appelant.
## `build-push`
Construit une image avec **buildah**, sans démon ni socket, et la publie dans
le registre de Gitea sous les tags de sa filière. **Ne déploie rien.**
Construit une image avec **buildah**, sans démon ni socket, la passe au **scan
de vulnérabilités bloquant**, puis — sur `develop` ou un tag `vX.Y.Z`
seulement — la publie dans le registre de Gitea. **Ne déploie rien.**
**L'image est construite et scannée sur toute référence, PR comprise** : une
image vulnérable fait échouer le pipeline **avant** la fusion, pas après. Le
job qui l'appelle tourne donc sur chaque événement, juste après les tests :
```yaml
- uses: https://gitea.raggaroth-factory.fr/public/RF_ACTIONS/build-push@main
with:
image: gitea.raggaroth-factory.fr/raggaroth-factory/<nom-de-l-image>
dockerfile: Dockerfile
context: .
registry_user: ${{ secrets.REGISTRY_USER }}
registry_password: ${{ secrets.REGISTRY_PASSWORD }}
image:
needs: tests
runs-on: docker
steps:
- uses: actions/checkout@<empreinte de commit> # vX.Y.Z
- uses: https://gitea.raggaroth-factory.fr/public/RF_ACTIONS/build-push@v1.0.0
with:
image: gitea.raggaroth-factory.fr/raggaroth-factory/<nom-de-l-image>
dockerfile: Dockerfile
context: .
registry_user: ${{ secrets.REGISTRY_USER }}
registry_password: ${{ secrets.REGISTRY_PASSWORD }}
```
| Déclencheur | Tags publiés |
|---|---|
| poussée sur `develop` | `:dev` et `:<sha court, 12 caractères>` |
| tag `vX.Y.Z` (ou `vX.Y.Z-rc.1`) | `:vX.Y.Z`, orthographié comme le tag git, et rien d'autre |
| toute autre référence | **échec**, sans rien construire |
| Référence | Construction + scan | Publication |
|---|---|---|
| poussée sur `develop` | oui | `:dev` et `:<sha court, 12 caractères>` |
| tag `vX.Y.Z` (ou `vX.Y.Z-rc.1`) | oui | `:vX.Y.Z`, orthographié comme le tag git, et rien d'autre |
| PR, autre branche, `main` | oui | **rien** |
Sorties : `tags` (les tags publiés) et `digest` (l'empreinte `sha256:…` de
l'image publiée).
Les identifiants du registre ne sont lus **que** si la référence publie : une PR
ne se connecte pas au registre. Ils sont exigés dans ce cas, et leur absence est
une erreur explicite.
Sorties : `publie` (`true` / `false`), `tags` (les tags publiés, vide sinon) et
`digest` (l'empreinte `sha256:…` de l'image publiée).
**Scan de vulnérabilités bloquant.** Entre la construction et la publication,
**Trivy** examine l'image. Une CVE **HIGH ou CRITICAL pour laquelle un