RF_ACTIONS

Actions Gitea partagées par les projets de Raggaroth Factory.

Ce dépôt est public parce qu'il doit l'être : act_runner télécharge les actions appelées par uses: sans s'authentifier, et un dépôt privé lui répond « repository not found ». Il ne contient donc que le code des actions — rien qui décrive l'infrastructure qui les exécute. Cette description, les décisions et la procédure d'installation du runner vivent dans RF_CICD, qui reste privé.

Règle qui en découle : rien de propre à une machine, un compte ou un chemin de l'infrastructure n'entre ici. Et aucun secret, jamais — ils arrivent par les entrées des actions, depuis les secrets du dépôt appelant.

build-push

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 :

  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 }}

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

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 correctif existe fait échouer le job : rien n'est publié. Les autres — dont les CVE sans correctif, contre lesquelles personne ne peut rien — sont rapportées dans le journal sans bloquer. Le seuil n'est pas une entrée de l'action : un dépôt ne peut pas l'abaisser pour lui seul.

Une CVE acceptée sciemment va dans .trivyignore.yaml, à la racine du dépôt appelant. Chaque entrée porte une justification et une date d'expiration ; sans l'une ou l'autre, l'action refuse le fichier. À l'échéance, Trivy cesse d'appliquer l'exception et la CVE bloque de nouveau.

vulnerabilities:
  - id: CVE-2026-93990
    statement: libexpat de l'image nginx ; correctif attendu dans la prochaine base
    expired_at: 2026-11-15

Le plus souvent, la correction est une ligne dans le Dockerfile — mettre à jour les paquets de la base (apk upgrade --no-cache, apt-get upgrade) — plutôt qu'une exception.

Exigences : l'image du conteneur de job doit porter buildah et trivy. L'action construit avec --storage-driver vfs --isolation chroot, ce qui fonctionne dans un conteneur non privilégié, sans capacité ajoutée ni /dev/fuse. Les FROM des Dockerfiles construits doivent être des noms complets (docker.io/library/nginx:alpine, pas nginx:alpine) : buildah n'a pas de registre de recherche par défaut, et sa table d'alias est incomplète.

Toujours uses: en URL complète : la forme courte public/RF_ACTIONS/… serait résolue contre le serveur d'actions par défaut de l'instance, qui n'est pas forcément celle-ci.