gitlab Download - gitlab Quellcode herunterladen

gitlab

Anderer Quellcode

v13.2.1

Herunterladen

@semantic-release/gitlab

Semantic-Release- Plugin zum Veröffentlichen einer GitLab-Version.

Schritt	Beschreibung
`verifyConditions`	Überprüfen Sie das Vorhandensein und die Gültigkeit der Authentifizierung (festgelegt über Umgebungsvariablen).
`publish`	Veröffentlichen Sie eine GitLab-Version.
`success`	Fügen Sie zu jedem GitLab-Problem oder jeder Merge-Anfrage, die durch die Veröffentlichung gelöst wurde, einen Kommentar hinzu.
`fail`	Öffnen oder aktualisieren Sie ein GitLab-Problem mit Informationen zu den Fehlern, die zum Fehlschlagen der Veröffentlichung geführt haben.

Installieren

$ npm install @semantic-release/gitlab -D

Verwendung

Das Plugin kann in der Semantic-Release- Konfigurationsdatei konfiguriert werden:

{
  "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 " }
        ]
      }
    ]
  ]
}

Mit diesem Beispiel werden GitLab-Releases auf der Instanz https://custom.gitlab.com veröffentlicht.

Konfiguration

GitLab-Authentifizierung

Die GitLab-Authentifizierungskonfiguration ist erforderlich und kann über Umgebungsvariablen festgelegt werden.

Erstellen Sie ein Projektzugriffstoken, Gruppenzugriffstoken oder persönliches Zugriffstoken mit der Rolle „Entwickler“ (oder höher) und dem api Bereich und stellen Sie es in Ihrer CI-Umgebung über die Umgebungsvariable GL_TOKEN zur Verfügung. Wenn Sie GL_TOKEN als Remote-Git-Repository-Authentifizierung verwenden, muss es auch den Bereich write_repository haben.

Hinweis : Bei der Ausführung mit dryRun ist nur der Bereich read_repository erforderlich.

Umgebungsvariablen

Variable	Beschreibung
`GL_TOKEN` oder `GITLAB_TOKEN`	Erforderlich. Das zur Authentifizierung bei GitLab verwendete Token.
`GL_URL` oder `GITLAB_URL`	Der GitLab-Endpunkt.
`GL_PREFIX` oder `GITLAB_PREFIX`	Das GitLab-API-Präfix.
`HTTP_PROXY` oder `HTTPS_PROXY`	Zu verwendender HTTP- oder HTTPS-Proxy.
`NO_PROXY`	Muster, für die der Proxy ignoriert werden sollte. Details siehe unten.

Proxy-Konfiguration

Das Plugin unterstützt die Weiterleitung von Anfragen über einen Proxyserver.

Sie können einen Proxyserver über die Umgebungsvariable HTTPS_PROXY konfigurieren: HTTPS_PROXY=http://proxyurl.com:8080

Wenn Ihr Proxyserver eine Authentifizierung erfordert, betten Sie den Benutzernamen und das Passwort in die URL ein: HTTPS_PROXY=http://user:[email protected]:8080

Wenn Ihre GitLab-Instanz über einfaches HTTP verfügbar gemacht wird (nicht empfohlen!), verwenden Sie stattdessen HTTP_PROXY .

Wenn Sie den Proxy für einige Hosts umgehen müssen, konfigurieren Sie die Umgebungsvariable NO_PROXY : NO_PROXY=*.host.com, host.com

Optionen

