[CI] Docker Bench Security will always be manual

.gitlab-ci.yml

@@ -60,7 +60,9 @@ set-variables:
   rules:
     - changes:
       - "pica-*/Dockerfile"
+      - "pica-*/clair-whitelist.yml"
       - "meta-*/Dockerfile"
+      - "meta-*/clair-whitelist.yml"
       when: always
     - changes:
       - "pica-*/**"
@@ -155,18 +157,11 @@ docker-bench-security:
     paths:
       - report.txt
   rules:
-    - changes:
-      - "pica-*/Dockerfile"
-      - "pica-*/docker-compose.yml"
-      - "meta-*/Dockerfile"
-      - "meta-*/docker-compose.yml"
-      when: on_success
     - changes:
       - "pica-*/**"
       - "meta-*/**"
       when: manual
       allow_failure: true
-    - when: never
 
 # Push the generated image on the production registry,
 # once it passed all security tests and has been successfully built

doc/guide_developpeur_ci.md

@@ -37,7 +37,7 @@ La mise à jour d'un `Dockerfile` entraîne le lancement de l'ensemble de la CI.
 
 La mise à jour d'une liste blanche de CVE (voir [Formalisme du dépôt](#formalisme-du-dpt)) déclenche uniquement l'analyse de sécurité statique sur la dernière image construite (pas de nécessité de reconstruire l'image).
 
-La mise à jour d'un `docker-compose.yml` déclenche l'analyse de sécurité dynamique sur la dernière image construite (pas de nécessité de reconstruire l'image).
+La mise à jour d'un `docker-compose.yml` déclenchait l'analyse de sécurité dynamique sur la dernière image construite (pas de nécessité de reconstruire l'image) : à présent, elle n'est déclenchée que manuellement.
 
 La mise à jour d'un fichier autre donne la possibilité de déclencher manuellement les étapes de la CI : on appréciera au cas par cas s'il est nécessaire de reconstruire l'image. Par exemple, mettre à jour le `README` ou un fichier de secrets d'exemple ne devrait pas déclencher la CI, tandis que mettre à jour un fichier de configuration devrait déclencher la CI.