release please Télécharger - release please Téléchargement du code source

release please

Autre code source

v16.15.0

Télécharger

Libérez s'il vous plaît

Release Please automatise la génération CHANGELOG, la création de versions GitHub et les changements de version pour vos projets.

Pour ce faire, il analyse votre historique git, recherche les messages de validation conventionnelle et crée des PR de version.

Il ne gère pas la publication vers les gestionnaires de packages ni la gestion complexe des branches.

Qu'est-ce qu'un Release PR ?

Plutôt que de publier continuellement ce qui arrive dans votre branche par défaut, release-please maintient les Release PR :

Ces versions PR sont tenues à jour à mesure que des travaux supplémentaires sont fusionnés. Lorsque vous êtes prêt à baliser une version, fusionnez simplement le PR de la version. Les commits de fusion et de fusion fonctionnent avec les Release PR.

Lorsque la Release PR est fusionnée, release-please suit les étapes suivantes :

Met à jour votre fichier journal des modifications (par exemple CHANGELOG.md ), ainsi que d'autres fichiers spécifiques à une langue (par exemple package.json ).
Marque le commit avec le numéro de version
Crée une version GitHub basée sur la balise

Vous pouvez savoir où se trouve la version PR dans son cycle de vie grâce à l'étiquette d'état sur la PR elle-même :

autorelease: pending est l'état initial du Release PR avant sa fusion
autorelease: tagged signifie que la version PR a été fusionnée et que la version a été balisée dans GitHub
autorelease: snapshot est un état spécial pour les modifications de version d'instantané
autorelease: published signifie qu'une version de GitHub a été publiée sur la base du Release PR ( release-please n'ajoute pas automatiquement cette balise, mais nous la recommandons comme convention pour les outils de publication ).

Comment dois-je rédiger mes commits ?

Release Please suppose que vous utilisez des messages de validation conventionnels.

Les préfixes les plus importants à garder à l’esprit sont :

fix: qui représente des corrections de bogues et est en corrélation avec un correctif SemVer.
feat: qui représente une nouvelle fonctionnalité et est en corrélation avec un mineur SemVer.
feat!: , ou fix!: , refactor!: , etc., qui représentent un changement radical (indiqué par le ! ) et entraîneront un SemVer majeur.

Historique des commits git linéaires (utilisez squash-merge)

Nous vous recommandons fortement d'utiliser des fusions par squash lors de la fusion de demandes d'extraction. Un historique git linéaire facilite grandement :

Suivre l'historique - les commits sont triés par date de fusion et ne sont pas mélangés entre les demandes d'extraction
Rechercher et annuler les bugs - git bisect est utile pour déterminer quel changement a introduit un bug
Contrôlez le journal des modifications de la version s'il vous plaît - lorsque vous fusionnez un PR, vous pouvez avoir des messages de validation qui ont du sens dans le cadre du PR, mais qui n'ont pas de sens lorsqu'ils sont fusionnés dans la branche principale. Par exemple, vous pouvez avoir feat: introduce feature A puis fix: some bugfix introduced in the first commit . La validation fix n'est en fait pas pertinente pour les notes de version car aucun bug n'a été rencontré dans la branche principale.
Gardez une branche principale propre - si vous utilisez quelque chose comme le développement rouge/vert (créez un test échoué dans le commit A, puis corrigez-le dans le commit B) et fusionnez (ou rebase-fusionnez), alors il y aura des moments dans votre branche principale où les tests ne réussissent pas.

Que se passe-t-il si mon PR contient plusieurs correctifs ou fonctionnalités ?

Release Please vous permet de représenter plusieurs modifications dans un seul commit, à l'aide de pieds de page :

 exploit : ajoute l'UUID v4 à la cryptographie

Cela ajoute la prise en charge des UUID v4 à la bibliothèque.

fix (utils) : Unicode ne lève plus d'exception
  PiperOrigin-RevId : 345559154
  RUPTURE-CHANGEMENT : la méthode d'encodage ne lance plus.
  Lien source : googleapis/googleapis@5e0dcb2

