release-detect

S'exécute sur un push de tag de release et écrit un fichier release.env exposé comme dotenv report GitLab. Les jobs aval qui le consomment via needs reçoivent les variables VERSION, CHANNEL et RELEASE_TYPE dans leur environnement sans les recalculer eux-mêmes.

C'est le pendant côté pipeline-de-tag de release-tag : release-tag pousse le tag → le tag déclenche un nouveau pipeline → release-detect y publie les métadonnées sémantiques.

Snippet d'include

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

stages:
  - detect
  - build
  - release

Inputs

Input	Requis	Défaut	Description
stage	non	detect	Stage du job.
image	non	node:lts-alpine	Image utilisée. Doit fournir npm/npx.
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_TAG =~ /^[0-9]+\.[0-9]+\.[0-9]+(-staging\.[0-9]+)?$/

Match strict : pas de préfixe v, format Capgo-compatible (MAJOR.MINOR.PATCH[-staging.N]). Si le projet utilise un autre schéma de tags (v1.2.3, tags datés…), ce composant n'est pas adapté.

Variables émises dans release.env

Variable	Valeurs
VERSION	X.Y.Z ou X.Y.Z-staging.N
CHANNEL	production ou staging
RELEASE_TYPE	major, minor, patch

Consommation depuis un job aval

my-downstream-job:
  stage: build
  needs:
    - job: release-detect
      artifacts: true
  rules:
    - if: $CI_COMMIT_TAG =~ /^[0-9]+\.[0-9]+\.[0-9]+(-staging\.[0-9]+)?$/
  script:
    - echo "Building $VERSION for $CHANNEL (type=$RELEASE_TYPE)"

artifacts: true dans needs: est obligatoire : sans ça, GitLab attend release-detect mais ne charge pas son dotenv.

⚠️ Limitation GitLab : RELEASE_TYPE ne peut pas gater rules:

Les rules: GitLab sont évaluées à la création du pipeline, avant que release-detect ne tourne. Donc RELEASE_TYPE (ainsi que VERSION, CHANNEL) ne peut pas être utilisé dans rules:.

Pattern à utiliser : gater le rules: sur ce qui est déjà connu (typiquement le format du $CI_COMMIT_TAG), et court-circuiter en début de script: :

major-only-job:
  rules:
    - if: $CI_COMMIT_TAG =~ /^[0-9]+\.[0-9]+\.[0-9]+(-staging\.[0-9]+)?$/
  needs:
    - job: release-detect
      artifacts: true
  script:
    - |
      if [ "$RELEASE_TYPE" != "major" ]; then
        echo "Skip — RELEASE_TYPE=$RELEASE_TYPE"
        exit 0
      fi
    # … vrai travail

Le runtime gate court-circuite proprement. Le job apparaît comme success dans GitLab dans tous les cas — c'est l'idiome standard.

Notes

• expire_in: 1 week suffit largement : les jobs aval consomment le dotenv dans la même heure que sa création.
• Ne pas confondre avec release-tag : release-tag tourne sur trunk et pousse un tag ; release-detect tourne sur le pipeline du tag que release-tag vient de pousser.

Cas d'usage typiques

• Capgo OTA upload : needs release-detect, lit VERSION et CHANNEL, appelle npx @capgo/cli bundle upload --apikey "$CAPGO_TOKEN" --channel "$CHANNEL" --bundle "$VERSION".
• Native mobile build (Fastlane) : needs release-detect, court-circuite si RELEASE_TYPE != "major", sinon bump capacitor.config.ts + pbxproj / build.gradle à $VERSION, build, ship.
• Déploiement K8s gated : needs release-detect, déploie l'image ${REGISTRY}/${IMAGE}:${VERSION} sur le cluster correspondant à $CHANNEL.

Voir aussi

• release-tag — pousse le tag qui déclenche le pipeline dans lequel release-detect tourne.
• ../troubleshooting.md — si les variables n'arrivent pas dans le job aval.

Contributors

No contributors

Changelog

No recent changes