release-badges

Génère les badges SVG de version (prod.svg, staging.svg) après une release et les expose comme artefact non-expirant pour que le README.md du projet puisse les afficher via une URL stable.

Délègue à npx @spektrum/release-util@latest badges --out badges, qui lit les derniers tags X.Y.Z et X.Y.Z-staging.N et produit deux SVGs.

Snippet d'include

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

stages:
  - tag

Combiné avec release-tag dans le même pipeline :

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

stages:
  - tag

Inputs

Input	Requis	Défaut	Description
stage	non	tag	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

Identique à release-tag :

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

URL stable des badges

L'artefact est exposé à :

https://gitlab.internal.spektrum-suisse.ch/<group>/<project>/-/jobs/artifacts/<default-branch>/raw/badges/<file>.svg?job=release-badges

À ajouter en Project Badges (Settings → General → Badges) ou directement dans le README.md du projet :

![staging](https://gitlab.internal.spektrum-suisse.ch/<group>/<project>/-/jobs/artifacts/main/raw/badges/staging.svg?job=release-badges)
![prod](https://gitlab.internal.spektrum-suisse.ch/<group>/<project>/-/jobs/artifacts/main/raw/badges/prod.svg?job=release-badges)

Remplacer main par la branche par défaut du projet.

Dépendance release-tag

Le composant déclare :

needs:
  - job: release-tag
    optional: true

C'est-à-dire : si release-tag existe dans le pipeline, attendre qu'il finisse (pour que le tag fraîchement poussé soit lisible). Sinon, ne pas bloquer. Compatible avec les deux cas : projet qui utilise les deux composants, et projet qui pousse les tags autrement.

Notes

• expire_in: never est volontaire. C'est ce qui rend l'URL stable d'une release à l'autre. Ne pas le réduire — sinon les badges du README finissent en 404 après quelques semaines.
• Le job s'exécute aussi sur les commits Merge branch 'release/…' (cas où GitLab synthétise un merge commit). Si tu veux strictement limiter aux commits chore(release):, surcharge rules: côté projet.

Voir aussi

• release-tag — généralement utilisé en combinaison.
• publish-docker — alternative qui intègre déjà cette logique (ne pas combiner avec release-badges).
• ../setup.md — pour configurer les badges au niveau projet GitLab.

Contributors

No contributors

Changelog

No recent changes