feat(utils) : mettre à jour l'encodage pour prendre en charge Unicode
  PiperOrigin-RevId : 345559182
  Lien source : googleapis/googleapis@e5eef86

Le message de validation ci-dessus contiendra :

une entrée pour la fonctionnalité "ajoute l'UUID v4 au crypto" .
une entrée pour le correctif "Unicode ne génère plus d'exception" , accompagnée d'une note indiquant qu'il s'agit d'un changement radical.
une entrée pour la fonctionnalité "mettre à jour l'encodage pour prendre en charge Unicode" .

️ Important : Les messages supplémentaires doivent être ajoutés au bas du commit.

Comment changer le numéro de version ?

Lorsqu'un commit dans la branche principale a Release-As: xxx (insensible à la casse) dans le corps du commit , Release Please ouvrira une nouvelle pull request pour la version spécifiée.

Exemple de commit vide :

git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" donne le message de validation suivant :

 corvée : version 2.0.0

Version en tant que : 2.0.0

Comment puis-je corriger les notes de version ?

Si vous avez fusionné une pull request et souhaitez modifier le message de validation utilisé pour générer les notes de version pour cette validation, vous pouvez modifier le corps des pull request fusionnées et ajouter une section comme :

BEGIN_COMMIT_OVERRIDE
feat: add ability to override merged commit message

fix: another message
chore: a third message
END_COMMIT_OVERRIDE

La prochaine fois que Release Please s'exécutera, il utilisera cette section de remplacement comme message de validation au lieu du message de validation fusionné.

️ Important : Cette fonctionnalité ne fonctionnera pas avec les fusions simples car release-please ne sait pas à quel(s) commit(s) appliquer le remplacement. Nous vous recommandons plutôt d'utiliser squash-merge.

Le bot Release Please ne crée pas de PR de version. Pourquoi?

Étape 1 : Assurez-vous que les unités libérables sont fusionnées

Release Please crée une demande d'extraction de version après avoir remarqué que la branche par défaut contient des « unités libérables » depuis la dernière version. Une unité libérable est un commit dans la branche avec l'un des préfixes suivants : "feat", "fix" et "deps". (Un commit « corvée » ou « build » n’est pas une unité libérable.)

Certaines langues ont leur configuration d'unité libérable spécifique. Par exemple, « docs » est un préfixe pour les unités publiables en Java et Python.

Étape 2 : Assurez-vous qu'il n'y a pas `autorelease: pending` ou `autorelease: triggered` dans un ancien PR

Vérifiez les demandes d'extraction existantes étiquetées avec autorelease: pending ou autorelease: triggered . En raison d'échecs de l'API GitHub, il est possible que la balise n'ait pas été supprimée correctement lors d'une version précédente et Release Please pense que la version précédente est toujours en attente. Si vous êtes certain qu’il n’y a pas de version en attente, supprimez l’étiquette autorelease: pending ou autorelease: triggered .

