Page d'accueil>Lié à la programmation>Autre code source
Télécharger

@semantic-release/gitlab

plugin de publication sémantique pour publier une version de GitLab.

Étape Description
verifyConditions Vérifier la présence et la validité de l'authentification (définie via des variables d'environnement).
publish Publiez une version de GitLab.
success Ajoutez un commentaire à chaque problème GitLab ou demande de fusion résolu par la version.
fail Ouvrez ou mettez à jour un problème GitLab avec des informations sur les erreurs qui ont provoqué l'échec de la version.

Installer 

$ npm install @semantic-release/gitlab -D

Usage

Le plugin peut être configuré dans le fichier de configuration de la version sémantique : 

{
  "branches" : [ " main " ],
  "plugins" : [
    " @semantic-release/commit-analyzer " ,
    " @semantic-release/release-notes-generator " ,
    [
      " @semantic-release/gitlab " ,
      {
        "gitlabUrl" : " https://custom.gitlab.com " ,
        "assets" : [
          { "path" : " dist/asset.min.css " , "label" : " CSS distribution " },
          { "path" : " dist/asset.min.js " , "label" : " JS distribution " , "target" : " generic_package " },
          { "path" : " dist/asset.min.js " , "label" : " v${nextRelease.version}.js " },
          { "url" : " https://gitlab.com/gitlab-org/gitlab/-/blob/master/README.md " }
        ]
      }
    ]
  ]
}

Avec cet exemple, les versions de GitLab seront publiées sur l'instance https://custom.gitlab.com .

Configuration

Authentification GitLab

La configuration de l'authentification GitLab est requise et peut être définie via des variables d'environnement.

Créez un jeton d'accès au projet, un jeton d'accès de groupe ou un jeton d'accès personnel avec le rôle Développeur (ou supérieur) et la portée api et rendez-le disponible dans votre environnement CI via la variable d'environnement GL_TOKEN . Si vous utilisez GL_TOKEN comme authentification du référentiel Git distant, il doit également avoir la portée write_repository .

Remarque : lors de l'exécution avec dryRun seule la portée read_repository est requise.

Variables d'environnement

Variable Description
GL_TOKEN ou GITLAB_TOKEN Requis. Le jeton utilisé pour s'authentifier auprès de GitLab.
GL_URL ou GITLAB_URL Le point de terminaison GitLab.
GL_PREFIX ou GITLAB_PREFIX Le préfixe de l'API GitLab.
HTTP_PROXY ou HTTPS_PROXY Proxy HTTP ou HTTPS à utiliser.
NO_PROXY Modèles pour lesquels le proxy doit être ignoré. Voir les détails ci-dessous.

Configuration du proxy

Le plugin prend en charge la transmission des requêtes via un serveur proxy.

Vous pouvez configurer un serveur proxy via la variable d'environnement HTTPS_PROXY : HTTPS_PROXY=http://proxyurl.com:8080

Si votre serveur proxy nécessite une authentification, intégrez le nom d'utilisateur et le mot de passe dans l'URL : HTTPS_PROXY=http://user:[email protected]:8080

Si votre instance GitLab est exposée via HTTP simple (non recommandé !), utilisez plutôt HTTP_PROXY .

Si vous devez contourner le proxy pour certains hôtes, configurez la variable d'environnement NO_PROXY : NO_PROXY=*.host.com, host.com

Possibilités

Option Description Défaut
gitlabUrl Le point de terminaison GitLab. Variable d'environnement GL_URL ou GITLAB_URL ou variables d'environnement fournies par CI si elles sont exécutées sur GitLab CI/CD ou https://gitlab.com .
gitlabApiPathPrefix Le préfixe de l'API GitLab. Variable d'environnement GL_PREFIX ou GITLAB_PREFIX ou variables d'environnement fournies par CI si elles sont exécutées sur GitLab CI/CD ou /api/v4 .
assets Un tableau de fichiers à télécharger vers la version. Voir les actifs. -
milestones Un éventail de titres marquants à associer à la version. Voir API de version GitLab. -
successComment Le commentaire à ajouter à chaque problème et demande de fusion résolus par la version. Voir successComment. ? Ce problème a été résolu dans la version ${nextRelease.version} ?nnLa version est disponible sur la version GitLab
successCommentCondition Utilisez-le comme condition pour commenter des problèmes ou des demandes de fusion. Voir successCommentCondition. -
failComment Le contenu du problème créé lors de l'échec d'une version. Voir failComment. Message convivial avec des liens vers la documentation et le support de la version sémantique , avec la liste des erreurs qui ont provoqué l'échec de la version.
failTitle Le titre du problème créé lors de l'échec d'une version. The automated release is failing
failCommentCondition Utilisez-le comme condition pour savoir quand commenter ou créer un problème en cas d'échec. Voir failCommentCondition. -
labels Les étiquettes à ajouter au problème créé en cas d'échec d'une version. Définissez sur false pour n’ajouter aucune étiquette. Les étiquettes doivent être séparées par des virgules comme décrit dans la documentation officielle, par exemple "semantic-release,bot" . semantic-release
assignee Responsable à ajouter au problème créé en cas d'échec d'une version. -

