publish-docker

Build + push d'une image Docker sur le registry interne, avec routage staging/prod basé sur le titre du commit de release. Le composant génère deux jobs : publish-docker-staging et publish-docker-prod, qui partagent un job masqué .publish-docker-base.

Intègre déjà le tagging (release-util tag) et la génération des badges, donc ne pas combiner avec release-tag ni release-badges.

Snippet d'include

Minimum :

include:
  - component: $CI_SERVER_FQDN/spektrum/ci-templates/publish-docker@<version>
    inputs:
      image_name: mon-service

stages:
  - publish

Avec personnalisation :

include:
  - component: $CI_SERVER_FQDN/spektrum/ci-templates/publish-docker@<version>
    inputs:
      stage: deploy
      tags: [linux, gpu]
      image_name: vision-service
      registry: registry.internal.spektrum-suisse.ch
      dockerfile: ./docker/Dockerfile.prod
      context: ./service
      floating_tag_prod: stable
      floating_tag_staging: edge

Inputs

Input	Requis	Défaut	Description
stage	non	publish	Stage des deux jobs.
tags	non	[linux]	Tags de runner (tableau).
image_name	oui	—	Nom de l'image (sans registry ni tag). Ex. buchsearch.
registry	non	registry.internal.spektrum-suisse.ch	Registry Docker cible.
dockerfile	non	./Dockerfile	Chemin du Dockerfile.
context	non	.	Contexte de build.
floating_tag_prod	non	latest	Tag flottant pour les builds prod.
floating_tag_staging	non	latest-staging	Tag flottant pour les builds staging.
npm_scope	non	@spektrum	Scope npm à configurer pour tirer release-util.
npm_scope_registry	non	https://npm.internal.spektrum-suisse.ch/	URL du registry npm associé au scope.

Jobs générés

Job	Trigger
publish-docker-staging	Commit chore(release): X.Y.Z-staging.N ou Merge branch 'release/…-staging.N' sur la branche par défaut. Image taguée <version> + latest-staging.
publish-docker-prod	Commit chore(release): X.Y.Z (sans suffixe) ou Merge branch 'release/X.Y.Z' sur la branche par défaut. Image taguée <version> + latest.

Les deux namespaces de tags flottants sont disjoints : promouvoir latest ne touche pas latest-staging et vice-versa. Staging et prod tirent depuis des tags indépendants.

Ce que fait .publish-docker-base

1. Configure le scope npm @spektrum → registry interne.
2. Configure origin avec RELEASE_TOKEN pour que release-util tag puisse pousser.
3. eval $(npx --yes @spektrum/release-util@latest tag) — pousse le tag et exporte RELEASE_VERSION, RELEASE_ENV, RELEASE_TAG.
4. Calcule BUILD_DATE (ISO 8601 UTC).
5. docker build avec --build-arg VERSION_TAG="${RELEASE_VERSION}" et --build-arg BUILD_DATE="${BUILD_DATE}", tag versionné.
6. docker tag versionné → tag flottant.
7. docker push des deux tags.
8. npx @spektrum/release-util@latest badges --out badges → artefact expire_in: never.

Build-args injectés dans l'image

À déclarer dans le Dockerfile pour les consommer :

ARG VERSION_TAG
ARG BUILD_DATE

LABEL org.opencontainers.image.version="${VERSION_TAG}"
LABEL org.opencontainers.image.created="${BUILD_DATE}"
ENV APP_VERSION=${VERSION_TAG}

VERSION_TAG vaut X.Y.Z ou X.Y.Z-staging.N. BUILD_DATE est un timestamp UTC ISO 8601.

Pré-requis

Côté projet :

• Variable CI/CD RELEASE_TOKEN (Protected + Masked) avec scope write_repository. Voir ../setup.md.
• Squash merge désactivé pour les MR release/*.

Côté runner :

• Daemon Docker disponible.
• Pré-authentification au registry (typiquement ~/.docker/config.json provisionné machine). Les jobs ne font pas de docker login. Voir ../setup.md.

Surcharges courantes

Pour ajouter un scan de vulnérabilités après le push, étendre le job public correspondant dans le .gitlab-ci.yml projet :

publish-docker-prod:
  after_script:
    - trivy image "${CI_REGISTRY_IMAGE}:${RELEASE_VERSION}"

extends: n'est pas nécessaire — le job existe déjà, on l'enrichit directement.

Notes

• Les deux jobs ne tournent jamais ensemble : les rules: sont mutuellement exclusifs (un commit ne peut pas être à la fois …-staging.N et X.Y.Z nu).
• expire_in: never sur les badges est volontaire. Voir release-badges pour le détail.
• Pas de cache cross-job sur le build : les runners Spektrum n'utilisent pas BuildKit + cache distribué. Si c'est un goulot, c'est un sujet séparé.

Voir aussi

• release-detect — si le projet a aussi des jobs aval déclenchés par le tag push (déploiement K8s, etc.).
• ../setup.md — variables CI/CD et settings runner.
• ../troubleshooting.md — si le push échoue.

Contributors

No contributors

Changelog

No recent changes