Pour les utilisateurs de l'application GitHub, Release Please ne créera pas de nouvelle demande d'extraction s'il existe une demande d'extraction existante étiquetée comme autorelease: pending . Pour confirmer ce cas, recherchez une pull request avec l’étiquette. (Il est très probable qu'il s'agisse de la dernière demande d'extraction de version.) Si vous trouvez une demande d'extraction de version avec l'étiquette et qu'elle ne sera pas publiée (ou déjà publiée), supprimez l'étiquette autorelease: pending et réexécutez Release Please.

Étape 3 : Réexécutez la version s'il vous plaît

Si vous pensez que Release Please a manqué la création d'un PR de version après la fusion d'une demande d'extraction avec une unité publiable, veuillez réexécuter release-please . Si vous utilisez l'application GitHub, ajoutez l'étiquette release-please:force-run à la demande d'extraction fusionnée. Si vous utilisez l'action, recherchez l'appel ayant échoué et réessayez l'exécution du flux de travail. Release Please traitera immédiatement la pull request pour trouver des unités libérables.

Types de stratégie (langage) pris en charge

Release Please automatise les versions pour les versions de référentiels suivantes :

type de version	description
`bazel`	Un module Bazel, avec un MODULE.bazel et un CHANGELOG.md
`dart`	Un dépôt avec un pubspec.yaml et un CHANGELOG.md
`elixir`	Un dépôt avec un mix.exs et un CHANGELOG.md
`go`	Un référentiel avec un CHANGELOG.md
`helm`	Un dépôt avec un Chart.yaml et un CHANGELOG.md
`java`	Une stratégie qui génère une version SNAPSHOT après chaque version
`krm-blueprint`	Un package kpt, avec 1 ou plusieurs fichiers KRM et un CHANGELOG.md
`maven`	Stratégie pour les projets Maven, génère une version SNAPSHOT après chaque version et met automatiquement à jour `pom.xml`
`node`	Un dépôt Node.js, avec un package.json et CHANGELOG.md
`expo`	Un référentiel React Native basé sur Expo, avec un package.json, app.json et CHANGELOG.md
`ocaml`	Un référentiel OCaml, contenant 1 ou plusieurs fichiers opam ou esy et un CHANGELOG.md
`php`	Un dépôt avec un composer.json et un CHANGELOG.md
`python`	Un référentiel Python, avec un setup.py, setup.cfg, CHANGELOG.md et éventuellement un pyproject.toml et un <project>/__init__.py
`ruby`	Un dépôt avec une version.rb et un CHANGELOG.md
`rust`	Un référentiel Rust, avec un Cargo.toml (soit sous forme de caisse ou d'espace de travail, mais notez que les espaces de travail nécessitent une version pilotée par manifeste et le plugin "cargo-workspace") et un CHANGELOG.md
`sfdx`	Un référentiel avec un sfdx-project.json et un CHANGELOG.md
`simple`	Un dépôt avec un version.txt et un CHANGELOG.md
`terraform-module`	Un module Terraform, avec une version dans le README.md, et un CHANGELOG.md

Configuration de la version s'il vous plaît

Il existe différentes manières de déployer la version :

Action GitHub (recommandée)

Le moyen le plus simple d’exécuter Release Please consiste à utiliser une action GitHub. Veuillez consulter googleapis/release-please-action pour les instructions d'installation et de configuration.

Exécuté en tant que CLI

Veuillez consulter la version en cours d'exécution-veuillez CLI pour toutes les options de configuration.

Installez l'application GitHub

Une application probot est disponible, qui vous permet de déployer Release Please en tant qu'application GitHub. Veuillez consulter github.com/googleapis/repo-automation-bots pour les instructions d'installation et de configuration.

Amorcer votre référentiel

Release Please examine les commits depuis votre dernière balise de version. Il se peut ou non qu’il soit en mesure de retrouver vos versions précédentes. Le moyen le plus simple d'intégrer votre référentiel consiste à amorcer une configuration de manifeste.

Personnalisation de la version s'il vous plaît

Release Please fournit plusieurs options de configuration pour permettre de personnaliser votre processus de publication. Veuillez consulter customizing.md pour plus de détails.

Prise en charge de Monorepos via la configuration du manifeste

Release Please prend également en charge la publication de plusieurs artefacts à partir du même référentiel. Pour en savoir plus, consultez manifest-releaser.md.

Versions Node.js prises en charge

Nos bibliothèques client suivent le calendrier de publication de Node.js. Les bibliothèques sont compatibles avec toutes les versions actives et de maintenance actuelles de Node.js.

Des bibliothèques clientes ciblant certaines versions en fin de vie de Node.js sont disponibles et peuvent être installées via les balises npm dist. Les balises dist suivent la convention de dénomination legacy-(version) .

Les anciennes versions de Node.js sont prises en charge dans la mesure du possible :

Les versions existantes ne seront pas testées en intégration continue.
Certains correctifs de sécurité peuvent ne pas pouvoir être rétroportés.
Les dépendances ne seront pas maintenues à jour et les fonctionnalités ne seront pas rétroportées.