Images Docker pour déploiements et CI
Image ruby pour la production.
Image ruby pour la configuration des déploiements.
Image Node pour les installations, lint, types et tests sans navigateur. Fournit les outils de
images/node-ci/Aptfile, notamment Git, curl et zstd.
Étend le même socle avec Playwright et Chromium préinstallés, pour les tests navigateur et les audits d’accessibilité.
Chaque image possède son Dockerfile et son workflow de publication.
images/node-ci-chromium/Dockerfile hérite de l’image node-ci publiée,
épinglée par version et digest, comme rails-ci hérite de ruby-ci.
Les outils communs restent déclarés dans images/node-ci/Aptfile.
Une publication de node-ci est détectée par Renovate, qui propose une mise
à jour du FROM de node-ci-chromium. Le merge de cette mise à jour sur
main déclenche la reconstruction et la publication de Chromium.
Il n’y a pas de build sur PR. Les publications automatiques et manuelles
sont limitées à main.
Migration : node-ci contenait auparavant Chromium. Les jobs qui utilisent
le navigateur doivent adopter node-ci-chromium et son digest publié.
Les anciens digests restent associés à leur ancien contenu ; mettre à jour
leur digest sous le nom node-ci adopte désormais la variante sans navigateur.
Pour Alvéole, utiliser node-ci pour l’installation, les contrôles de sources
et les tests unitaires, et node-ci-chromium pour le job web/accessibilité.
La référence de Groove est migrée séparément, ultérieurement.
Runner ARC (self-hosted GitHub Actions) basé sur
falcondev-oss/actions-runner, aveczstdembarqué pour la compression du cache GitHub Actions. Évite l'installation de zstd au démarrage de chaque runner éphémère.
Créer un dossier pour l'image dans /images
Ajouter un fichier Dockerfile dans le dossier
Ajouter une configuration de déploiement automatique via un fichier publish-mon-image.yml dans .github/workflows
Configurer la publication de l'image :
- Le workflow doit écouter uniquement les changements du
Dockerfileet du fichierpublish-mon-image.ymlsurmain - Le workflow doit extraire la version de l'image a publier. Attention: Il faut prendre en compte que Renovate va pin les images utilisée, par exemple si vous utilisez
cimg/ruby:4.0.2renovate le transformera encimg/ruby:4.0.2@sha256:XXXXXXXXXmais on veut extraire uniquement4.0.2. - Le workflow doit extraire les metadata et définir l'image comme
latest. On doit pouvoir récupérer l'image par sa version, son sha et latest. - Le workflow doit plublier le package sur le repo
Rendre publique le package créé. A la première publication, il faut rendre publique le package et donc les images qu'il contient pour faciliter la récupération.
Pour cela, rendez-vous dans les setting du package https://github.com/orgs/captive-studio/packages/container/mon-image/settings et définissez le package comme publique dans la Danger zone.
Configurer renovate pour votre image :
- Ajouter un fichier
preset.jsondans le dossier de votre image avec les règles renovate - Etendre ce preset dans la configuration renovate à la racine de ce projet
- Ajouter votre image à la configuration renovate partagée dans le repo renovate-config.
A noter : Il est important d'attendre moins longtemps après une release que la configuration de base de renovate afin de fournir une image de la version au moment ou renovate passera sur le projet utilisant l'image. De la même manière il faut que votre image soit authorisée moins de temps après la release. Par exemple: si renovate-config attendait 3 jours après une release, alors votre preset doit attendre 1 jour et renovate-config doit attendre 2 jours pour votre image. Ainsi le comportement restera similaire.
Pour consommer votre package, il est préférable d'utiliser la version et non latest ou sha-xxx afin que Renovate tourne correctement dans votre projet cible.
Par exemple: ghcr.io/captive-studio/ruby-ci:4.0.2