Option	Beschreibung	Standard
`gitlabUrl`	Der GitLab-Endpunkt.	`GL_URL` oder `GITLAB_URL` Umgebungsvariable oder von CI bereitgestellte Umgebungsvariablen, wenn sie auf GitLab CI/CD oder `https://gitlab.com` ausgeführt werden.
`gitlabApiPathPrefix`	Das GitLab-API-Präfix.	`GL_PREFIX` oder `GITLAB_PREFIX` Umgebungsvariable oder von CI bereitgestellte Umgebungsvariablen, wenn sie auf GitLab CI/CD oder `/api/v4` ausgeführt werden.
`assets`	Eine Reihe von Dateien, die in die Veröffentlichung hochgeladen werden sollen. Siehe Vermögenswerte.	-
`milestones`	Eine Reihe von Meilensteintiteln, die der Veröffentlichung zugeordnet werden können. Siehe GitLab Release API.	-
`successComment`	Der Kommentar, der zu jedem durch die Veröffentlichung gelösten Problem und jeder Zusammenführungsanfrage hinzugefügt werden soll. Siehe Erfolgskommentar.	? Dieses Problem wurde in der Version ${nextRelease.version} behoben.nnDie Veröffentlichung ist in der GitLab-Version verfügbar
`successCommentCondition`	Verwenden Sie dies als Bedingung, wenn Sie Probleme kommentieren oder Anfragen zusammenführen möchten. Siehe successCommentCondition.	-
`failComment`	Der Inhalt des Problems, das erstellt wird, wenn ein Release fehlschlägt. Siehe failComment.	Freundliche Nachricht mit Links zur Semantic-Release -Dokumentation und -Support, mit der Liste der Fehler, die zum Fehlschlagen des Release geführt haben.
`failTitle`	Der Titel des Problems, das erstellt wird, wenn eine Veröffentlichung fehlschlägt.	`The automated release is failing`
`failCommentCondition`	Verwenden Sie dies als Bedingung, wann Sie bei Fehlern einen Kommentar abgeben oder einen Issue erstellen möchten. Siehe failCommentCondition.	-
`labels`	Die Bezeichnungen, die dem erstellten Problem hinzugefügt werden sollen, wenn ein Release fehlschlägt. Auf `false` setzen, um keine Beschriftung hinzuzufügen. Bezeichnungen sollten durch Kommas getrennt werden, wie in den offiziellen Dokumenten beschrieben, z. B. `"semantic-release,bot"` .	`semantic-release`
`assignee`	Der Beauftragte, der dem erstellten Problem etwas hinzufügen soll, wenn ein Release fehlschlägt.	-

Vermögenswerte

Kann ein Glob oder ein Array von Globs und Object s mit den folgenden Eigenschaften sein:

Eigentum	Beschreibung	Standard
`path`	Erforderlich , sofern keine `url` festgelegt ist. Ein Glob zur Identifizierung der hochzuladenden Dateien. Unterstützt Lodash-Templating.	-
`url`	Alternativ zum Festlegen `path` bietet dies die Möglichkeit, Links zu Veröffentlichungen hinzuzufügen, z. B. URLs zu Containerbildern. Unterstützt Lodash-Templating.	-
`label`	Kurze Beschreibung der Datei, die in der GitLab-Version angezeigt wird. Wird ignoriert, wenn `path` mit mehr als einer Datei übereinstimmt. Unterstützt Lodash-Templating.	Aus dem `path` extrahierter Dateiname.
`type`	In der GitLab-Version angezeigter Asset-Typ. Kann `runbook` , `package` , `image` und `other` sein (siehe offizielle Dokumente zu Release-Assets). Unterstützt Lodash-Templating.	`other`
`filepath`	Ein Dateipfad zum Erstellen eines Permalinks, der auf das Asset verweist (erfordert GitLab 12.9+, siehe offizielle Dokumente zu Permanentlinks). Wird ignoriert, wenn `path` mit mehr als einer Datei übereinstimmt. Unterstützt Lodash-Templating.	-
`target`	Steuert, wohin die Datei hochgeladen wird. Kann auf `project_upload` gesetzt werden, um die Datei als Projekt-Upload zu speichern, oder `generic_package` um die Datei als generisches Paket zu speichern.	`project_upload`
`status`	Dies wird nur angewendet, wenn `target` auf `generic_package` gesetzt ist. Der generische Paketstatus. Kann `default` oder `hidden` sein (siehe offizielle Dokumente zu generischen Paketen).	`default`

