nemoclaw-maintainer-cut-release-tag

Par nvidia · skills

Créer une nouvelle release semver — incrémente toutes les chaînes de version via `bump-version.ts`, ouvre une release PR, puis après fusion tag `main` et pousse. À utiliser lors de la création d'une release, du tagging d'une version, de l'expédition d'un build ou de la préparation d'un déploiement. Mots-clés déclencheurs : cut tag, release tag, new tag, cut release, tag version, ship it.

npx skills add https://github.com/nvidia/skills --skill nemoclaw-maintainer-cut-release-tag

Créer une étiquette de version

Mettre à jour toutes les chaînes de version, ouvrir une PR de version, et après fusion créer des étiquettes annotées semver et latest sur origin/main.

Cette skill délègue le travail de mise à jour de version à scripts/bump-version.ts (invoqué via npm run bump:version). Ce script met à jour package.json (racine + plugin), blueprint.yaml, les valeurs par défaut du programme d'installation, la configuration de la documentation et les liens de documentation versionnés — puis exécute la compilation et les tests avant d'ouvrir une PR.

Conditions préalables

  • Vous devez être dans le dépôt git NemoClaw.
  • Vous devez avoir accès en écriture à origin (NVIDIA/NemoClaw).
  • La suite E2E nightly devrait avoir réussi avant la création de l'étiquette. Vérifiez auprès de l'utilisateur en cas de doute.

Étape 1 : Déterminer la version actuelle

Récupérez toutes les étiquettes et trouvez la dernière étiquette semver :

git fetch origin --tags
git tag --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -1

Extrayez les composantes majeure, mineure et de patch de cette étiquette.

Étape 2 : Demander à l'utilisateur quel type de mise à jour

Présentez les options avec la mise à jour de patch par défaut :

  • Patch (par défaut) : vX.Y.(Z+1) — corrections de bugs, petites modifications
  • Minor : vX.(Y+1).0 — nouvelles fonctionnalités, modifications plus importantes
  • Major : v(X+1).0.0 — changements qui cassent la compatibilité

Affichez les chaînes de version concrètes. Exemple d'invite :

Étiquette actuelle : v0.0.2

Quel type de mise à jour ?

  1. Patchv0.0.3 (par défaut)
  2. Minorv0.1.0
  3. Majorv1.0.0

Attendez la confirmation de l'utilisateur avant de procéder. S'il dit simplement « oui », « go », « fais-le » ou similaire, utilisez la valeur par défaut patch.

Étape 3 : Afficher ce qui va être étiqueté

Montrez à l'utilisateur le commit qui sera étiqueté et l'historique des modifications depuis la dernière étiquette :

git log --oneline origin/main -1
git log --oneline <previous-tag>..origin/main

Demandez une confirmation avant de procéder.

Étape 4 : Exécuter le script de mise à jour de version

D'abord, prévisualisez le plan avec --dry-run :

npm run bump:version -- <version-without-v-prefix> --dry-run

Affichez la sortie du dry-run à l'utilisateur. Après confirmation, demandez à l'utilisateur le mode qu'il souhaite :

Option A : Mode PR (par défaut, recommandé)

npm run bump:version -- <version-without-v-prefix>

Cela va :

  1. Mettre à jour toutes les chaînes de version dans le dépôt
  2. Exécuter la compilation et les tests
  3. Créer une branche release/<version> et ouvrir une PR de version contre main

En mode PR, la création d'étiquette est reportée — procédez à l'étape 5 après la fusion de la PR.

Option B : Mode direct (sans PR)

npm run bump:version -- <version-without-v-prefix> --no-create-pr --push

Cela va :

  1. Mettre à jour toutes les chaînes de version dans le dépôt
  2. Exécuter la compilation et les tests
  3. Commiter directement sur main
  4. Créer les étiquettes annotées v<version> et latest
  5. Pousser le commit et les deux étiquettes vers origin

En mode direct, la création d'étiquette et la poussée sont gérées par le script — passez à l'étape 6.

Si l'utilisateur souhaite ignorer les tests (par exemple, parce qu'il les a déjà exécutés), ajoutez --skip-tests à l'un ou l'autre mode.

Étape 5 : Créer et pousser les étiquettes (mode PR uniquement, après la fusion de la PR)

Ignorer cette étape si vous avez utilisé le mode direct à l'étape 4 — le script a déjà créé l'étiquette et poussé.

Une fois que la PR de version est fusionnée dans main, créez l'étiquette annotée, déplacez latest et poussez :

git fetch origin main --tags
git tag -a <new-version> origin/main -m "<new-version>"

# Déplacer l'étiquette latest (supprimer l'ancienne, créer la nouvelle)
git tag -d latest 2>/dev/null || true
git tag -a latest origin/main -m "latest"

# Pousser les deux étiquettes (force-push latest puisqu'elle se déplace)
git push origin <new-version>
git push origin latest --force

Étape 6 : Vérifier

git ls-remote --tags origin | grep -E '(<new-version>|latest)'

Confirmez que les deux étiquettes pointent vers le même commit sur le dépôt distant.

Notes importantes

  • NE JAMAIS créer d'étiquette sans confirmation explicite de l'utilisateur sur la version.
  • NE JAMAIS créer d'étiquette sur une branche autre que origin/main.
  • Toujours utiliser des étiquettes annotées (-a), pas des étiquettes légères.
  • L'étiquette latest est une étiquette flottante qui pointe toujours vers la version la plus récente — elle nécessite --force pour être poussée.
  • La chaîne de version passée à npm run bump:version ne doit PAS avoir de préfixe v (par exemple, 0.0.3, pas v0.0.3). Le script ajoute le préfixe v en interne pour les étiquettes.

Skills similaires