actifs

Peut être un glob ou Array of globs et Object avec les propriétés suivantes :

Propriété Description Défaut
path Obligatoire , sauf si url est définie. Un glob pour identifier les fichiers à télécharger. Prend en charge les modèles Lodash. -
url Alternative au path de définition, cela offre la possibilité d'ajouter des liens vers des versions, par exemple des URL vers des images de conteneurs. Prend en charge les modèles Lodash. -
label Brève description du fichier affiché sur la version GitLab. Ignoré si path correspond à plusieurs fichiers. Prend en charge les modèles Lodash. Nom du fichier extrait du path .
type Type d'actif affiché sur la version GitLab. Peut être runbook , package , image et other (voir les documents officiels sur les ressources de version). Prend en charge les modèles Lodash. other
filepath Un chemin de fichier pour créer un lien permanent pointant vers l'actif (nécessite GitLab 12.9+, voir les documents officiels sur les liens permanents). Ignoré si path correspond à plusieurs fichiers. Prend en charge les modèles Lodash. -
target Contrôle l'endroit où le fichier est téléchargé. Peut être défini sur project_upload pour stocker le fichier en tant que téléchargement de projet ou generic_package pour stocker le fichier en tant que package générique. project_upload
status Ceci n'est appliqué que si target est défini sur generic_package . L’état du package générique. Peut être default et hidden (voir les documents officiels sur les packages génériques). default

Chaque entrée du Array assets est regroupée individuellement. Un glob peut être un String ( "dist/**/*.js" ou "dist/mylib.js" ) ou un Array of String s qui seront regroupés ensemble ( ["dist/**", "!**/*.css"] ).

Si un répertoire est configuré, tous les fichiers de ce répertoire et ses enfants seront inclus.

Remarque : Si un fichier a une correspondance dans assets il sera inclus même s'il a également une correspondance dans .gitignore .

exemples d'actifs

'dist/*.js' : inclut tous les fichiers js dans le répertoire dist , mais pas dans ses sous-répertoires.

[['dist', '!**/*.css']] : inclut tous les fichiers du répertoire dist et ses sous-répertoires à l'exclusion des fichiers css .

[{path: 'dist/MyLibrary.js', label: 'MyLibrary JS distribution'}, {path: 'dist/MyLibrary.css', label: 'MyLibrary CSS distribution'}] : inclut le dist/MyLibrary.js et dist/MyLibrary.css et étiquetez-les MyLibrary JS distribution et MyLibrary CSS distribution dans la version GitLab.

[['dist/**/*.{js,css}', '!**/*.min.*'], {path: 'build/MyLibrary.zip', label: 'MyLibrary'}] : inclure tous les fichiers js et css du répertoire dist et de ses sous-répertoires à l'exclusion de la version minifiée, plus le fichier build/MyLibrary.zip et étiquetez- MyLibrary dans la version GitLab.

succèsCommentaire

Le message pour les commentaires sur le problème est généré avec le modèle Lodash. Les variables suivantes sont disponibles :

Paramètre Description
branch Object avec les propriétés name , type , channel , range et prerelease de la branche à partir de laquelle la version est effectuée.
lastRelease Object avec version , channel , gitTag et gitHead de la dernière version.
nextRelease Object avec version , channel , gitTag , gitHead et notes de la version en cours de réalisation.
commits Array d' Object de validation avec hash , subject , body message et author .
releases Array avec une version Object s pour chaque version publiée, avec des données de version facultatives telles que name et url .
issue Un objet de problème d'API GitLab sur lequel le commentaire sera publié, ou false lors du commentaire des demandes de fusion.
mergeRequest Un objet de demande de fusion d'API GitLab sur lequel le commentaire sera publié, ou false lors du commentaire des problèmes.