Jeder Eintrag im assets Array wird einzeln globiert. Ein Glob kann ein String ( "dist/**/*.js" oder "dist/mylib.js" ) oder ein Array von String s sein, die zusammen globiert werden ( ["dist/**", "!**/*.css"] ).

Wenn ein Verzeichnis konfiguriert ist, werden alle Dateien in diesem Verzeichnis und seinen untergeordneten Verzeichnissen einbezogen.

Hinweis : Wenn eine Datei eine Übereinstimmung in assets aufweist, wird sie einbezogen, auch wenn es auch eine Übereinstimmung in .gitignore gibt.

Beispiele für Vermögenswerte

'dist/*.js' : Alle js Dateien im dist -Verzeichnis einschließen, jedoch nicht in seinen Unterverzeichnissen.

[['dist', '!**/*.css']] : Alle Dateien im dist Verzeichnis und seinen Unterverzeichnissen mit Ausnahme der css Dateien einschließen.

[{path: 'dist/MyLibrary.js', label: 'MyLibrary JS distribution'}, {path: 'dist/MyLibrary.css', label: 'MyLibrary CSS distribution'}] : Schließen Sie dist/MyLibrary.js und ein dist/MyLibrary.css Dateien und bezeichnen Sie sie in der GitLab-Version MyLibrary JS distribution und MyLibrary CSS distribution .

[['dist/**/*.{js,css}', '!**/*.min.*'], {path: 'build/MyLibrary.zip', label: 'MyLibrary'}] : include Alle js und css Dateien im dist Verzeichnis und seinen Unterverzeichnissen mit Ausnahme der minimierten Version sowie die Datei build/MyLibrary.zip und bezeichnen sie in der GitLab-Version MyLibrary .

ErfolgKommentar

Die Nachricht für die Problemkommentare wird mit der Lodash-Vorlage generiert. Folgende Variablen stehen zur Verfügung:

Parameter	Beschreibung
`branch`	`Object` mit `name` , `type` , `channel` , `range` und `prerelease` des Zweigs, von dem aus die Veröffentlichung erfolgt.
`lastRelease`	`Object` mit `version` , `channel` , `gitTag` und `gitHead` der letzten Veröffentlichung.
`nextRelease`	`Object` mit `version` , `channel` , `gitTag` , `gitHead` und `notes` zur durchgeführten Veröffentlichung.
`commits`	`Array` von Commit `message` `Object` mit `hash` , `subject` , `body` und `author` .
`releases`	`Array` mit einem Release- `Object` für jedes veröffentlichte Release, mit optionalen Release-Daten wie `name` und `url` .
`issue`	Ein GitLab API Issue-Objekt, an das der Kommentar gepostet wird, oder `false` beim Kommentieren von Merge Requests.
`mergeRequest`	Ein GitLab API Merge Request-Objekt, an das der Kommentar gepostet wird, oder `false` beim Kommentieren von Problemen.

successCommentCondition

Die Erfolgskommentarbedingung wird mit der Lodash-Vorlage generiert. Folgende Variablen stehen zur Verfügung:

Parameter	Beschreibung
`branch`	`Object` mit `name` , `type` , `channel` , `range` und `prerelease` des Zweigs, von dem aus die Veröffentlichung erfolgt.
`lastRelease`	`Object` mit `version` , `channel` , `gitTag` und `gitHead` der letzten Veröffentlichung.
`nextRelease`	`Object` mit `version` , `channel` , `gitTag` , `gitHead` und `notes` zur durchgeführten Veröffentlichung.
`commits`	`Array` von Commit `message` `Object` mit `hash` , `subject` , `body` und `author` .
`releases`	`Array` mit einem Release- `Object` für jedes veröffentlichte Release, mit optionalen Release-Daten wie `name` und `url` .
`issue`	Ein GitLab API Issue-Objekt, an das der Kommentar gepostet wird.
`mergeRequest`	Ein GitLab API Merge Request-Objekt, an das der Kommentar gepostet wird.

successCommentCondition-Beispiel

