SEMANTIC-Release automatise l'ensemble du flux de travail de version du package, y compris: déterminer le numéro de version suivant, générer les notes de version et publier le package.
Cela supprime le lien immédiat entre les émotions humaines et les numéros de version, en suivant strictement la spécification de version sémantique et en communiquant l' impact des changements aux consommateurs.
Faites-nous confiance, cela changera votre flux de travail pour le mieux. - egghead.io
Version entièrement automatisée
Appliquer les spécifications du versioning sémantique
De nouvelles fonctionnalités et correctifs sont immédiatement disponibles pour les utilisateurs
Informer les mainteneurs et les utilisateurs de nouvelles versions
Utiliser la convention de message de validation formalisée pour documenter les modifications de la base de code
Publiez sur différents canaux de distribution (tels que NPM Dist-Tags) basé sur les fusions GIT
Intégrez à votre flux de travail d'intégration continue
Évitez les erreurs potentielles associées aux versions manuelles
Prise en charge de tous les gestionnaires et langues de package via des plugins
Configuration simple et réutilisable via des configurations partageables
Prise en charge de la provenance du package NPM qui favorise une sécurité accrue de la chaîne d'approvisionnement via des attestations signées sur les actions GitHub
SEMANTIS-Release utilise les messages de validation pour déterminer l'impact des consommateurs des modifications dans la base de code. Après les conventions formalisées pour les messages de validation, la libération sémantique détermine automatiquement le prochain numéro de version sémantique, génère un Changelog et publie la version.
Par défaut, Semantic-Release utilise les conventions de messages de validation angulaire. Le format de message de validation peut être modifié avec les options preset
ou config
des plugins @ sémantique-libération / commit-analyzer et @ sémantique-libération / libération des notes-générator.
Des outils tels que Commizen ou Commitlint peuvent être utilisés pour aider les contributeurs et appliquer des messages valides valides.
Le tableau ci-dessous montre quel message de validation vous donne le type de version lorsque la libération semantic-release
(en utilisant la configuration par défaut):
Commettre un message | Type de version |
---|---|
fix(pencil): stop graphite breaking when too much pressure applied | Release de correctif de correctif |
feat(pencil): add 'graphiteWidth' option | Version de fonctionnalité mineure |
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons. | MAJEUR DE RUBÉRATION (Notez que le BREAKING CHANGE: le jeton doit être dans le pied de page du commit) |
La libération sémantique est censée être exécutée sur l'environnement CI après chaque construction réussie sur la branche de libération. De cette façon, aucun humain n'est directement impliqué dans le processus de publication et les sorties sont garanties comme peu romanes et non sentimentales.
Pour chaque nouvel commit ajouté à l'une des branches de version (par exemple: master
, main
, next
, beta
), avec git push
ou en fusionnant une demande de traction ou en fusion d'une autre branche, une construction CI est déclenchée et exécute la semantic-release
Commande pour faire une version s'il y a des modifications de base de code depuis la dernière version qui affectent les fonctionnalités du package.
Semantic Release offre diverses façons de contrôler le calendrier, le contenu et le public des sorties publiées. Voir l'exemple de workflows dans les recettes suivantes:
Utilisation des canaux de distribution
Versions de maintenance
Pré-version
Après avoir exécuté les tests, la Command semantic-release
exécutera les étapes suivantes:
Étape | Description |
---|---|
Vérifier les conditions | Vérifiez toutes les conditions pour procéder à la libération. |
Obtenez la dernière version | Obtenez l'engagement correspondant à la dernière version en analysant les balises GIT. |
Analyser les commits | Déterminez le type de version basé sur les validations ajoutées depuis la dernière version. |
Vérifier la libération | Vérifiez la conformité de la libération. |
Générer des notes | Générez des notes de libération pour les commits ajoutés depuis la dernière version. |
Créer une balise git | Créez une balise GIT correspondant à la nouvelle version de version. |
Préparer | Préparez la libération. |
Publier | Publiez la version. |
Aviser | Informer de nouvelles versions ou erreurs. |
Afin d'utiliser la libération sémantique, vous avez besoin:
Pour héberger votre code dans un référentiel GIT
Utilisez un service d'intégration continue qui vous permet de configurer en toute sécurité les informations d'identification
Une version Git CLI qui répond à nos exigences de version installées dans votre environnement d'intégration continue
Une version Node.js qui répond à notre exigence de version installée dans votre environnement d'intégration continue
Usage
Commencer
Installation
Configuration CI
Configuration
Plugins
Configuration du workflow
Configurations partageables
Extension
Plugins
Configuration partageable
Recettes
Configurations CI
Services hébergés Git
Libérer le flux de travail
Guide du développeur
API JavaScript
Développement des plugins
Développement de configuration partageable
Soutien
Ressources
Questions fréquemment posées
Dépannage
Exigence de version de nœud
Politique de support de nœud
Discussions GitHub
Débordement de pile
Gazouillement
Faites savoir aux gens que votre package est publié à l'aide de la libération sémantique et quel engagement de validation est suivi par l'inclusion de ce badge dans votre lecture.
[! [Semantic-Release: Angular] (https://img.shields.io/badge/semantic-release-angular-e10079?logo=semantic-release)] (https://github.com/semantic-release / Sémantique-libération)
![]() | ![]() | ![]() |
---|---|---|
Gregor Martynus | Pierre Vanduynslager | Matt Travi |
![]() | ![]() | ![]() | ![]() | ![]() |
---|---|---|---|---|
Stephan Bönnemann | Rolf Erik Lekang | Johannes Jörg Schmidt | Finn Pauls | Christoph Witzko |