release-tag

Pousse le tag annoté X.Y.Z (ou X.Y.Z-staging.N) sur la branche par défaut, après qu'un commit chore(release): … (ou un merge commit Merge branch 'release/…') y atterrit. Délègue tout le travail à npx @spektrum/release-util@latest tag.

Snippet d'include

include:
  - component: $CI_SERVER_FQDN/spektrum/ci-templates/release-tag@<version>
    inputs:
      stage: tag

stages:
  - tag

Remplacer <version> par un tag git du repo spektrum/ci-templates (ex. 1.2.0).

Inputs

Input	Requis	Défaut	Description
stage	non	tag	Stage du job.
image	non	node:lts-alpine	Image utilisée. Doit fournir npm/npx. Le job installe git via apk si l'image est Alpine — si tu changes pour une base non-Alpine, surcharge le before_script.
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. Sans ça, npx interroge registry.npmjs.org et reçoit un 404 puisque @spektrum/release-util n'y est pas publié.

Trigger

$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
&& ($CI_COMMIT_TITLE =~ /^chore\(release\):/
    || $CI_COMMIT_TITLE =~ /^Merge.*release\//)

Le job ne s'exécute que sur la branche par défaut et seulement si le titre du commit correspond à un commit de release (fast-forward chore(release): ou merge commit synthétisé par GitLab Merge branch 'release/…').

Pré-requis

• Variable CI/CD RELEASE_TOKEN (Protected + Masked) avec scope write_repository. Voir ../setup.md.
• Squash merge désactivé pour les MR release/* (../setup.md).
• Branche par défaut et tags protégés (../setup.md).

Variables exportées dans le job courant

release-util tag exporte dans l'environnement du job pendant sa seconde moitié :

Variable	Valeurs
RELEASE_VERSION	X.Y.Z ou X.Y.Z-staging.N
RELEASE_ENV	prod ou staging
RELEASE_TAG	identique à RELEASE_VERSION

⚠️ Ces variables ne sont pas disponibles dans les jobs aval. Pour ça, utiliser release-detect, qui les ré-émet en dotenv après le push du tag.

Notes

• Le tag déclenché crée un nouveau pipeline. Les jobs gated sur $CI_COMMIT_TAG tournent dans ce nouveau pipeline, pas dans le pipeline trunk qui contient le release-tag job.
• Idempotent. Re-jouer le job sur un commit où le tag existe déjà ne fait rien.
• GIT_DEPTH: "0" est imposé par le job : release-util doit lire l'historique pour calculer l'incrément -staging.N.

Voir aussi

• release-badges — généralement utilisé en combinaison.
• release-detect — pour exposer les variables au pipeline de tag suivant.
• publish-docker — alternative qui intègre déjà release-tag (ne pas combiner).

Contributors

No contributors

Changelog

No recent changes