Überhaupt keine Kommentare erstellen: auf false oder templating setzen: "<% return false; %>"
um nur Probleme zu kommentieren: "<% return issue %>"
um nur Zusammenführungsanfragen zu kommentieren: "<% return mergeRequest %>"
Sie können Labels verwenden, um Probleme zu filtern: "<% return issue.labels?.includes('semantic-release-relevant') %>"

Überprüfen Sie das GitLab API Merge Request-Objekt oder das GitLab API Issue-Objekt auf Eigenschaften, die für den Filter verwendet werden können

failComment

Die Nachricht für den Probleminhalt wird mit der Lodash-Vorlage generiert. Folgende Variablen stehen zur Verfügung:

Parameter	Beschreibung
`branch`	Der Zweig, aus dem die Veröffentlichung fehlgeschlagen ist.
`errors`	Ein `Array` von SemanticReleaseError. Jeder Fehler verfügt über die Eigenschaften `message` , `code` , `pluginName` und `details` . `pluginName` enthält den Paketnamen des Plugins, das den Fehler ausgelöst hat. `details` enthält eine im Markdown formatierte Information über den Fehler.

failComment-Beispiel

Der failComment This release from branch ${branch.name} had failed due to the following errors:n- ${errors.map(err => err.message).join('\n- ')} generiert den Kommentar:

Diese Veröffentlichung von Branch Master war aufgrund der folgenden Fehler fehlgeschlagen:
Fehlermeldung 1
Fehlermeldung 2

failCommentCondition

Die Fehlerkommentarbedingung wird mit der Lodash-Vorlage generiert. Folgende Variablen stehen zur Verfügung:

Parameter	Beschreibung
`branch`	`Object` mit `name` , `type` , `channel` , `range` und `prerelease` des Zweigs, von dem aus die Veröffentlichung erfolgt.
`lastRelease`	`Object` mit `version` , `channel` , `gitTag` und `gitHead` der letzten Veröffentlichung.
`nextRelease`	`Object` mit `version` , `channel` , `gitTag` , `gitHead` und `notes` zur durchgeführten Veröffentlichung.
`commits`	`Array` von Commit `message` `Object` mit `hash` , `subject` , `body` und `author` .
`releases`	`Array` mit einem Release- `Object` für jedes veröffentlichte Release, mit optionalen Release-Daten wie `name` und `url` .
`issue`	Ein GitLab API Issue-Objekt, auf dem der Kommentar gepostet wird – nur verfügbar, wenn ein offenes Issue vorhanden ist.

failCommentCondition-Beispiel

Überhaupt keine Kommentare erstellen: auf false oder templating setzen: "<% return false; %>"
um nur den Hauptzweig zu kommentieren: "<% return branch.name === 'main' %>"
Sie können Labels verwenden, um Probleme zu filtern, z. B. um keinen Kommentar abzugeben, wenn das Problem mit wip gekennzeichnet ist: "<% return !issue.labels?.includes('wip') %>"

Überprüfen Sie das GitLab API Issue-Objekt auf Eigenschaften, die für den Filter verwendet werden können

Kompatibilität

Die neueste Version dieses Plugins ist mit allen derzeit unterstützten Versionen von GitLab kompatibel, also der aktuellen Hauptversion und den beiden vorherigen Hauptversionen. Es kann nicht garantiert werden, dass dieses Plugin mit nicht unterstützten Versionen von GitLab funktioniert.

Wichtige Änderungen in 14.0

Wenn Sie GitLab.com verwenden oder Ihre selbst gehostete GitLab-Instanz auf 14.0 aktualisiert haben, verwenden Sie bitte Version >=6.0.7 dieses Plugins.

Warum?

In GitLab 14.0 wurde das Erstellen eines Release mithilfe der Tags-API entfernt (siehe # 290311). Dieses Plugin wurde in #184 aktualisiert, um stattdessen die Releases-API zu verwenden, die in Version 6.0.7 und höher verfügbar ist.

Expandieren

Zusätzliche Informationen