succèsCommentaireCondition

La condition de commentaire de réussite est générée avec le modèle Lodash. Les variables suivantes sont disponibles :

Paramètre Description
branch Object avec les propriétés name , type , channel , range et prerelease de la branche à partir de laquelle la version est effectuée.
lastRelease Object avec version , channel , gitTag et gitHead de la dernière version.
nextRelease Object avec version , channel , gitTag , gitHead et notes de la version en cours de réalisation.
commits Array d' Object de validation avec hash , subject , body message et author .
releases Array avec une version Object s pour chaque version publiée, avec des données de version facultatives telles que name et url .
issue Un objet GitLab API Issue sur lequel le commentaire sera publié.
mergeRequest Un objet de demande de fusion d'API GitLab sur lequel le commentaire sera publié.
Exemple de successCommentCondition
  • ne créez aucun commentaire : définissez-le sur false ou créez un modèle : "<% return false; %>"
  • pour commenter uniquement les problèmes : "<% return issue %>"
  • pour commenter uniquement les demandes de fusion : "<% return mergeRequest %>"
  • vous pouvez utiliser des étiquettes pour filtrer les problèmes : "<% return issue.labels?.includes('semantic-release-relevant') %>"

vérifiez l'objet GitLab API Merge Request ou l'objet GitLab API Issue pour les propriétés qui peuvent être utilisées pour le filtre

failComment

Le message pour le contenu du problème est généré avec le modèle Lodash. Les variables suivantes sont disponibles :

Paramètre Description
branch Branche à partir de laquelle la version a échoué.
errors Un Array de SemanticReleaseError. Chaque erreur a les propriétés message , code , pluginName et details .
pluginName contient le nom du package du plugin qui a généré l'erreur.
details contiennent des informations sur l’erreur formatées en markdown.
Exemple de commentaire d'échec

Le failComment This release from branch ${branch.name} had failed due to the following errors:n- ${errors.map(err => err.message).join('\n- ')} générera le commentaire:

Cette version de la branche principale a échoué en raison des erreurs suivantes :

  • Message d'erreur 1
  • Message d'erreur 2

failCommentCondition

La condition de commentaire d'échec est générée avec le modèle Lodash. Les variables suivantes sont disponibles :

Paramètre Description
branch Object avec les propriétés name , type , channel , range et prerelease de la branche à partir de laquelle la version est effectuée.
lastRelease Object avec version , channel , gitTag et gitHead de la dernière version.
nextRelease Object avec version , channel , gitTag , gitHead et notes de la version en cours de réalisation.
commits Array d' Object de validation avec hash , subject , body message et author .
releases Array avec une version Object s pour chaque version publiée, avec des données de version facultatives telles que name et url .
issue Un objet Issue de l'API GitLab sur lequel le commentaire sera publié - disponible uniquement s'il existe un problème ouvert.
Exemple d'échecCommentCondition
  • ne créez aucun commentaire : définissez-le sur false ou créez un modèle : "<% return false; %>"
  • pour commenter uniquement la branche principale : "<% return branch.name === 'main' %>"
  • vous pouvez utiliser des étiquettes pour filtrer les problèmes, c'est-à-dire pour ne pas commenter si le problème est étiqueté avec wip : "<% return !issue.labels?.includes('wip') %>"

vérifiez l'objet GitLab API Issue pour les propriétés qui peuvent être utilisées pour le filtre

Compatibilité

La dernière version de ce plugin est compatible avec toutes les versions actuellement prises en charge de GitLab, qui sont la version majeure actuelle et les deux versions majeures précédentes. Il n'est pas garanti que ce plugin fonctionne avec les versions non prises en charge de GitLab.

Changements majeurs dans la version 14.0

Si vous utilisez GitLab.com ou avez mis à niveau votre instance GitLab auto-hébergée vers la version 14.0, veuillez utiliser la version >=6.0.7 de ce plugin.

Pourquoi?

Dans GitLab 14.0, la création d'une version à l'aide de l'API Tags a été supprimée (voir # 290311). Ce plugin a été mis à jour pour utiliser l'API Releases à la place dans le numéro 184, qui est disponible dans la version 6.0.7 et au-delà.

Développer
Informations supplémentaires
Applications connexes
Recommandé pour vous
Actualités connexes Tout