repo sync
This commit is contained in:
Octomerger Bot
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Informationen zu Aktionen
|
||||
intro: 'Aktionen sind einzelne Aufgaben, die Du kombinieren kannst, um Aufträge zu erstellen und Deinen Workflow anzupassen. Sie können eigene Aktionen erstellen oder Aktionen verwenden und anpassen, die von der {% data variables.product.prodname_dotcom %} -Community gemeinsam genutzt werden.'
|
||||
intro: 'Aktionen sind einzelne Aufgaben, die Du kombinieren kannst, um Aufträge zu erstellen und Deinen Workflow anzupassen. You can create your own actions, or use and customize actions shared by the {% data variables.product.prodname_dotcom %} community.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/about-actions
|
||||
@@ -20,7 +20,8 @@ versions:
|
||||
Zum Erstellen von Aktionen können Sie benutzerdefinierten Code schreiben, der mit Ihrem Repository auf die gewünschte Weise interagiert und sich dabei beispielsweise in die APIs von {% data variables.product.prodname_dotcom %} und in öffentlich zugängliche Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
Sie können eigene Aktionen schreiben und ausschließlich in Ihrem Workflow verwenden oder auch Ihre erstellten Aktionen mit der {% data variables.product.prodname_dotcom %}-Community schreiben. Die erstellten Aktionen können nur dann freigegeben werden, wenn das Repository öffentlich ist.
|
||||
You can write your own actions to use in your workflow or share the actions you build with the
|
||||
{% data variables.product.prodname_dotcom %} community. Die erstellten Aktionen können nur dann freigegeben werden, wenn das Repository öffentlich ist.
|
||||
{% endif %}
|
||||
|
||||
Aktionen können direkt auf einem Computer oder in einem Docker-Container laufen. Sie können die Eingabe, die Ausgabe und die Umgebungsvariablen für eine Aktion definieren.
|
||||
@@ -53,42 +54,43 @@ Wenn Sie ein Node.js Projekt entwickeln, bietet das {% data variables.product.pr
|
||||
|
||||
#### Zusammengesetzte Ausführungsschritte Aktionen
|
||||
|
||||
Ein _zusammengesetzten Ausführungsschritte_ Aktion ermöglicht es Ihnen, mehrere Workflowausführungsschritte innerhalb einer Aktion zu kombinieren. Sie können diese Funktion beispielsweise verwenden, um mehrere Ausführungsbefehle in einer Aktion zu bündeln, und dann einen Workflow haben, der die gebündelten Befehle in einem einzigen Schritt mit dieser Aktion ausführt. Um ein Beispiel anzuzeigen, sehen Sie sich "[Erstellen einer zusammengesetzten Ausführungsschritteaktion](/actions/creating-actions/creating-a-composite-run-steps-action)" an.
|
||||
A _composite run steps_ action allows you to combine multiple workflow run steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands a single step using that action. To see an example, check out "[Creating a composite run steps action](/actions/creating-actions/creating-a-composite-run-steps-action)".
|
||||
|
||||
### Ort für eine Aktion auswählen
|
||||
|
||||
Wenn Du eine Aktion entwickelst, die von anderen Personen genutzt werden soll, empfehlen wir, die Aktion in ihrem eigenen Repository zu belassen, also nicht mit anderem Anwendungscode zu einem Bundle zusammenzufassen. Damit kannst Du die Aktion wie jede andere Software versionieren, nachverfolgen und veröffentlichen.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
Wenn Du eine Aktion in einem eigenen Repository speicherst, kann die {% data variables.product.prodname_dotcom %}-Community die Aktion eher entdecken. Außerdem wird damit die Codebasis begrenzt, auf die die Entwickler bei der Fehlerbehebung und bei der Erweiterung der Aktion angewiesen sind, und die Versionierung der Aktion wird von der Versionierung des anderen Anwendungscodes getrennt.
|
||||
Storing an action in its own repository makes it easier for the
|
||||
{% data variables.product.prodname_dotcom %} community to discover the action, narrows the scope of the code base for developers fixing issues and extending the action, and decouples the action's versioning from the versioning of other application code.
|
||||
{% endif %}
|
||||
|
||||
Wenn Du eine Aktion erstellst, die nicht öffentlich zugänglich sein soll, kannst Du die Dateien für die Aktion an einem beliebigen Speicherort in Deinem Repository ablegen. Wenn der Aktions-, der Workflow- und der Anwendungscode in einem einzigen Repository abgelegt werden sollen, empfehlen wir, die Aktionen im Verzeichnis `.github` zu speichern. Beispiel: `.github/actions/action-a` und `.github/actions/action-b`.
|
||||
{% if currentVersion == "free-pro-team@latest" %}If you're building an action that you don't plan to make available to the public, you {% else %} You{% endif %} can store the action's files in any location in your repository. Wenn der Aktions-, der Workflow- und der Anwendungscode in einem einzigen Repository abgelegt werden sollen, empfehlen wir, die Aktionen im Verzeichnis `.github` zu speichern. Beispiel: `.github/actions/action-a` und `.github/actions/action-b`.
|
||||
|
||||
### Kompatibilität mit {% data variables.product.prodname_ghe_server %}
|
||||
### Compatibility with {% data variables.product.prodname_ghe_server %}
|
||||
|
||||
Um sicherzustellen, dass Ihre Aktion mit {% data variables.product.prodname_ghe_server %}kompatibel ist, sollten Sie sicherstellen, dass Sie keine hartcodierten Verweise auf {% data variables.product.prodname_dotcom %} API-URLs verwenden. Sie sollten stattdessen Umgebungsvariablen verwenden, um auf die {% data variables.product.prodname_dotcom %} -API zu verweisen:
|
||||
To ensure that your action is compatible with {% data variables.product.prodname_ghe_server %}, you should make sure that you do not use any hard-coded references to {% data variables.product.prodname_dotcom %} API URLs. You should instead use environment variables to refer to the {% data variables.product.prodname_dotcom %} API:
|
||||
|
||||
- Verwenden Sie für die REST-API die `GITHUB_API_URL` -Umgebungsvariable.
|
||||
- Verwenden Sie für GraphQL die Umgebungsvariable `GITHUB_GRAPHQL_URL` .
|
||||
|
||||
Weitere Informationen finden Sie unter "[Standardumgebungsvariablen](/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables)".
|
||||
For more information, see "[Default environment variables](/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables)."
|
||||
|
||||
### Verwenden der Releaseverwaltung für Aktionen
|
||||
|
||||
In diesem Abschnitt wird erläutert, wie Sie die Releaseverwaltung verwenden können, um Aktualisierungen auf vorhersehbare Weise an Ihre Aktionen zu verteilen.
|
||||
This section explains how you can use release management to distribute updates to your actions in a predictable way.
|
||||
|
||||
#### Bewährte Verfahren für das Release-Management
|
||||
|
||||
Wenn Sie eine Aktion für andere Benutzer entwickeln, empfehlen wir die Verwendung der Releaseverwaltung, um zu steuern, wie Sie Updates verteilen. Benutzer können erwarten, dass die Hauptversion einer Aktion die erforderlichen kritischen Korrekturen und Sicherheitspatches enthält, während sie weiterhin mit ihren vorhandenen Workflows kompatibel bleiben. Sie sollten die Veröffentlichung einer neuen Hauptversion in Betracht ziehen, wenn sich Ihre Änderungen auf die Kompatibilität auswirken.
|
||||
If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's major version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.
|
||||
|
||||
Bei diesem Releaseverwaltungsansatz sollten Benutzer nicht auf den `Master` Zweig einer Aktion verweisen, da dieser wahrscheinlich den neuesten Code enthält und daher möglicherweise instabil ist. Stattdessen können Sie den Benutzern empfehlen, bei der Verwendung Ihrer Aktion eine Hauptversion anzugeben und sie nur dann an eine bestimmte Version weiterzuleiten, wenn Probleme auftreten.
|
||||
Bei diesem Releaseverwaltungsansatz sollten Benutzer nicht auf den `Master` Zweig einer Aktion verweisen, da dieser wahrscheinlich den neuesten Code enthält und daher möglicherweise instabil ist. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.
|
||||
|
||||
Um eine bestimmte Aktionsversion zu verwenden, können Benutzer ihre {% data variables.product.prodname_actions %} Workflow so konfigurieren, dass sie auf ein Tag, die SHA eines Commits oder einen Zweig abzielen, der nach einer Version benannt ist.
|
||||
To use a specific action version, users can configure their {% data variables.product.prodname_actions %} workflow to target a tag, a commit's SHA, or a branch named for a release.
|
||||
|
||||
#### Verwenden von Tags für die Releaseverwaltung
|
||||
|
||||
Es wird empfohlen, Tags für die Releaseverwaltung von Aktionen zu verwenden. Mit diesem Ansatz können Ihre Benutzer leicht zwischen Haupt- und Nebenversionen unterscheiden:
|
||||
We recommend using tags for actions release management. Using this approach, your users can easily distinguish between major and minor versions:
|
||||
|
||||
- Erstellen und überprüfen Sie eine Version auf einem Release-Zweig (z. B. `release/v1`), bevor Sie das Release-Tag erstellen (z. B. `v1.0.2`).
|
||||
- Erstellen Sie eine Version mit semantischer Versionierung. Weitere Informationen finden Sie unter „[Veröffentlichungen erstellen](/articles/creating-releases)“.
|
||||
@@ -96,14 +98,14 @@ Es wird empfohlen, Tags für die Releaseverwaltung von Aktionen zu verwenden. Mi
|
||||
- Führen Sie ein neues Hauptversions-Tag (`v2`) für Änderungen ein, die vorhandene Workflows unterbrechen. Eine störende Änderung liegt beispielsweise vor, wenn die Eingabe einer Aktion geändert wird.
|
||||
- Hauptversionen können zunächst mit einem `Beta-` -Tag veröffentlicht werden, um ihren Status anzugeben, z. B. `v2-beta`. Das `-beta-` -Tag kann dann entfernt werden, wenn es fertig ist.
|
||||
|
||||
In diesem Beispiel wird veranschaulicht, wie ein Benutzer auf ein Hauptversions-Tag verweisen kann:
|
||||
This example demonstrates how a user can reference a major release tag:
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
- verwendet: actions/javascript-action@v1
|
||||
```
|
||||
|
||||
In diesem Beispiel wird veranschaulicht, wie ein Benutzer auf ein bestimmtes Patch-Release-Tag verweisen kann:
|
||||
This example demonstrates how a user can reference a specific patch release tag:
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
@@ -112,7 +114,7 @@ Schritte:
|
||||
|
||||
#### Verwenden von Zweigen für die Releaseverwaltung
|
||||
|
||||
Wenn Sie Zweigstellennamen für die Releaseverwaltung verwenden möchten, wird in diesem Beispiel veranschaulicht, wie Sie auf eine benannte Zweigstelle verweisen:
|
||||
If you prefer to use branch names for release management, this example demonstrates how to reference a named branch:
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
@@ -121,7 +123,7 @@ Schritte:
|
||||
|
||||
#### Verwenden des SHA eines Commits für die Releaseverwaltung
|
||||
|
||||
Jeder Git-Commit erhält einen berechneten SHA-Wert, der eindeutig und unveränderlich ist. Die Benutzer Ihrer Aktion möchten sich möglicherweise auf den SHA-Wert eines Commits verlassen, da dieser Ansatz zuverlässiger sein kann als die Angabe eines Tags, das gelöscht oder verschoben werden könnte. Dies bedeutet jedoch, dass die Benutzer keine weiteren Aktualisierungen der Aktion erhalten. Die Verwendung des vollständigen SHA-Werts eines Commits anstelle des abgekürzten Werts kann dazu beitragen, dass Personen einen böswilligen Commit verwenden, der dieselbe Abkürzung verwendet.
|
||||
Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. Using a commit's full SHA value instead of the abbreviated value can help prevent people from using a malicious commit that uses the same abbreviation.
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
@@ -141,7 +143,7 @@ Wenn Du Deine Aktion öffentlich bereitstellen möchten, empfehlen wir, eine REA
|
||||
|
||||
### Unterschiede zwischen {% data variables.product.prodname_actions %} und {% data variables.product.prodname_github_apps %}
|
||||
|
||||
{% data variables.product.prodname_marketplace %} bietet Tools, um Deinen Workflow zu verbessern. Wenn Du die Unterschiede und die Vorteile der einzelnen Tools verstehst, kannst Du das beste Tool für Deinen Auftrag auswählen. Weitere Informationen zum Erstellen von Aktionen und Apps finden Sie unter "[über GitHub-Aktionen](/actions/getting-started-with-github-actions/about-github-actions)" und "[über Apps](/apps/about-apps/)".
|
||||
{% data variables.product.prodname_marketplace %} bietet Tools, um Deinen Workflow zu verbessern. Wenn Du die Unterschiede und die Vorteile der einzelnen Tools verstehst, kannst Du das beste Tool für Deinen Auftrag auswählen. For more information about building apps, see "[About apps](/apps/about-apps/)."
|
||||
|
||||
#### Stärken von GitHub Aktionen und GitHub Apps
|
||||
|
||||
|
||||
@@ -18,9 +18,9 @@ Nachdem Sie dieses Projekt abgeschlossen haben, sollten Sie verstehen, wie Sie I
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Bevor Sie beginnen, erstellen Sie ein {% data variables.product.product_name %} Repository.
|
||||
Before you begin, you'll create a {% data variables.product.product_name %} repository.
|
||||
|
||||
1. Erstellen Sie ein neues öffentliches Repository auf {% data variables.product.product_location %}. Sie können einen beliebigen Repository-Namen auswählen oder die folgenden `hello-world-composite-run-steps-action` Beispiel verwenden. Sie können diese Dateien hinzufügen, nachdem Ihr Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
|
||||
1. Create a new public repository on {% data variables.product.product_location %}. Sie können einen beliebigen Repository-Namen auswählen oder die folgenden `hello-world-composite-run-steps-action` Beispiel verwenden. Du kannst diese Dateien hinzufügen, nachdem Dein Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
|
||||
|
||||
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
|
||||
|
||||
@@ -36,7 +36,7 @@ Bevor Sie beginnen, erstellen Sie ein {% data variables.product.product_name %}
|
||||
echo "Auf Wiedersehen"
|
||||
```
|
||||
|
||||
1. Machen Sie von Ihrem Terminal aus `goodbye.sh` ausführbare Datei und checken Sie sie in Ihr Repository ein.
|
||||
3. From your terminal, make `goodbye.sh` executable.
|
||||
|
||||
```shell
|
||||
chmod +x goodbye.sh
|
||||
@@ -85,13 +85,26 @@ Bevor Sie beginnen, erstellen Sie ein {% data variables.product.product_name %}
|
||||
|
||||
Weitere Informationen zur Verwendung von `github.action_path`finden Sie unter "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
|
||||
1. Erstellen Sie eine neue Bezeichnung. In diesem Beispiel wird eine Bezeichnung mit dem Namen `v1` für den Hauptzweig verwendet. Weitere Informationen finden Sie unter "[Erstellen einer Bezeichnung ](/github/managing-your-work-on-github/creating-a-label)."
|
||||
1. From your terminal, check in your `action.yml` file.
|
||||
|
||||
```shell
|
||||
git add action.yml
|
||||
git commit -m "Add action"
|
||||
git push
|
||||
```
|
||||
|
||||
1. From your terminal, add a tag. This example uses a tag called `v1`. Weitere Informationen finden Sie unter „[Informationen zu Aktionen](/actions/creating-actions/about-actions#using-release-management-for-actions)“.
|
||||
|
||||
```shell
|
||||
git tag -a -m "Description of this release" v1
|
||||
git push --follow-tags
|
||||
```
|
||||
|
||||
### Deine Aktion in einem Workflow testen
|
||||
|
||||
Der folgende Workflowcode verwendet die abgeschlossene Hello-World-Aktion, die Sie in "[Erstellen einer Aktionsmetadatendatei](/actions/creating-actions/creating-a-composite-run-steps-action#creating-an-action-metadata-file)" ausgeführt haben.
|
||||
|
||||
Kopieren Sie den Workflowcode in eine `.github/workflows/main.yml` Datei in einem anderen Repository, ersetzen Sie jedoch `actions/hello-world-composite-run-steps-action@v1` durch das Repository und die Von Ihnen erstellte Bezeichnung. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
|
||||
Copy the workflow code into a `.github/workflows/main.yml` file in another repository, but replace `actions/hello-world-composite-run-steps-action@v1` with the repository and tag you created. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
|
||||
|
||||
{% raw %}
|
||||
**.github/workflows/main.yml**
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Eine Docker-Container-Aktion erstellen
|
||||
intro: In diesem Leitfaden werden die mindestens erforderlichen Schritte zum Erstellen einer Docker-Container-Aktion beschrieben.
|
||||
intro: 'In diesem Leitfaden werden die mindestens erforderlichen Schritte zum Erstellen einer Docker-Container-Aktion beschrieben.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/creating-a-docker-container-action
|
||||
|
||||
@@ -33,7 +33,7 @@ Als Erstes müssen Sie die Anwendung Node.js herunterladen und ein GitHub-Reposi
|
||||
|
||||
https://nodejs.org/de/download/current/
|
||||
|
||||
1. Erstellen Sie ein neues Repository auf {% data variables.product.product_location %}. Du kannst einen beliebigen Repository-Namen auswählen oder wie in diesem Beispiel „hello-world-javascript-action“ verwenden. Sie können diese Dateien hinzufügen, nachdem Ihr Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
|
||||
1. Erstellen Sie ein neues Repository auf {% data variables.product.product_location %}. Du kannst einen beliebigen Repository-Namen auswählen oder wie in diesem Beispiel „hello-world-javascript-action“ verwenden. Du kannst diese Dateien hinzufügen, nachdem Dein Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
|
||||
|
||||
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
|
||||
|
||||
@@ -77,9 +77,9 @@ Diese Datei definiert die Eingabe `who-to-greet` und die Ausgabe `time`. Sie gib
|
||||
|
||||
Das Toolkit für Aktionen ist eine Node.js-Paketsammlung, mit der Sie JavaScript-Aktionen schnell und konsistenter erstellen können.
|
||||
|
||||
Das Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/master/packages/core) enthält eine Schnittstelle für die Workflow-Befehle, Eingabe- und Ausgabevariablen, Exit-Status und Debugging-Meldungen.
|
||||
Das Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) enthält eine Schnittstelle für die Workflow-Befehle, Eingabe- und Ausgabevariablen, Exit-Status und Debugging-Meldungen.
|
||||
|
||||
Das Toolkit enthält zudem das Paket [`@actions/github`](https://github.com/actions/toolkit/tree/master/packages/github), das einen authentifizierten Octokit REST-Client und Zugriff auf GitHub Aktions-Kontexte bietet.
|
||||
Das Toolkit enthält zudem das Paket [`@actions/github`](https://github.com/actions/toolkit/tree/main/packages/github), das einen authentifizierten Octokit REST-Client und Zugriff auf GitHub Aktions-Kontexte bietet.
|
||||
|
||||
Das Toolkit bietet mehr als die Pakete `core` und `github`. Weitere Informationen findest Du im Repository [actions/toolkit](https://github.com/actions/toolkit).
|
||||
|
||||
@@ -119,7 +119,7 @@ try {
|
||||
}
|
||||
```
|
||||
|
||||
Wenn im o. g. `index.js`-Beispiel ein Fehler ausgegeben wird, nutzt `core.setFailed(error.message);` das Aktions-Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/master/packages/core), um eine Meldung zu protokollieren und einen Fehler-Exit-Code festzulegen. Weitere Informationen findest Du unter "[Exit Codes für Aktionen setzen](/actions/creating-actions/setting-exit-codes-for-actions)."
|
||||
Wenn im o. g. `index.js`-Beispiel ein Fehler ausgegeben wird, nutzt `core.setFailed(error.message);` das Aktions-Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core), um eine Meldung zu protokollieren und einen Fehler-Exit-Code festzulegen. Weitere Informationen findest Du unter "[Exit Codes für Aktionen setzen](/actions/creating-actions/setting-exit-codes-for-actions)."
|
||||
|
||||
|
||||
### Eine README erstellen
|
||||
@@ -258,4 +258,8 @@ Jobs:
|
||||
|
||||
Klicke in Deinem Repository auf die Registerkarte **Actions** (Aktionen), und wähle die neueste Workflow-Ausführung aus. Es sollten „Hello Mona the Octocat“ oder der von Dir für die Eingabe `who-to-greet` verwendete Name und der im Protokoll ausgegebene Zeitstempel angezeigt werden.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
|
||||
{% else %}
|
||||
|
||||
{% endif %}
|
||||
@@ -5,7 +5,8 @@ redirect_from:
|
||||
- /articles/building-actions
|
||||
- /github/automating-your-workflow-with-github-actions/building-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/building-actions
|
||||
- /aktionen/Building-Aktionen
|
||||
- /actions/building-actions
|
||||
- /articles/creating-a-github-action/
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Metadaten-Syntax für GitHub-Aktionen
|
||||
shortTitle: Metadaten-Syntax
|
||||
intro: 'Du kannst Aktionen erstellen, um Aufgaben in Ihrem Repository zu erledigen. Für Aktionen ist eine Metadaten-Datei erforderlich, welche die YAML-Syntax verwendet.'
|
||||
intro: Du kannst Aktionen erstellen, um Aufgaben in Ihrem Repository zu erledigen. Für Aktionen ist eine Metadaten-Datei erforderlich, welche die YAML-Syntax verwendet.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/metadata-syntax-for-github-actions
|
||||
@@ -42,7 +42,6 @@ Aktionsmetadatendateien verwenden die YAML-Syntax. Wenn Sie bislang noch nicht m
|
||||
|
||||
In diesem Beispiel werden zwei Eingaben konfiguriert: „numOctocats“ und „octocatEyeColor“. Die Eingabe „numOctocats“ ist nicht erforderlich und entspricht standardmäßig dem Wert „1“. Die Eingabe „octocatEyeColor“ ist erforderlich und weist keinen Standardwert auf. Workflow-Dateien, die diese Aktion einsetzen, müssen das Stichwort `with` verwenden, um für „octocatEyeColor“ einen Eingabewert festzulegen. Weitere Informationen zu `with`-Syntax finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepswith)“.
|
||||
|
||||
|
||||
```yaml
|
||||
inputs:
|
||||
numOctocats:
|
||||
@@ -54,7 +53,6 @@ inputs:
|
||||
required: true
|
||||
```
|
||||
|
||||
|
||||
Wenn Sie eine Eingabe für eine Aktion in einer Workflow-Datei angeben oder einen Standardeingabewert verwenden, erstellt {% data variables.product.prodname_dotcom %} eine Umgebungsvariable für die Eingabe mit dem Namen `INPUT_<VARIABLE_NAME>`. Die erstellte Umgebungsvariable wandelt Eingabenamen in Großbuchstaben um und ersetzt Leerzeichen durch `_`-Zeichen.
|
||||
|
||||
Wenn beispielsweise ein Workflow die Eingaben „numOctocats“ und „octocatEyeColor“ definiert hat, kann der Aktionscode die Werte für die Eingaben mithilfe der Umgebungsvariablen `INPUT_NUMOCTOCATS` and `INPUT_OCTOCATEYECOLOR` lesen.
|
||||
@@ -99,7 +97,7 @@ outputs:
|
||||
|
||||
### **`-Ausgaben`** für Aktionen mit zusammengesetzten Ausführungsschritten
|
||||
|
||||
**Optionale** `-Ausgänge verwenden` die gleichen Parameter wie `-Ausgänge.<output_id>` und `Ausgänge.<output_id>.description` (siehe "[`Ausgaben` für {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#outputs)"), enthält aber auch den `-Wert` Token.
|
||||
**Optional** `outputs` use the same parameters as `outputs.<output_id>` and `outputs.<output_id>.description` (see "[`outputs` for {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#outputs)"), but also includes the `value` token.
|
||||
|
||||
#### Beispiel
|
||||
|
||||
@@ -121,7 +119,7 @@ läuft:
|
||||
#### **`outputs.<output_id.value>`**
|
||||
**Erforderliche** Der Wert, dem der Ausgabeparameter zugeordnet wird. Sie können dies auf eine `Zeichenfolge` oder einen Ausdruck mit Kontext festlegen. Sie können z. B. die `Schritte` Kontext verwenden, um den `Wert` einer Ausgabe auf den Ausgabewert eines Schritts festzulegen.
|
||||
|
||||
Weitere Informationen zur Verwendung von Kontext- und Ausdruckssyntax finden Sie unter "[Kontext- und Ausdruckssyntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
For more information on how to use context and expression syntax, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
|
||||
### **`runs`** für JavaScript-Aktionen
|
||||
|
||||
@@ -243,7 +241,7 @@ Weitere Informationen finden Sie unter "[`github context`](/actions/reference/co
|
||||
|
||||
##### **`runs.steps.env`**
|
||||
|
||||
**Optionale** Legt eine `Zuordnung` von Umgebungsvariablen nur für diesen Schritt fest. Wenn Sie die im Workflow gespeicherte Umgebungsvariable ändern möchten, verwenden Sie `Echo "::set-env name={name}::{value}"` in einem zusammengesetzten Ausführungsschritt.
|
||||
**Optionale** Legt eine `Zuordnung` von Umgebungsvariablen nur für diesen Schritt fest. If you want to modify the environment variable stored in the workflow, use {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}`echo "{name}={value}" >> $GITHUB_ENV`{% else %}`echo "::set-env name={name}::{value}"`{% endif %} in a composite run step.
|
||||
|
||||
##### **`runs.steps.working-directory`**
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ versions:
|
||||
|
||||
### Fehler-Exit-Code in einer JavaScript-Aktion festlegen
|
||||
|
||||
Wenn Sie eine JavaScript-Aktion erstellen, können Sie mit dem Aktions-Toolkit [`@actions/core`](https://github.com/actions/toolkit/tree/master/packages/core) eine Meldung protokollieren und einen Fehler-Exit-Code festlegen. Ein Beispiel:
|
||||
Wenn Sie eine JavaScript-Aktion erstellen, können Sie mit dem Aktions-Toolkit [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) eine Meldung protokollieren und einen Fehler-Exit-Code festlegen. Ein Beispiel:
|
||||
|
||||
```javascript
|
||||
try {
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: Informationen zur fortlaufenden Integration
|
||||
intro: 'Sie können benutzerdefinierte Continuous Integration (CI) und Continuous Deployment (CD)-Workflows direkt in Ihrem {% data variables.product.prodname_dotcom %} Repository mit {% data variables.product.prodname_actions %}erstellen.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/about-continuous-integration
|
||||
- /github/automating-your-workflow-with-github-actions/about-continuous-integration
|
||||
- /actions/automating-your-workflow-with-github-actions/about-continuous-integration
|
||||
- /actions/building-and-testing-code-with-continuous-integration/about-continuous-integration
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zur fortlaufenden Integration
|
||||
|
||||
Bei der Softwarepraktik der fortlaufenden Integration (CI) erfolgen häufige Code-Commits an ein gemeinsames Repository. Code-Commits in kurzen Abständen tragen dazu bei, Fehler frühzeitiger aufzudecken, und verringern die Codemenge, die ein Entwickler auf der Suche nach der Fehlerursache debuggen muss. Durch häufige Code-Aktualisierungen lassen sich zudem Änderungen von verschiedenen Mitgliedern eines Software-Entwicklungsteams leichter zusammenführen. Dies bedeutet einen erheblichen Vorteil für die Entwickler, die sich damit stärker auf das Schreiben des Codes konzentrieren können, statt Fehler debuggen oder Mergekonflikte beheben zu müssen.
|
||||
|
||||
Durch einen Code-Commit an das Repository können Sie den Code fortlaufend erstellen und testen, sodass gewährleistet ist, dass der Commit keine Fehler einbringt. Die Tests können beispielsweise Code-Linters (überprüfen Stilformatierungen), Sicherheitsprüfungen, Code-Abdeckung, Funktionstests und andere benutzerdefinierte Prüfungen umfassen.
|
||||
|
||||
Zum Erstellen und Testen des Codes ist ein Server erforderlich. Sie können Aktualisierungen lokal erstellen und testen, bevor Sie den Code per Push an ein Repository senden, oder auch einen CI-Server heranziehen, der neue Code-Commits in einem Repository prüft.
|
||||
|
||||
### Informationen zur kontinuierlichen Integration mit {% data variables.product.prodname_actions %}
|
||||
|
||||
CI mit {% data variables.product.prodname_actions %} bietet Workflows, die den Code in Ihrem Repository erstellen und Ihre Tests ausführen können. Workflows können auf {% data variables.product.prodname_dotcom %}gehosteten virtuellen Maschinen oder auf Computern ausgeführt werden, die Sie selbst hosten. Weitere Informationen finden Sie unter "[Virtuelle Umgebungen für {% data variables.product.prodname_dotcom %}gehostete Läufer](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)" und "[über selbst gehostete Läufer](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)".
|
||||
|
||||
Sie können Ihren CI-Workflow so konfigurieren, dass er ausgeführt wird, wenn ein {% data variables.product.product_name %} Ereignis auftritt (z. B. wenn neuer Code an Ihr Repository übertragen wird), nach einem festgelegten Zeitplan oder wenn ein externes Ereignis mithilfe des Repository-Dispatch-Webhooks auftritt.
|
||||
|
||||
{% data variables.product.product_name %} führt die CI-Tests aus und stellt die Ergebnisse jedes Tests in der Pullanforderung bereit, sodass Sie sehen können, ob die Änderung in Ihrem Zweig einen Fehler verursacht. Sobald alle CI-Tests in einem Workflow bestanden wurden, können die per Push übermittelten Änderungen von einem Teammitglied geprüft oder zusammengeführt werden. Wenn ein Test nicht bestanden wird, liegt die Ursache eventuell in einer Ihrer Änderungen.
|
||||
|
||||
Wenn Sie CI in Ihrem Repository einrichten, analysiert {% data variables.product.product_name %} den Code in Ihrem Repository und empfiehlt CI-Workflows basierend auf der Sprache und dem Framework in Ihrem Repository. Wenn Sie beispielsweise [Node.js](https://nodejs.org/en/)verwenden, schlägt {% data variables.product.product_name %} eine Vorlagendatei vor, die Ihre Node.js-Pakete installiert und Ihre Tests ausführt. Sie können die von {% data variables.product.product_name %}vorgeschlagene CI-Workflowvorlage verwenden, die vorgeschlagene Vorlage anpassen oder eine eigene benutzerdefinierte Workflowdatei zum Ausführen der CI-Tests erstellen.
|
||||
|
||||
|
||||
|
||||
Sie können nicht nur ci-Workflows für Ihr Projekt einrichten, sondern auch {% data variables.product.prodname_actions %} verwenden, um Workflows über den gesamten Softwareentwicklungslebenszyklus hinweg zu erstellen. Sie können Ihr Projekt beispielsweise mithilfe von Aktionen bereitstellen, packen oder veröffentlichen. Weitere Informationen finden Sie unter "[über {% data variables.product.prodname_actions %}](/articles/about-github-actions)".
|
||||
|
||||
Eine Definition von gebräuchliche Begriffe finden Sie unter "[Kernkonzepte für {% data variables.product.prodname_actions %}](/github/automating-your-workflow-with-github-actions/core-concepts-for-github-actions)".
|
||||
|
||||
### Unterstützte Sprachen
|
||||
|
||||
{% data variables.product.product_name %} bietet CI-Workflowvorlagen für eine Vielzahl von Sprachen und Frameworks.
|
||||
|
||||
Browse the complete list of CI workflow templates offered by {% data variables.product.product_name %} in the {% if currentVersion == "free-pro-team@latest" %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
### Benachrichtigungen für Workflow-Läufe
|
||||
|
||||
{% data reusables.repositories.workflow-notifications %}
|
||||
|
||||
### Status-Badges für Workflow-Läufe
|
||||
|
||||
{% data reusables.repositories.actions-workflow-status-badge-into %}
|
||||
|
||||
Weitere Informationen finden Sie unter „[Einen Workflow konfigurieren](/articles/configuring-a-workflow)“.
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- "[Einrichtung einer kontinuierlichen Integration mit {% data variables.product.prodname_actions %}](/articles/setting-up-continuous-integration-using-github-actions)"
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
- „[Abrechnung für {{ site.data.variables.product.prodname_actions }} verwalten](/github/setting-up-and-managing-billing-and-payments-on-github/managing-billing-for-github-actions)“
|
||||
{% endif %}
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Informationen zum Paketieren mit GitHub-Aktionen
|
||||
intro: 'In {% data variables.product.prodname_actions %}kannst Du Workflows einrichten, um Pakete zu erstellen und sie zu {% data variables.product.prodname_registry %} oder einem anderen Paket-Hosting-Anbieter hochzuladen.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/about-packaging-with-github-actions
|
||||
- /actions/publishing-packages-with-github-actions/about-packaging-with-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu Paketierungsschritten
|
||||
|
||||
Die Paket-Erstellung ist ein üblicher Bestandteil des Workflows bei der kontinuierlichen Integration oder bei der kontinuierlichen Auslieferung. Nach dem Erstellen und Testen der Anwendung wird ein lauf- oder bereitstellungsfähiges Artefakt als Paket erstellt. Beispielsweise kann ein Workflow zur kontinuierlichen Integration für ein Java-Projekt `mvn package` ausführen, um eine JAR-Datei zu erstellen. Oder ein CI-Workflow für eine Node.js-Anwendung kann einen Docker-Container erzeugen.
|
||||
|
||||
Je nach Art der Anwendung, die Du erstellst, kann dieses Paket für manuelle Tests lokal heruntergeladen, Benutzern zum Herunterladen zur Verfügung gestellt oder in einer Staging- oder Produktionsumgebung bereitgestellt werden.
|
||||
|
||||
### Paket-Erstellung in Workflows zur kontinuierlichen Integration
|
||||
|
||||
Das Erstellen eines Pakets am Ende eines Workflows zur kontinuierlichen Integration kann während des Code-Reviews bei einem Pull-Request hilfreich sein. Nach dem Erstellen und Testen Deines Codes kann ein Paketierungsschritt ein lauf- oder bereitstellungsfähiges Artefakt erzeugen. Dein Workflow kann dieses Artefakt dann übernehmen und als Teil des Workflows hochladen.
|
||||
|
||||
Wenn Du nun einen Pull-Request überprüfst, kannst Du Dir den Ablauf des Workflows ansehen und das erzeugte Artefakt herunterladen.
|
||||
|
||||
|
||||
|
||||
Dadurch kannst Du den Code im Pull-Request auf Deinem Rechner ausführen, was beim Debuggen oder Testen des Pull-Requests helfen kann.
|
||||
|
||||
### Workflows zum Veröffentlichen von Paketen
|
||||
|
||||
Außer Paket-Artefakte zum Testen in einem Workflow zur kontinuierlichen Integration zum Testen hochzuladen, kannst Du auch Workflows erstellen, die Dein Projekt bauen und Pakete in einer Paket-Registry veröffentlichen.
|
||||
|
||||
* **Publish packages to {% data variables.product.prodname_registry %}**
|
||||
{% data variables.product.prodname_registry %} can act as a package hosting service for many types of packages. Du kannst Deine Pakete entweder mit allen {% data variables.product.prodname_dotcom %} oder private Pakete nur mit Mitarbeitern oder einer Organisation teilen. Weitere Informationen findest Du unter „[Informationen zu {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages/about-github-packages)“.
|
||||
|
||||
You may want to publish packages to {% data variables.product.prodname_registry %} on every push into the default branch. Auf diese Weise können Entwickler in Deinem Projekt immer den neuesten Build aus Master ausführen und testen, indem sie ihn von {% data variables.product.prodname_registry %} installieren.
|
||||
|
||||
* **Pakete in einer Paket-Registry veröffentlichen** Bei vielen Projekten werden neue Versionen immer in einer Paket-Registry veröffentlicht. Beispielsweise kann ein Projekt, das eine JAR-Datei erstellt, neue Versionen in das Zentral-Repository von Maven hochladen. Oder ein .NET-Projekt kann ein NuGet-Paket erzeugen und es in die NuGet-Galerie hochladen.
|
||||
|
||||
Du kannst dies automatisieren, indem Du einen Workflow erstellst, der bei jeder Release-Erstellung Pakete in einer Paket-Registry veröffentlicht. Weitere Informationen findest Du unter „[Releases erstellen](/github/administering-a-repository/creating-releases)“.
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- „[Node.js-Pakete veröffentlichen](/actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages)“
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Informationen zu Service-Containern
|
||||
intro: 'Du kannst Service-Container verwenden, um Datenbanken, Webdienste, Speicher-Caches und andere Tools mit Deinem Workflow zu verbinden.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/about-service-containers
|
||||
- /actions/configuring-and-managing-workflows/about-service-containers
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu Service-Containern
|
||||
|
||||
Service-Container sind Docker-Container, die Dir eine einfache und portable Möglichkeit bieten, Dienste zu hosten, um Deine Anwendung in einem Workflow zu testen oder zu betreiben. Beispielsweise muss Dein Workflow möglicherweise Integrationstests ausführen, die Zugriff auf eine Datenbank und einen Speicher-Cache erfordern.
|
||||
|
||||
Du kannst Service-Container für jeden Job in einem Workflow konfigurieren. Für jeden Service, der im Workflow konfiguriert ist, erstellt {% data variables.product.prodname_dotcom %} einen neuen Docker-Container und löscht den Service Container, wenn der Auftrag abgeschlossen ist. Steps (Schritte) in einem Job können mit allen Service-Containern kommunizieren, die Teil des gleichen Jobs sind.
|
||||
|
||||
{% data reusables.github-actions.docker-container-os-support %}
|
||||
|
||||
### Mit Service-Containern kommunizieren
|
||||
|
||||
Du kannst Jobs in einem Workflow so konfigurieren, dass sie direkt auf einer Runner-Maschine oder in einem Docker-Container laufen. Die Kommunikation zwischen einem Job und seinen Service-Containern ist unterscherschiedlich, je nachdem, ob ein Job direkt auf der Runner-Maschine oder in einem Container läuft.
|
||||
|
||||
#### Jobs in einem Container ausführen
|
||||
|
||||
Wenn Du Jobs in einem Container ausführst, verbindet {% data variables.product.prodname_dotcom %} die Service-Container mit dem Job über die benutzerdefinierten Bridge-Netzwerke von Docker. Weitere Informationen findest Du unter "[Bridge-Netzwerke verwenden](https://docs.docker.com/network/bridge/)" in der Docker-Dokumentation.
|
||||
|
||||
Jobs und der Services in einem Container laufen zu lassen, vereinfacht den Netzwerkzugriff. Du kannst auf einen Service-Container mittels des Labels (Bezeichnung) zugreifen, den Du im Workflow konfigurierst. Der Hostname des Service-Containers wird automatisch dem Labelnamen zugeordnet. Wenn Du z.B. einen Service-Container mit der Bezeichnung `Redis` erstellst, ist auch der Hostname des Service-Containers `Redis`.
|
||||
|
||||
Du brauchst für Service-Container keine Ports zu konfigurieren. Standardmäßig machen alle Container, die Teil desselben Docker-Netzwerks sind, alle Ports füreinander verfügbar, und außerhalb des Docker-Netzwerks werden keine Ports verfügbar gemacht.
|
||||
|
||||
#### Jobs auf der Runner-Maschine ausführen
|
||||
|
||||
Wenn Du Jobs direkt auf der Runner-Maschine ausführst, kannst Du auf Service-Container mit `localhost:<port>` oder `127.0.0.1:<port>` zugreifen. {% data variables.product.prodname_dotcom %} konfiguriert das Container-Netzwerk, um die Kommunikation vom Service-Container zum Docker-Host zu ermöglichen.
|
||||
|
||||
Wenn ein Job direkt auf einer Runner-Maschine läuft, macht der im Docker-Container laufende Dienst seine Ports nicht standardmäßig dem Job auf dem Runner verfügbar. Du musst Ports auf dem Service-Container dem Docker Host zuordnen. Weitere Informationen findest Du unter "[Ports auf Docker-Host und Service-Container zuordnen](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)."
|
||||
|
||||
### Service-Container erstellen
|
||||
|
||||
Du kannst das Schlüsselwort `Services` verwenden, um Service-Container zu erstellen, die Teil eines Jobs in Deinem Workflow sind. Weitere Informationen findest Du unter [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices).
|
||||
|
||||
Dieses Beispiel erstellt einen Dienst namens `redis` in einem Job namens `container-job`. Der Docker-Host in diesem Beispiel ist der Container `node:10.18-jessie`.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Redis container example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
container-job:
|
||||
# Container müssen in Linux-basierten Betriebssystemen laufen
|
||||
runs-on: ubuntu-latest
|
||||
# Docker-Hub-Image in dem `container-job` laeuft
|
||||
container: node:10.18-jessie
|
||||
|
||||
# Service-Container, mit denen `container-job` laeuft
|
||||
services:
|
||||
# Label zum Zugriff auf den Service--Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Ports von Docker-Host und Service-Container zuordnen
|
||||
|
||||
Wenn Dein Job in einem Docker-Container läuft, brauchst Du keine Ports auf dem Host oder dem Service-Container zuzuordnen. Wenn Dein Job direkt auf der Runner-Maschine läuft, musst Du alle benötigten Service-Container-Ports zu Ports der Host-Runner-Maschine zuordnen.
|
||||
|
||||
Du kannst Service-Container-Ports mit Hilfe des Schlüsseworts `ports` dem Docker-Host zuordnen. Weitere Informationen findest Du unter [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices).
|
||||
|
||||
| Wert von `ports` | Beschreibung |
|
||||
| ---------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| `8080:80` | Ordnet TCP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu. |
|
||||
| `8080:80/udp` | Ordnet UDP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu. |
|
||||
| `8080/udp` | Ordnet einen zufällig gewählten UDP-Port im Container dem UDP-Port 8080 auf dem Docker-Host zu. |
|
||||
|
||||
Wenn Du Ports mittels `ports` zuordnest, publiziert {% data variables.product.prodname_dotcom %} die Ports des Containers auf dem Docker-Host mit dem Befehl `--publish`. Weitere Informationen findest Du unter "[Vernetzung von Docker-Containern](https://docs.docker.com/config/containers/container-networking/)" in der Docker Dokumentation.
|
||||
|
||||
Wenn Du den Port des Docker-Hosts angibst, aber nicht den des Containers, dann wird der Container-Port zufällig einem freien Port zugewiesen. {% data variables.product.prodname_dotcom %} setzt den zugewiesenen Container-Port im Kontext des Service-Containers. Wenn Du beispielsweise den Port 5432 für den Docker-Host konfiguriert hast, kannst Du für einen Service Container `redis` mit dem Kontext code>job.services.redis.ports[5432]</code> auf den entsprechenden Port des Containers zugreifen. Weitere Informationen findest Du unter "[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#job-context)."
|
||||
|
||||
#### Beispiel zur Zuordnung von Redis-Ports
|
||||
|
||||
Dieses Beispiel ordnet den Port 6379 des Service-Containers `redis` dem Port 6379 des Docker-Hosts zu.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Redis Service Example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
runner-job:
|
||||
# Fuer Service-Containers oder Container-Jobs musst Du eine Linux-Umgebung benutzen
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# Service-Container, die mit `runner-job` laufen sollen
|
||||
services:
|
||||
# Label zum Zugriff auf den Service-Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
#
|
||||
ports:
|
||||
# Oeffnet TCP-Port 6379 auf dem Host und Service-Container
|
||||
- 6379:6379
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- "[Redis-Service-Container erstellen](/actions/automating-your-workflow-with-github-actions/creating-redis-service-containers)"
|
||||
- "[PostgreSQL-Service-Container erstellen](/actions/automating-your-workflow-with-github-actions/creating-postgresql-service-containers)"
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: Java bauen und testen mit Ant
|
||||
intro: Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Ant zu bauen und zu testen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/building-and-testing-java-with-ant
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Build-Systems Ant durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Artefakte von einem Workflow-Lauf hochlädt.
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Ant. For a list of software and the pre-installed versions for JDK and Ant, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
|
||||
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
|
||||
Du solltest ein grundlegendes Verständnis von Java und dem Framework Ant haben. Weitere Informationen findest Du im [Handbuch zu Apache Ant](https://ant.apache.org/manual/).
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
### Einstieg mit einer Ant-Workflow-Vorlage
|
||||
|
||||
{% data variables.product.prodname_dotcom %} bietet eine Ant-Workflow-Vorlage, die für die meisten Ant-basierten Java-Projekte funktionieren wird. For more information, see the [Ant workflow template](https://github.com/actions/starter-workflows/blob/main/ci/ant.yml).
|
||||
|
||||
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Ant-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
|
||||
|
||||
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Java CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up JDK 1.8
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Build with Ant
|
||||
run: ant -noinput -buildfile build.xml
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
|
||||
2. Der Schritt `setup-java` konfiguriert das Java 1.8 JDK.
|
||||
3. Der Schritt „Build with Ant“ (mittels Ant bauen) führt das standardmäßige „Target“ (Ziel) in Deiner `build.xml` im nicht-interaktiven Modus aus.
|
||||
|
||||
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
|
||||
|
||||
{% data reusables.github-actions.example-github-runner %}
|
||||
|
||||
{% data reusables.github-actions.java-jvm-architecture %}
|
||||
|
||||
### Deinen Code bauen und testen
|
||||
|
||||
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
|
||||
|
||||
Der Starter-Workflow führt das in der Datei _build.xml_ angegebene „default target“ (Standardziel) aus. Dein Standard-Ziel wird normalerweise eingestellt, um Klassen zu bauen, Tests durchzuführen und Klassen in ihr verteilbares Format (z.B . eine JAR-Datei) zu paketieren.
|
||||
|
||||
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder ein anderes Ziel auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise das Ziel `jar` ausführen, das in Deiner Datei _build-ci.xml_ konfiguriert ist.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Run the Ant jar target
|
||||
run: ant -noinput -buildfile build-ci.xml jar
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Workflow-Daten als Artefakte paketieren
|
||||
|
||||
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
|
||||
|
||||
Ant erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `build/jar`. Du kannst den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
- run: ant -noinput -buildfile build.xml
|
||||
- uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: Package
|
||||
path: build/jar
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: Java bauen und testen mit Gradle
|
||||
intro: Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Gradle zu bauen und zu testen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/building-and-testing-java-with-gradle
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Build-Systems Gradle durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Dateien im Cache zwischenspeichert und Artefakte von einem Workflow-Lauf hochlädt.
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Gradle. For a list of software and the pre-installed versions for JDK and Gradle, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
|
||||
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
|
||||
Du solltest ein grundlegendes Verständnis von Java und dem Framework Gradle haben. Weitere Informationen findest Du unter [Erste Schritte](https://docs.gradle.org/current/userguide/getting_started.html) in der Gradle-Dokumentation.
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
### Einstieg mit einer Gradle-Workflow-Vorlage
|
||||
|
||||
{% data variables.product.prodname_dotcom %} bietet eine Gradle-Workflow-Vorlage, die für die meisten Gradle-basierten Java-Projekte funktionieren wird. For more information, see the [Gradle workflow template](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml).
|
||||
|
||||
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Gradle-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
|
||||
|
||||
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Java CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up JDK 1.8
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Build with Gradle
|
||||
run: ./gradlew build
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
|
||||
2. Der Schritt `setup-java` konfiguriert das Java 1.8 JDK.
|
||||
3. Der Schritt "Build with Gradle" führt das Wrapper-Skript `gradlew` aus, um sicherzustellen, dass dein Code gebaut, Tests bestanden und ein Paket erstellt werden kann.
|
||||
|
||||
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
|
||||
|
||||
{% data reusables.github-actions.example-github-runner %}
|
||||
|
||||
{% data reusables.github-actions.java-jvm-architecture %}
|
||||
|
||||
### Deinen Code bauen und testen
|
||||
|
||||
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
|
||||
|
||||
Der Starter-Workflow führt standardmäßig den Task `build` aus. In der Standard-Gradle-Konfiguration lädt dieser Befehl Abhängigkeiten herunter, baut Klassen, führt Tests durch und paketiert Klassen in ihr verteilbares Format, zum Beispiel eine JAR-Datei.
|
||||
|
||||
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder einen anderen Task auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise den Task `package` ausführen, der in Deiner Datei _ci.gradle_ konfiguriert ist.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Run the Gradle package task
|
||||
run: ./gradlew -b ci.gradle package
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Abhängigkeiten „cachen“ (zwischenspeichern)
|
||||
|
||||
Du kannst Deine Abhängigkeiten zwischenspeichern, um die Workflow-Ausführungen zu beschleunigen. Nach einem erfolgreichen Lauf wird Dein lokaler Paket-Cache von Gradle in der Aktions-Infrastruktur auf GitHub gespeichert. Bei zukünftigen Workflow-Ausführungen wird der Cache wiederhergestellt, so dass Abhängigkeiten nicht aus entfernten Paket-Repositories heruntergeladen werden müssen. Weitere Informationen findest Du unter „[Caching-Abhängigkeiten zur Beschleunigung von Workflows](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)“ und der [Aktion `cache`](https://github.com/marketplace/actions/cache).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up JDK 1.8
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Cache Gradle packages
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
path: ~/.gradle/caches
|
||||
key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
|
||||
restore-keys: ${{ runner.os }}-gradle
|
||||
- name: Build with Gradle
|
||||
run: ./gradlew build
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow speichert den Inhalt Deines lokalen Gradle-Package-Caches im Verzeichnis `.gradle/caches` des Home-Verzeichnisses auf dem Runner. Der Cache-Schlüssel wird der gehashte Inhalt der Gradle-Build-Dateien sein, so dass Änderungen an ihnen den Cache ungültig machen.
|
||||
|
||||
### Workflow-Daten als Artefakte paketieren
|
||||
|
||||
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
|
||||
|
||||
Gradle erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `build/libs`. Du kannst den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
- run: ./gradlew build
|
||||
- uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: Package
|
||||
path: build/libs
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
title: Java bauen und testen mit Maven
|
||||
intro: Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Maven zu bauen und zu testen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/building-and-testing-java-with-maven
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Software-Projektmanagement-Tools Maven durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Dateien im Cache zwischenspeichert und Artefakte von einem Workflow-Lauf hochlädt.
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Maven. For a list of software and the pre-installed versions for JDK and Maven, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
|
||||
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
|
||||
Du solltest ein grundlegendes Verständnis von Java und dem Framework Maven haben. Weitere Informationen findest Du in der [Anleitung für erste Schritte mit Maven](http://maven.apache.org/guides/getting-started/index.html) in der Maven-Dokumentation.
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
### Einstieg mit einer Maven-Workflow-Vorlage
|
||||
|
||||
{% data variables.product.prodname_dotcom %} bietet eine Maven-Workflow-Vorlage, die für die meisten Maven-basierten Java-Projekte funktionieren wird. Weitere Informationen findest Du im [Workflow-Template für Maven](https://github.com/actions/starter-workflows/blob/main/ci/maven.yml).
|
||||
|
||||
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Maven-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
|
||||
|
||||
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Java CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up JDK 1.8
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Build with Maven
|
||||
run: mvn -B package --file pom.xml
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
|
||||
2. Der Schritt `setup-java` konfiguriert das Java 1.8 JDK.
|
||||
3. Der Schritt "Build with Maven" führt das Maven-„Target“ (Ziel) `package` im nicht-interaktiven Modus aus, um sicherzustellen, dass der Code gebaut, Tests bestanden und ein Paket erstellt werden kann.
|
||||
|
||||
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
|
||||
|
||||
{% data reusables.github-actions.example-github-runner %}
|
||||
|
||||
{% data reusables.github-actions.java-jvm-architecture %}
|
||||
|
||||
### Deinen Code bauen und testen
|
||||
|
||||
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
|
||||
|
||||
Der Starter-Workflow führt standardmäßig das „target“ (Ziel) `package` aus. In der Standard-Maven-Konfiguration lädt dieser Befehl Abhängigkeiten herunter, baut Klassen, führt Tests durch und paketiert Klassen in ihr verteilbares Format, zum Beispiel eine JAR-Datei.
|
||||
|
||||
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder ein anderes Ziel auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise das Ziel `verify` ausführen, das in Deiner Datei _pom-ci.xml_ konfiguriert ist.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Run the Maven verify phase
|
||||
run: mvn -B verify --file pom-ci.xml
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Abhängigkeiten „cachen“ (zwischenspeichern)
|
||||
|
||||
Du kannst Deine Abhängigkeiten zwischenspeichern, um die Workflow-Ausführungen zu beschleunigen. Nach einem erfolgreichen Lauf wird Dein lokales Maven-Repository in der Aktions-Infrastruktur auf GitHub gespeichert. Bei zukünftigen Workflow-Ausführungen wird der Cache wiederhergestellt, so dass Abhängigkeiten nicht aus entfernten Maven-Repositories heruntergeladen werden müssen. Weitere Informationen findest Du unter „[Caching-Abhängigkeiten zur Beschleunigung von Workflows](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)“ und der [Aktion `cache`](https://github.com/marketplace/actions/cache).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up JDK 1.8
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Cache Maven packages
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
path: ~/.m2
|
||||
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
|
||||
restore-keys: ${{ runner.os }}-m2
|
||||
- name: Build with Maven
|
||||
run: mvn -B package --file pom.xml
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow speichert den Inhalt Deines lokalen Maven-Repositiorys im Verzeichnis `.m2` des Home-Verzeichnisses auf dem Runner. Der Cache-Schlüssel wird der gehashte Inhalt von _pom.xml_sein, so dass Änderungen an _pom.xml_ den Cache ungültig machen.
|
||||
|
||||
### Workflow-Daten als Artefakte paketieren
|
||||
|
||||
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
|
||||
|
||||
Maven erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `target`. Um diese als Artefakte hochzuladen, kannst du sie in ein neues Verzeichnis kopieren, welches Artefakte zum Hochladen enthält. Zum Beispiel kannst Du ein Verzeichnis namens `staging` erstellen. Dann kannst Du den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
- run: mvn -B package --file pom.xml
|
||||
- run: mkdir staging && cp target/*.jar staging
|
||||
- uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: Package
|
||||
path: staging
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -0,0 +1,276 @@
|
||||
---
|
||||
title: Building and testing Node.js
|
||||
intro: Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Dein Node.js-Projekt zu bauen und zu testen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/using-nodejs-with-github-actions
|
||||
- /actions/language-and-framework-guides/using-nodejs-with-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Diese Anleitung zeigt Dir, wie Du einen Workflow für fortlaufende Integration (CI) erstellen kannst, der Node.js-Code baut und testet. Wenn Deine CI-Tests erfolgreich durchlaufen, kannst Du Deinen Code deployen (bereitstellen) oder ein Paket veröffentlichen.
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Wir empfehlen, dass Du ein grundlegendes Verständnis von Node.js, YAML, Workflowkonfigurations-Optionen und die Erstellung einer Workflow-Datei hast. Weitere Informationen findest Du unter:
|
||||
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
- "[Getting started with Node.js](https://nodejs.org/en/docs/guides/getting-started-guide/)"
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
### Einstieg mit einer Node.js-Workflow-Vorlage
|
||||
|
||||
{% data variables.product.prodname_dotcom %} bietet eine Node.js-Workflow-Vorlage, die für die meisten Node.js-basierten Projekte funktionieren wird. Diese Anleitung enthält npm und Yarn Beispiele, mit denen Du die Vorlage anpassen kannst. Weitere Informationen findest Du in der [Node.js-Workflow-Vorlage](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml).
|
||||
|
||||
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [8.x, 10.x, 12.x]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
- run: npm install
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
env:
|
||||
CI: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.example-github-runner %}
|
||||
|
||||
### Die Node.js-Version angeben
|
||||
|
||||
Der einfachste Weg, eine Node.js-Version anzugeben, ist die Aktion `setup-node` von {% data variables.product.prodname_dotcom %} zu verwenden. Weitere Informationen findest Du unter [`setup-node`](https://github.com/actions/setup-node/).
|
||||
|
||||
Die Aktion `setup-node` nimmt eine Node.js-Version als Eingabe und konfiguriert diese Version auf dem Runner. Die Aktion `setup-node` findet auf jedem Runner eine bestimmte Version von Node.js aus dem Tools-Cache und legt die notwendigen Binärdateien im `PATH` ab, wo sie für den Rest des Jobs bestehen bleiben. Für Node.js mit {% data variables.product.prodname_actions %} wird empfohlen, die Aktion `setup-node` zu verwenden, weil dadurch über verschiedenen Runner und verschiedenen Versionen von Node.js hinweg ein konsistentes Verhalten sicherstellt wird. Wenn Du einen selbst gehosteten Runner verwendest, musst Du Node.js installieren und zum `PATH` hinzufügen.
|
||||
|
||||
Die Vorlage enthält eine Matrix-Strategie, die Deinen Code mit drei Node.js-Versionen baut und testet: 8.x, 10.x und 12.x. Das 'x' ist ein Platzhalterzeichen, für das neueste Minor- und Patch-Release des jeweiligen Major-Releases steht. The 'x' is a wildcard character that matches the latest minor and patch release available for a version. Jede Version von Node.js, die im Array `node-version` festgelegt ist, erstellt einen Job, der die gleichen Schritte ausführt.
|
||||
|
||||
Jeder Job in der Matrix kann mithilfe des `Matrix`-Kontexts auf den im Array `node-version` definierten Wert zugreifen. Die Aktion `setup-node` verwendet den Kontext als Eingabe für `node-version`. Die Aktion `setup-node` konfiguriert jeden Job mit einer anderen Node.js-Version bevor sie den Code baut und testet. Weitere Informationen zu Matrix-Strategien und Kontexten findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)“ und „[Kontext- und Ausdruckssyntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [8.x, 10.x, 12.x]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Alternativ kannnst Du auch mit genauen Node.js-Versionen bauen und testen.
|
||||
|
||||
```yaml
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [8.16.2, 10.17.0]
|
||||
```
|
||||
|
||||
Oder Du kannst auch mithilfe einer einzelnen Version von Node.js bauen und testen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- run: npm install
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
env:
|
||||
CI: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Wenn Du keine Node.js Version festlegst, verwendet {% data variables.product.prodname_dotcom %} die standardmäßige Node.js Version der Umgebung. For more information, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Abhängigkeiten installieren
|
||||
|
||||
Auf {% data variables.product.prodname_dotcom %}-gehosteten Runnern sind die Abhängigkeitsmanager npm und Yarn installiert. Du kannst npm und Yarn verwenden, um in Ihrem Workflow Abhängigkeiten zu installieren, bevor Du Deinen Code baust und testest. Die auf {% data variables.product.prodname_dotcom %} gehosteten Windows- und Linux-Runner haben auch Grunt, Gulp und Bower installiert.
|
||||
|
||||
Du kannst Abhängigkeiten auch im Cache zwischenspeichern, um Deinen Workflow zu beschleunigen. Weitere Informationen findest Du unter „[Abhängigkeiten im Cache zwischenspeichern, um Deinen Workflow zu beschleunigen](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)“.
|
||||
|
||||
#### Beispiel mit npm
|
||||
|
||||
Dieses Beispiel installiert die Abhängigkeiten, die in der Datei *package.json* definiert sind. Weitere Informationen findest Du unter [`npm install`](https://docs.npmjs.com/cli/install).
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Install dependencies
|
||||
run: npm install
|
||||
```
|
||||
|
||||
Du kannst mithilfe `npm ci` die Versionen in der Datei *package-lock.json* oder *npm-shrinkwrap.json* installieren und Aktualisierungen der Sperrdatei verhindern. `npm ci` zu verwenden ist gewöhnlich schneller als `npm install` laufen zu lassen. Weitere Informationen findest Du unter [`npm ci`](https://docs.npmjs.com/cli/ci.html) und „[Einführung in `npm ci` für schnellere und zuverlässigere Builds](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)“.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Beispiel mit Yarn
|
||||
|
||||
Dieses Beispiel installiert die Abhängigkeiten, die in der Datei *package.json* definiert sind. Weitere Informationen findest Du unter [`Yarn-Installation`](https://yarnpkg.com/en/docs/cli/install).
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Install dependencies
|
||||
run: yarn
|
||||
```
|
||||
|
||||
Alternativ kannst Du `--frozen-lockfile` übergeben, um die Versionen in der Datei *yarn.lock* zu installieren und Aktualisierungen der Datei *yarn.lock* zu verhindern.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Install dependencies
|
||||
run: yarn --frozen-lockfile
|
||||
```
|
||||
|
||||
#### Beispiel mit einer privaten Registry und Erstellung der Datei .npmrc
|
||||
|
||||
{% data reusables.github-actions.setup-node-intro %}
|
||||
|
||||
Um Dich bei Deiner privaten Registry zu authentifizieren, musst Du in Deinen Repository-Einstellungen Dein npm-Authentifizierungs-Token als Geheimnis ablegen. Erstelle z.B. ein Geheimnis namens `NPM_TOKEN`. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
Im folgenden Beispiel enthält das Geheimnis `NPM_TOKEN` den npm-Authentifizierungs-Token. Die Aktion `setup-node` konfiguriert die Datei *.npmrc*, um den npm-Authentifizierung-Token aus der Umgebungsvariablen `NODE_AUTH_TOKEN` zu lesen. Wenn Du die Aktion `setup-node` verwendest, um eine Datei *.npmrc* zu erstellen, musst Du die Umgebungsvariable `NPM_AUTH_TOKEN` auf das Geheimnis setzen, das Deinen npm-Authentifizierungs-Token enthält.
|
||||
|
||||
Bevor Du Abhängigkeiten installierst, verwende die Aktion `setup-node`, um die Datei *.npmrc* zu erstellen. Die Aktion hat zwei Eingabeparameter. Der Parameter `node-version` legt die Version von Node.js fest und der Parameter `registry-url` bestimmt die Standard-Registry. Wenn Deine Paket-Registry Geltungsbereiche verwendet, musst Du den Parameter `scope` verwenden. Weitere Informationen findest Du unter [`npm-scope`](https://docs.npmjs.com/misc/scope).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
always-auth: true
|
||||
node-version: '12.x'
|
||||
registry-url: https://registry.npmjs.org
|
||||
scope: '@octocat'
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Das obige Beispiel erzeugt eine *.npmrc* Datei mit folgendem Inhalt:
|
||||
|
||||
```
|
||||
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
|
||||
@octocat:registry=https://registry.npmjs.org/
|
||||
always-auth=true
|
||||
```
|
||||
|
||||
#### Beispiel zum Zwischenspeichern von Abhängigkeiten im Cache
|
||||
|
||||
Du kannst Abhängigkeiten mit einem eindeutigen Schlüssel im Cache zwischenspeichern und sie später wiederherstellen, wenn Du zukünftige Workflows mit der Aktion `-cache-` ausführst. Weitere Informationen findest Du unter „[Caching-Abhängigkeiten zur Beschleunigung von Workflows](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)“ und der [Aktion `cache`](https://github.com/marketplace/actions/cache).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Cache Node.js modules
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
# npm cache files are stored in `~/.npm` on Linux/macOS
|
||||
path: ~/.npm
|
||||
key: ${{ runner.OS }}-node-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: |
|
||||
${{ runner.OS }}-node-
|
||||
${{ runner.OS }}-
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Deinen Code bauen und testen
|
||||
|
||||
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen. Wenn Du beispielsweise `npm run build` ausführst, um die in Deinem *package.json* definierten Build-Schritte zu durchlaufen, und `npm test`, um Deine Testsuite laufen zu lassen, dann fügst Di diese Befehle in Deine Workflow-Datei ein.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js
|
||||
uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- run: npm install
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
```
|
||||
|
||||
### Workflow-Daten als Artefakte paketieren
|
||||
|
||||
Du kannst Artefakte aus deinen Build- und Testschritten speichern, um sie nach dem Abschluss eines Jobs anzuzeigen. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
|
||||
|
||||
### In Paket-Registries veröffentlichen
|
||||
|
||||
Du kannst Deinen Workflow so konfigurieren, dass Dein Node.js-Paket nach Bestehen Deiner CI-Tests in einer Paket-Registry veröffentlicht wird. Weitere Informationen zum Veröffentlichen in npm und {% data variables.product.prodname_registry %} findest Du unter „[Node.js Pakete veröffentlichen](/actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages)“.
|
||||
@@ -0,0 +1,427 @@
|
||||
---
|
||||
title: Building and testing Python
|
||||
intro: Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Dein Python-Projekt zu bauen und zu testen.
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/using-python-with-github-actions
|
||||
- /actions/language-and-framework-guides/using-python-with-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Diese Anleitung zeigt Dir, wie Du ein Python-Paket baust, testest und veröffentlichst.
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-gehostete Runner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Python und PyPy. Du brauchst nichts zu installieren! For a full list of up-to-date software and the pre-installed versions of Python and PyPy, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
Du solltest ein grundlegendes Verständnis von Python, PyPy und pip haben. Weitere Informationen findest Du unter:
|
||||
- [Erste Schritte mit Python](https://www.python.org/about/gettingstarted/)
|
||||
- [PyPy](https://pypy.org/)
|
||||
- [Paketmanager pip](https://pypi.org/project/pip/)
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
### Einstieg mit der Python-Workflow-Vorlage
|
||||
|
||||
{% data variables.product.prodname_dotcom %} bietet eine Python-Workflow-Vorlage, die für die meisten Python-Projekte funktionieren sollte. Diese Anleitung enthält Beispiele, mit denen Du die Vorlage anpassen kannst. Weitere Informationen findest Du in der [Python-Workflow-Vorlage](https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml).
|
||||
|
||||
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: [2.7, 3.5, 3.6, 3.7, 3.8]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python ${{ matrix.python-version }}
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install flake8 pytest
|
||||
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
|
||||
- name: Lint with flake8
|
||||
run: |
|
||||
# stop the build if there are Python syntax errors or undefined names
|
||||
flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
|
||||
# exit-zero behandelt alle Fehler als Warnungen. Der GitHub-Editor ist 127 Zeichen breit
|
||||
flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
|
||||
- name: Test with pytest
|
||||
run: |
|
||||
pytest
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Eine Python-Version angeben
|
||||
|
||||
Benutze die Aktion `setup-python`, um eine vorinstallierte Version von Python oder PyPy auf einem {% data variables.product.prodname_dotcom %}-gehosteten Runner zu verwenden. Diese Aktion findet aus dem Tool-Cache auf jedem Runner eine bestimmte Version von Python oder PyPy und fügt die benötigten Binärdateien zum `PATH`hinzu, der für den Rest des Jobs bestehen bleibt. Wenn eine bestimmte Version von Python nicht im Tools-Cache vorinstalliert ist, lädt die Aktion `setup-python` die entsprechende Version vom [Repository `python-versions`](https://github.com/actions/python-versions) herunter und richtet sie ein.
|
||||
|
||||
Die `setup-action` ist die empfohlene Methode, Python mit {% data variables.product.prodname_actions %} zu verwenden, da dadurch ein einheitliches Verhalten der verschiedenen Runner und verschiedenen Versionen von Python gewährleistet wird. Wenn Du einen selbst gehosteten Runner verwendest, musst Du Python installieren und zum `PATH` hinzufügen. Weitere Informationen findest Du in der [Aktion `setup-python`](https://github.com/marketplace/actions/setup-python).
|
||||
|
||||
Die folgende Tabelle zeigt für jeden {% data variables.product.prodname_dotcom %}-gehosteten Runner, wo der Tools-Cache liegt.
|
||||
|
||||
| | Ubuntu | Mac | Windows |
|
||||
| -------------------------- | ------------------------------- | ---------------------------------------- | ------------------------------------------ |
|
||||
| **Tool-Cache-Verzeichnis** | `/opt/hostedtoolcache/*` | `/Users/runner/hostedtoolcache/*` | `C:\hostedtoolcache\windows\*` |
|
||||
| **Tool-Cache für Python** | `/opt/hostedtoolcache/Python/*` | `/Users/runner/hostedtoolcache/Python/*` | `C:\hostedtoolcache\windows\Python\*` |
|
||||
| **Tool-Cache für PyPy** | `/opt/hostedtoolcache/PyPy/*` | `/Users/runner/hostedtoolcache/PyPy/*` | `C:\hostedtoolcache\windows\PyPy\*` |
|
||||
|
||||
Wenn Du einen selbst gehosteten Runner verwendest, kannst Du den Runner so konfigurieren, dass er mithilfe der Aktion `setup-python` Deine Abhängigkeiten verwaltet. Weitere Informationen findest Du unter [setup-python mit einem selbst-gehosteten Runner verwenden](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner) in der README von `setup-python`.
|
||||
|
||||
{% data variables.product.prodname_dotcom %} unterstützt dir Syntax für semantische Versionierung. Weitere Informationen findest Du unter „[Semantische Versionierung verwenden](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept)“ und „[Spezifikation für semantische Versionierung](https://semver.org/)“.
|
||||
|
||||
#### Mehrere Python-Versionen verwenden
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
# Du kannst in python-version die PyPy-Versionen angeben,
|
||||
# For example, pypy2 and pypy3
|
||||
matrix:
|
||||
python-version: [2.7, 3.5, 3.6, 3.7, 3.8]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python ${{ matrix.python-version }}
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
# Du kannst Deine Matrix durch Ausgabe der aktuellen Python-Version testen
|
||||
- name: Display Python version
|
||||
run: python -c "import sys; print(sys.version)"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Eine bestimmten Python-Version verwenden
|
||||
|
||||
Du kannst eine bestimmte Version von Python konfigurieren, For example, 3.8. Alternativ kannst Du auch Syntax für semantische Versionierung verwenden, um das neuste Minor Release zu erhalten. Dieses Beispiel verwendet das neueste Minor Release von Python 3.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python 3.x
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
# Semantic version range syntax or exact version of a Python version
|
||||
python-version: '3.x'
|
||||
# Optional - x64 or x86 architecture, defaults to x64
|
||||
architecture: 'x64'
|
||||
# You can test your matrix by printing the current Python version
|
||||
- name: Display Python version
|
||||
run: python -c "import sys; print(sys.version)"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Eine Version ausschließen
|
||||
|
||||
Wenn du eine Version von Python angibst, die nicht verfügbar ist, schlägt `setup-python` fehl und meldet in etwa: `##[error]Version 3.4 with arch x64 not found`. Die Fehlermeldung enthält die verfügbaren Versionen.
|
||||
|
||||
Du kannst in Deinem Workflow auch das Schlüsselwort `exclude` verwenden, wenn Du eine bestimmte Konfiguration von Python nicht laufen lassen möchtest. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)“.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, macos-latest, windows-latest]
|
||||
python-version: [2.7, 3.6, 3.7, 3.8, pypy2, pypy3]
|
||||
exclude:
|
||||
- os: macos-latest
|
||||
python-version: 3.6
|
||||
- os: windows-latest
|
||||
python-version: 3.6
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Die Standard-Version von Python verwenden
|
||||
|
||||
Wir empfehlen, `setup-python` zu verwenden, um die Version von Python zu konfigurieren, die in deinen Workflows verwendet wird, da es hilft, deine Abhängigkeiten explizit zu machen. Wenn du `setup-python` nicht verwendest, wird in jeder Shell, wenn Du `python` aufrufst, die Standardversion von Python verwendet, die in `PATH` gesetzt wurde. Die Standardversion von Python variiert zwischen den {% data variables.product.prodname_dotcom %}-gehosteten Runnern. Dies kann zu unerwarteten Abweichungen führen oder es kann unerwartet eine ältere Version verwendet werden.
|
||||
|
||||
| {% data variables.product.prodname_dotcom %}-gehostete Runner | Beschreibung |
|
||||
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Ubuntu | Auf Ubuntu-Runnern sind mehrere Versionen von System-Python unter `/usr/bin/python` und `/usr/bin/python3` installiert. Die Python-Versionen, die mit Ubuntu mitgeliefert werden, sind zusätzlich zu den Versionen, die {% data variables.product.prodname_dotcom %} im Tools-Cache installiert. |
|
||||
| Windows | Neben den Python-Versionen, die sich im Tools-Cache befinden, kommt Windows nicht mit einer entsprechenden Version von System-Python. Um das mit anderen Runnern konsistente Verhalten sicherzustellen und um Python „out-of-the-box“ ohne die Aktion `setup-python` nutzen zu können fügt {% data variables.product.prodname_dotcom %} ein paar Versionen aus dem Tools-Cache zum `PATH` hinzu. |
|
||||
| macOS | Auf macOS-Runnern sind zusätzlich zu den Versionen im Tool-Cache noch mehrere Versionen von System-Python installiert. Die Python-Versionen des Systems befinden sich im Verzeichnis `/usr/local/Cellar/python/*`. |
|
||||
|
||||
### Abhängigkeiten installieren
|
||||
|
||||
Auf {% data variables.product.prodname_dotcom %}-gehosteten Runnern ist der Paketmanager pip installiert. Du kannst pip verwenden, um Abhängigkeiten von der PyPI-Paket-Registry zu installieren, bevor Du Deinen Code baust und testest. Zum Beispiel installiert oder aktualisiert der folgende YAML den Paket-Installierer `pip` sowie die Pakete `setuptools` und `wheel`.
|
||||
|
||||
Du kannst Abhängigkeiten auch im Cache zwischenspeichern, um Deinen Workflow zu beschleunigen. Weitere Informationen findest Du unter „[Abhängigkeiten im Cache zwischenspeichern, um Deinen Workflow zu beschleunigen](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)“.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Install dependencies
|
||||
run: python -m pip install --upgrade pip setuptools wheel
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Datei für „Requirements“ (Anforderungen)
|
||||
|
||||
Nach dem Update von `pip` werden üblicherweise im nächsten Schritt die Abhängigkeiten aus *requirements.txt* installiert.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Abhängigkeiten im Cache zwischenspeichern
|
||||
|
||||
You can cache pip dependencies using a unique key, and restore the dependencies when you run future workflows using the [`cache`](https://github.com/marketplace/actions/cache) action. For more information, see "[Caching dependencies to speed up workflows](/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows)."
|
||||
|
||||
Pip caches dependencies in different locations, depending on the operating system of the runner. The path you'll need to cache may differ from the Ubuntu example below depending on the operating system you use. For more information, see [Python caching examples](https://github.com/actions/cache/blob/main/examples.md#python---pip).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Setup Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Cache pip
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
# This path is specific to Ubuntu
|
||||
path: ~/.cache/pip
|
||||
# Look to see if there is a cache hit for the corresponding requirements file
|
||||
key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-pip-
|
||||
${{ runner.os }}-
|
||||
- name: Install dependencies
|
||||
run: pip install -r requirements.txt
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Depending on the number of dependencies, it may be faster to use the dependency cache. Projects with many large dependencies should see a performance increase as it cuts down the time required for downloading. Projects with fewer dependencies may not see a significant performance increase and may even see a slight decrease due to how pip installs cached dependencies. The performance varies from project to project.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Deinen Code testen
|
||||
|
||||
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
|
||||
|
||||
#### Mit pytest und pytest-cov testen
|
||||
|
||||
This example installs or upgrades `pytest` and `pytest-cov`. Tests are then run and output in JUnit format while code coverage results are output in Cobertura. For more information, see [JUnit](https://junit.org/junit5/) and [Cobertura](https://cobertura.github.io/cobertura/).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
- name: Test with pytest
|
||||
run: |
|
||||
pip install pytest
|
||||
pip install pytest-cov
|
||||
pytest tests.py --doctest-modules --junitxml=junit/test-results.xml --cov=com --cov-report=xml --cov-report=html
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Mit Flake8 den Code von „Fusseln“ reinigen
|
||||
|
||||
The following example installs or upgrades `flake8` and uses it to lint all files. For more information, see [Flake8](http://flake8.pycqa.org/en/latest/).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
- name: Lint with flake8
|
||||
run: |
|
||||
pip install flake8
|
||||
flake8 .
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Tests mit Tox ausführen
|
||||
|
||||
With {% data variables.product.prodname_actions %}, you can run tests with tox and spread the work across multiple jobs. You'll need to invoke tox using the `-e py` option to choose the version of Python in your `PATH`, rather than specifying a specific version. For more information, see [tox](https://tox.readthedocs.io/en/latest/).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python: [2.7, 3.7, 3.8]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Setup Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python }}
|
||||
- name: Install Tox and any other packages
|
||||
run: pip install tox
|
||||
- name: Run Tox
|
||||
# Run tox using the version of Python in `PATH`
|
||||
run: tox -e py
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Workflow-Daten als Artefakte paketieren
|
||||
|
||||
You can upload artifacts to view after a workflow completes. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
|
||||
The following example demonstrates how you can use the `upload-artifact` action to archive test results from running `pytest`. For more information, see the [`upload-artifact` action](https://github.com/actions/upload-artifact).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Python package
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: [2.7, 3.5, 3.6, 3.7, 3.8]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Setup Python # Set Python version
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
# Install pip and pytest
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install pytest
|
||||
- name: Test with pytest
|
||||
run: pytest tests.py --doctest-modules --junitxml=junit/test-results-${{ matrix.python-version }}.xml
|
||||
- name: Upload pytest test results
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: pytest-results-${{ matrix.python-version }}
|
||||
path: junit/test-results-${{ matrix.python-version }}.xml
|
||||
# Use always() to always run this step to publish test results when there are test failures
|
||||
if: ${{ always() }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### In Paket-Registries veröffentlichen
|
||||
|
||||
You can configure your workflow to publish your Python package to any package registry you'd like when your CI tests pass.
|
||||
|
||||
You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Upload Python Package
|
||||
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.x'
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install setuptools wheel twine
|
||||
- name: Build and publish
|
||||
env:
|
||||
TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
|
||||
TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}
|
||||
run: |
|
||||
python setup.py sdist bdist_wheel
|
||||
twine upload dist/*
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For more information about the template workflow, see [`python-publish`](https://github.com/actions/starter-workflows/blob/main/ci/python-publish.yml).
|
||||
@@ -0,0 +1,192 @@
|
||||
---
|
||||
title: Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen
|
||||
shortTitle: Abhängigkeiten „cachen“ (zwischenspeichern)
|
||||
intro: 'Um Deine Workflows schneller und effizienter zu gestalten, kannst Du Caches für Abhängigkeiten und andere häufig wiederverwendete Dateien erstellen und verwenden.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows
|
||||
- /actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows
|
||||
- /actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### Informationen zum Zwischenspeichern von Workflow-Abhängigkeiten
|
||||
|
||||
Workflow-Läufe verwenden häufig dieselben Ausgaben oder heruntergeladenen Abhängigkeiten in aufeinanderfolgenden Durchläufen. Tools zur Verwaltung von Paketen und Abhängigkeiten wie beispielsweise Maven, Gradle, npm und Yarn halten einen lokalen Cache mit heruntergeladenen Abhängigkeiten.
|
||||
|
||||
Jobs bei {% data variables.product.prodname_dotcom %}-gehosteten Läufern beginnen in einer sauberen virtuellen Umgebung und müssen Abhängigkeiten jedes Mal herunterladen. Dies führt zu erhöhter Netzwerkauslastung, längerer Laufzeit und erhöhten Kosten. Um die Zeit zum Neuerstellen dieser Dateien einzusparen, kann {% data variables.product.prodname_dotcom %} in Workflows häufig verwendete Abhängigkeiten zwischenspeichern.
|
||||
|
||||
Um Abhängigkeiten für einen Job zu cachen, musst du die `Cache`-Aktion von {% data variables.product.prodname_dotcom %} verwenden. Die Aktion ruft einen Cache ab, der durch einen eindeutigen Schlüssel identifiziert wurde. Weitere Informationen findest Du unter [`Aktionen/Cache`](https://github.com/actions/cache).
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warnung**: Wir empfehlen Ihnen, keine sensiblen Informationen im Cache von öffentlichen Repositories zu speichern. Sensible Informationen umfassen beispielsweise Zugriffstoken oder Anmeldedaten, die in einer Datei im Cache-Pfad gespeichert sind. Auch Kommandozeilen-Programme (CLI) wie `docker login` können Zugangsdaten in einer Konfigurationsdatei speichern. Jeder mit Lesezugriff kann einen Pull-Request auf ein Repository erstellen und auf den Inhalt des Caches zugreifen. Forks eines Repositorys können auch Pull-Requests auf den base branch (Basiszweig) erstellen und auf Caches im Basiszweig zugreifen.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Vergleich: Artefakte v/s Zwischenspeicherung von Abhängigkeiten
|
||||
|
||||
Artefakte und Caching sind ähnlich, da sie die Möglichkeit bieten, Dateien auf {% data variables.product.prodname_dotcom %} zu speichern, aber die beiden Funktionalitäten bieten verschiedene Anwendungsfälle und dürfen nicht miteinander verwechselt werden.
|
||||
|
||||
- Verwende Caching, wenn Du Dateien wiederverwenden willst, die sich zwischen Jobs oder Workflow-Läufen nicht oft ändern.
|
||||
- Verwende Artefakte, wenn Du die von einem Job erzeugten Dateien speichern willst, um sie nach dem Ende eines Workflows anzuzeigen. Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
|
||||
### Einschränkungen für den Zugriff auf einen Cache
|
||||
|
||||
Mit `v2-` der `Cache-` -Aktion können Sie in Workflows auf den Cache zugreifen, die von jedem Ereignis ausgelöst werden, das über eine `GITHUB_REF`verfügt. Wenn Sie `v1-` der `-Cache-` -Aktion verwenden, können Sie nur in Workflows auf den Cache zugreifen, `durch pushen` - und `pull_request` -Ereignisse ausgelöst werden, mit Ausnahme des `pull_request` `` -Ereignis geschlossen. Weitere Informationen findest Du unter "[Ereignisse, die Workflows auslösen](/actions/reference/events-that-trigger-workflows)."
|
||||
|
||||
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually `main`). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch `feature-b` has the base branch `feature-a`, a workflow triggered on `feature-b` would have access to caches created in the default branch (`main`), `feature-a`, and `feature-b`.
|
||||
|
||||
Zugriffsbeschränkungen bieten Cache-Isolation und Sicherheit durch Ziehen einer logischen Grenze zwischen verschiedenen Workflows und Zweigen. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-b` (with the base `main`).
|
||||
|
||||
### Verwenden der `-Cache-` -Aktion
|
||||
|
||||
Die Aktion `-cache-` wird versuchen, einen Cache basierend auf dem `key` (Schlüssel), den Du angibst, wiederherzustellen. Wenn die Aktion einen Cache findet, stellt die Aktion die zwischengespeicherten Dateien in dem `path` wieder her, den Du konfigurierst.
|
||||
|
||||
Wenn es keine exakte Übereinstimmung gibt, erzeugt die Aktion einen neuen Cache-Eintrag, wenn der Job erfolgreich abgeschlossen wird. Der neue Cache wird den `key` verwenden, den Du angegeben hast, und enthält die Dateien im Verzeichnis `path`.
|
||||
|
||||
Optional kannst Du eine Liste von `restore-keys` angeben, die verwendet werden sollen, wenn der `key` nicht mit einem vorhandenen Cache übereinstimmt. Eine Liste der `restore-keys` ist nützlich, wenn Du einen Cache aus einem anderen Zweig wiederherstellst, da `restore-keys` auch teilweise mit Cache-Schlüsseln übereinstimmen dürfen. Weitere Informationen zum Abgleich von `restore-keys`, siehe "[Einen Cache-Schlüssel abgleichen](#matching-a-cache-key)."
|
||||
|
||||
Weitere Informationen findest Du unter [`Aktionen/Cache`](https://github.com/actions/cache).
|
||||
|
||||
#### Eingabeparameter für die `-Cache-` -Aktion
|
||||
|
||||
- `key`: **Erforderlich** Der Schlüssel, der beim Speichern eines Caches erstellt wurde, und der Schlüssel, der zum Suchen nach einem Cache verwendet wird. Kann eine beliebige Kombination von Variablen, Kontextwerten, statischen Strings und Funktionen sein. Schlüssel haben eine maximale Länge von 512 Zeichen und Schlüssel, die die maximale Länge überschreiten, lassen die Aktion fehlschlagen.
|
||||
- `path`: **Erforderlich** Der Dateipfad auf dem Runner zum Anlegen oder Wiederherstellen des Caches. Der Pfad kann ein absoluter Pfad oder relativ zum Arbeitsverzeichnis sein.
|
||||
- Mit `v2-` der `-Cache-` -Aktion können Sie einen einzelnen Pfad oder mehrere Pfade als Liste angeben. Pfade können entweder Verzeichnisse oder einzelne Dateien sein, und Glob-Muster werden unterstützt.
|
||||
- Bei `v1-` der `-Cache-` -Aktion wird nur ein einzelner Pfad unterstützt, und es muss sich um ein Verzeichnis handeln. Eine einzelne Datei kannst Du nicht cachen.
|
||||
- `restore-keys`: **Optional** Eine geordnete Liste der alternativen Schlüssel, die zum Finden des Caches verwendet werden sollen, falls `key` keinen Treffer gebracht hat.
|
||||
|
||||
#### Ausgangsparameter für die Cache-Aktion
|
||||
|
||||
- `Cache-Treffer`: Ein boolescher Wert, um eine genaue Übereinstimmung für den Schlüssel anzugeben.
|
||||
|
||||
#### Beispiel für die Verwendung der `-Cache-` -Aktion
|
||||
|
||||
Dieses Beispiel erzeugt einen neuen Cache, wenn sich die Pakete in `package-lock.json` ändern oder wenn das Betriebssystem des Runners wechselt. Das folgende Beispiel verwendet Kontexte und Ausdrücke, um einen Schlüssel zu erzeugen, der eine Kennung des Runner-Betriebssystems und einen SHA-256-Hash der Datei `package-lock.json` enthält.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Caching mit npm
|
||||
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
schritte:
|
||||
- verwendet: actions/checkout@v2
|
||||
|
||||
- name: Cache node modules
|
||||
uses: actions/cache@v2
|
||||
env:
|
||||
cache-name: cache-node-modules
|
||||
with:
|
||||
-npm-Cache-Dateien werden in ''/.npm' auf dem Linux/macOS-
|
||||
-Pfad gespeichert: '/.npm
|
||||
-Schlüssel: '{{ runner.os }}-build-'{{ env.cache-name }}-' hashFiles('**/package-lock.json') '
|
||||
Restore-Keys: |
|
||||
-{{ runner.os }}-build--{{ env.cache-name }}-
|
||||
-{{ runner.os }}-build-
|
||||
-{{ runner.os }}-
|
||||
|
||||
- Name: Installieren sie abhängigkeiten
|
||||
ausführen: npm install
|
||||
|
||||
- Name: Build
|
||||
ausführen: npm build
|
||||
|
||||
- Name: Test
|
||||
-Test: npm-Test
|
||||
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Wenn `key` mit einem existierenden Cache übereinstimmt, wird das als „cache hit“ (Cache-Treffer) bezeichnet, und die Aktion stellt die zwischengespeicherten Dateien wieder her und legt sie in den `path`.
|
||||
|
||||
Wenn `key` nicht mit einem existierenden Cache übereinstimmt, wird das als „cache miss“ (Cache-Fehlschlag) bezeichnet. Wenn der Job erfolgreich abgeschlossen ist, wird ein neuer Cache erstellt. Wenn ein Cache-Fehlschlag auftritt, sucht die Aktion mittels der alternativen Schlüssel gemäß `restore-keys` weiter.
|
||||
|
||||
1. Wenn du `restore-keys` bereitstellst, sucht die `cache`-Aktion sequentiell nach Caches, die mit der Liste `restore-keys` übereinstimmen.
|
||||
- Wenn es eine exakte Übereinstimmung gibt, stellt die Aktion die Dateien aus dem Cache in das Verzeichnis `path` wieder her.
|
||||
- Wenn es keine exakten Übereinstimmungen gibt, sucht die Aktion nach partiellen Übereinstimmungen der „restore keys“ (Wiederherstellungs-Scvhlüssel). Wenn die Aktion eine partielle Übereinstimmung findet, wird der aktuellste Cache in das Verzeichnis `path` wiederhergestellt.
|
||||
1. Die `Cache-` Aktion abgeschlossen wird, und der nächste Workflowschritt im Auftrag wird ausgeführt.
|
||||
1. Wenn der Job erfolgreich abgeschlossen ist, erstellt die Aktion einen neuen Cache mit dem Inhalt des Verzeichnisses `path`.
|
||||
|
||||
Um Dateien in mehr als einem Verzeichnis zu cachen, benötigst Du einen step (Schritt), der die Aktion [`cache`](https://github.com/actions/cache) für jedes Verzeichnis verwendet. Sobald Du einen Cache erstellt hast, kannst Du den Inhalt eines bereits existierenden Caches nicht ändern, aber Du kannst einen neuen Cache mit einem neuen key (Schlüssel) erstellen.
|
||||
|
||||
#### Cache-Keys aus Kontexten erstellen
|
||||
|
||||
Ein Cache-Key (Cache-Schlüssel) kann Kontexte, Funktionen, Literale und Operatoren enthalten, die von {% data variables.product.prodname_actions %} unterstützt werden. Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
Wenn Du zum Erstellen eines `key`s Ausdrücke verwendest, kannst Du automatisch einen neuen Cache zu erstellen, sobald sich die Abhängigkeiten geändert haben. Zum Beispiel kannst Du einen `key` mittels eines Ausdrucks erstellen, der den Hash-Code einer npm-Datei `package-lock.json` errechnet.
|
||||
|
||||
{% raw %}
|
||||
```
|
||||
npm-${{ hashFiles('package-lock.json') }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data variables.product.prodname_dotcom %} wertet den Ausdruck aus `hash "package-lock.json"` um daraus den endgültigen `key` abzuleiten.
|
||||
|
||||
```
|
||||
npm-d5ea0750
|
||||
```
|
||||
|
||||
### Einen Cache-Key abgleichen
|
||||
|
||||
Der `-Cache` Aktion sucht zuerst nach Cachetreffern nach `Schlüssel` und `Wiederherstellungsschlüssel n` in der Verzweigung, die die Workflowausführung enthält. Wenn in der aktuellen Verzweigung keine Treffer vorhanden sind, sucht der `-Cache` Aktion nach `Schlüssel` und `Wiederherstellungsschlüssel, die in den übergeordneten Zweigen und vorgelagerten Zweigen` .
|
||||
|
||||
Du kannst eine Liste der `restore-keys` angeben, die verwendet werden sollen, wenn auf `key` ein Cache-Fehler auftritt. Du kannst mehrere `restore-keys` erstellen, die von den spezifischsten zum am wenigsten spezifischen sortiert sind. Die Aktion `cache` sucht nach `restore-keys` in sequenzieller Reihenfolge. Wenn ein Schlüssel nicht direkt übereinstimmt, sucht die Aktion nach Schlüsseln denen der Restore-Key vorangestellt ist. Wenn mehrere Teiltreffer für einen Restore-Key vorhanden sind, gibt die Aktion den zuletzt erstellten Cache zurück.
|
||||
|
||||
#### Beispiel für die Verwendung mehrerer Restore-Keys
|
||||
|
||||
{% raw %}
|
||||
```
|
||||
restore-keys: |
|
||||
npm-foobar-${{ hashFiles('package-lock.json') }}
|
||||
npm-foobar-
|
||||
npm-
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Der Runner bewertet die Ausdrücke, die sich in folgende `restore-keys` auflösen lassen:
|
||||
|
||||
{% raw %}
|
||||
```
|
||||
restore-keys: |
|
||||
npm-foobar-d5ea0750
|
||||
npm-foobar-
|
||||
npm-
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Der Restore-Key `npm-foobar-` passt auf jeden Schlüssel, der mit dem String `npm-foobar-` beginnt. Zum Beispiel passen zu ihm die beiden Schlüssel `npm-foobar-fd3052de` und `npm-foobar-a9b253ff`. Der Cache mit dem neuesten Erstellungsdatum wird verwendet. Die Schlüssel in diesem Beispiel werden in der folgenden Reihenfolge durchsucht:
|
||||
|
||||
1. **`npm-foobar-d5ea0750`** passt zu einem bestimmten Hash.
|
||||
1. **`npm-foobar-`** deckt alle Cache-Schlüssel ab, die mit `npm-foobar-` beginnen.
|
||||
1. **`npm-`** deckt alle Cache-Schlüssel ab, die mit `npm-` beginnen.
|
||||
|
||||
##### Beispiel für die Suchpriorität
|
||||
|
||||
```yaml
|
||||
key:
|
||||
npm-feature-d5ea0750
|
||||
restore-keys: |
|
||||
npm-feature-
|
||||
npm-
|
||||
```
|
||||
|
||||
For example, if a pull request contains a `feature` branch (the current scope) and targets the default branch (`main`), the action searches for `key` and `restore-keys` in the following order:
|
||||
|
||||
1. Schlüssel `npm-feature-d5eaa0750` im Zweig `feature`
|
||||
1. Schlüssel `npm-feature-` im Zweig `feature`
|
||||
2. Schlüssel `npm-` im Zweig `feature`
|
||||
1. Key `npm-feature-d5ea0750` in the `main` branch scope
|
||||
3. Key `npm-feature-` in the `main` branch scope
|
||||
4. Key `npm-` in the `main` branch scope
|
||||
|
||||
### Nutzungsbeschränkungen und Räumungsrichtlinien
|
||||
|
||||
{% data variables.product.prodname_dotcom %} wird alle Cache-Einträge entfernen, auf die seit mehr als 7 Tagen nicht zugegriffen wurde. Es gibt keine Grenze für die Anzahl der Caches, die du speichern kannst, aber die Gesamtgröße aller Caches in einem Repository ist auf 5 GB begrenzt. Wenn du dieses Limit überschreitest, wird {% data variables.product.prodname_dotcom %} deinen Cache speichern, aber damit beginnen, Caches zu löschen, bis die Gesamtgröße kleiner als 5 GB ist.
|
||||
@@ -0,0 +1,335 @@
|
||||
---
|
||||
title: PostgreSQL-Service-Container erstellen
|
||||
shortTitle: PostgreSQL service containers
|
||||
intro: Du kannst einen PostgreSQL-Service-Container zur Verwendung in Deinem Workflow erstellen. Dieser Leitfaden zeigt Beispiele für die Erstellung eines PostgreSQL-Dienstes für Jobs, die in Containern oder direkt auf der Runner-Maschine laufen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/creating-postgresql-service-containers
|
||||
- /actions/configuring-and-managing-workflows/creating-postgresql-service-containers
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Diese Anleitung zeigt Dir Workflow-Beispiele, die einen Service-Container mit dem `postgres`-Bild vom Docker-Hub konfigurieren. Der Workflow führt ein Skript aus, um einen PostgreSQL-Client zu erstellen und den Client mit Daten zu füllen. Um zu testen, ob der Workflow den PostgreSQL-Client erstellt und mit Daten füllt, gibt das Skript die Daten des Clients in der Konsole aus.
|
||||
|
||||
{% data reusables.github-actions.docker-container-os-support %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
{% data reusables.github-actions.service-container-prereqs %}
|
||||
|
||||
Es kann Dir auch helfen, YAML, die Syntax für {% data variables.product.prodname_actions %} und PostgreSQL grundlegende zu verstehen. Weitere Informationen findest Du unter:
|
||||
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
- "[PostgreSQL-Tutorial](https://www.postgresqltutorial.com/)" in der PostgreSQL-Dokumentation
|
||||
|
||||
### Jobs in Containern ausführen
|
||||
|
||||
{% data reusables.github-actions.container-jobs-intro %}
|
||||
|
||||
{% data reusables.github-actions.copy-workflow-file %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: PostgreSQL service example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
container-job:
|
||||
# Container muessen auf Linux-basierten Betriebssystemen laufen
|
||||
runs-on: ubuntu-latest
|
||||
# Docker-Hub-Image, welches `container-job` in
|
||||
container: node:10.18-jessie ausfuehrt
|
||||
|
||||
# Service-Containers, der mit Diensten von `container-job`
|
||||
laufen soll:
|
||||
# Label fuer den Zugrieff auf den Service-Container
|
||||
postgres:
|
||||
# Docker-Hub-Image
|
||||
image: postgres
|
||||
# Das Passwort fuer Postgres bereitstellen
|
||||
env:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
# health checks (Gesundheitstests) so einstellen, dass sie warten, bis Postgres gestarted ist
|
||||
options: >-
|
||||
--health-cmd pg_isready
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI-Tests starten
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller Abhaengigkeiten in der Datei `package.json` durch
|
||||
# Weitere Information findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to PostgreSQL
|
||||
# Startet ein Skript, das einen PostgreSQL-Client erzeugt,
|
||||
# Den Client mit Daten befuellt, und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, die vom Skript `client.js` benutzt wird, um einen neuen PostgreSQL-Client zu erzeugen.
|
||||
env:
|
||||
# Der Name des Hosts fuer die Kommunikation mit dem PostgreSQL-Servicecontainer
|
||||
POSTGRES_HOST: postgres
|
||||
# The default PostgreSQL port
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Runner-Job konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-container-host %}
|
||||
|
||||
{% data reusables.github-actions.postgres-label-description %}
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
container-job:
|
||||
# Container muessen in Linux-basierten Betriebssystemen laufen
|
||||
runs-on: ubuntu-latest
|
||||
# Docker-Hub-Image, das `container-job` in
|
||||
container: node:10.18-jessie ausfuehrt
|
||||
|
||||
# Service-Container, die mit `container-job` laufen sollen
|
||||
services:
|
||||
# Label fuer den Zugriff auf den Service-Container
|
||||
postgres:
|
||||
# Docker-Hub-Image
|
||||
image: postgres
|
||||
# Passwort fuer postgres bereitstellen
|
||||
env:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
# Health checks so einstellen, dass sie warten, bis Postgres gestarted ist
|
||||
options: >-
|
||||
--health-cmd pg_isready
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
```
|
||||
|
||||
#### „Steps“ (Schritte) konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-template-steps %}
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI-Tests starten
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller Anhängigkeiten in der Datei `package.json` durch
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to PostgreSQL
|
||||
# Startet ein Skript, das einen PostgreSQL-Client erzeugt,
|
||||
# den Client mit Daten befuellt und Daten abruft
|
||||
run: node client.js
|
||||
# Environment variable used by the `client.js` script to create
|
||||
# a new PostgreSQL client.
|
||||
env:
|
||||
# Der Name des Hosts fuer die Kommunikation mit dem PostgreSQL-Servicecontainer
|
||||
POSTGRES_HOST: postgres
|
||||
# Der standardmaessige PostgreSQL-Port
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
|
||||
{% data reusables.github-actions.postgres-environment-variables %}
|
||||
|
||||
Der Hostname des PostgreSQL-Dienstes ist der Label, den Du in Deinem Workflow konfiguriert hast, in diesem Fall `postgres`. Da Docker-Container im gleichen benutzerdefinierten Bridge-Netzwerk standardmäßig alle Ports öffnen, kannst Du auf den Service-Container durch den standardmäßigen PostgreSQL-Port 5432 zugreifen.
|
||||
|
||||
### Jobs direkt auf der Runner-Maschine ausführen
|
||||
|
||||
Wenn Du einen Job direkt auf der Runner-Maschine ausführst, musst Du die Ports des Service-Containers den Ports des Docker-Hosts zuordnen. Du kannst über den Docker-Host auf den Service-Container zugreifen, indem Du `localhost` und die Port-Nummer des Docker-Hosts verwendest.
|
||||
|
||||
{% data reusables.github-actions.copy-workflow-file %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: PostgreSQL Service Example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Runner-Jobs
|
||||
runner-job:
|
||||
# Du musst fuer Service-Container oder Container-Jobs eine Linux-Umgebung verwenden
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# Service-Container zum Betrieb mit `runner-job`
|
||||
services:
|
||||
# Label fuer den Zugriff auf den Service-Container
|
||||
postgres:
|
||||
# Docker-Hub-Image
|
||||
image: postgres
|
||||
# Das Passwort fuer Postgres bereitstellen
|
||||
env:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
# Health checks einstellen, dass sie warten, bis Postgres gestarted ist
|
||||
options: >-
|
||||
--health-cmd pg_isready
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
ports:
|
||||
# Maps tcp port 5432 on service container to the host
|
||||
- 5432:5432
|
||||
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI tests laufen
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller Abhaengigkeiten in der Datei `package.json` durch
|
||||
# Weitere Information finsest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to PostgreSQL
|
||||
# Startet ein Skript, das einen PostgreSQL-Client erzeugt,
|
||||
# den client mit Daten befuellt und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, die das Skript `client.js` benutzt, um
|
||||
# einen neuen PostgreSQL-Client zu erzeugen.
|
||||
env:
|
||||
# Der Hostname fuer die Kommunikation mit dem PostgreSQL-Service-Container
|
||||
POSTGRES_HOST: localhost
|
||||
# Standardmaessiger PostgreSQL-Port
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Runner-Job konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-container-host-runner %}
|
||||
|
||||
{% data reusables.github-actions.postgres-label-description %}
|
||||
|
||||
Der Workflow ordnet Port 5432 des PostgreSQL-Service-Containers dem Docker-Host zu. Weitere Informationen über das Schlüsselwort `ports` findest Du unter "[Informationen über Service-Container](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)."
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
# Label des Runner-Jobs
|
||||
runner-job:
|
||||
# Du musst fuer Service-Containers oder Container-Jobs eine Linux-Umgebung verwenden
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# Service-Containers zum Betrieb mit `runner-job`
|
||||
services:
|
||||
# Label fier den Zugriff auf den Service-Container
|
||||
postgres:
|
||||
# Docker-Hub-Image
|
||||
image: postgres
|
||||
# Das Passwort fuer Postgres bereitstellen
|
||||
env:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
# Health-Checks einstellen, dass sie warten, bis Postgres gestarted ist
|
||||
options: >-
|
||||
--health-cmd pg_isready
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
ports:
|
||||
# Ordnet TCP-Port 5432 des Service-Containers dem Host zu
|
||||
- 5432:5432
|
||||
```
|
||||
|
||||
#### „Steps“ (Schritte) konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-template-steps %}
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI-Tests starten
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller Anhängigkeiten in der Datei `package.json` durch
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to PostgreSQL
|
||||
# Startet ein Skript, das einen PostgreSQL-Client erzeugt,
|
||||
# den Client mit Daten befuellt und Daten abruft
|
||||
run: node client.js
|
||||
# Environment variable used by the `client.js` script to create
|
||||
# a new PostgreSQL client.
|
||||
env:
|
||||
# Der Hostname zur Kommunikation with the PostgreSQL-Service-Container
|
||||
POSTGRES_HOST: localhost
|
||||
# Der standardmaessige PostgreSQL-Port
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
|
||||
{% data reusables.github-actions.postgres-environment-variables %}
|
||||
|
||||
{% data reusables.github-actions.service-container-localhost %}
|
||||
|
||||
### Den PostgreSQL-Service-Container testen
|
||||
|
||||
Du kannst Deinen Workflow mit dem folgenden Skript testen, das einen PostgreSQL-Client erstellt und eine neue Tabelle mit Platzhalter-Daten hinzufügt. Das Skript gibt dann die im PostgreSQL-Client gespeicherten Werte auf dem Terminal aus. Dein Skript kann jede beliebige Sprache verwenden, aber in diesem Beispiel wird Node.js mit dem npm-Modul `pg` genutzt. Weitere Informationen findest Du unter [npm-Modul pg](https://www.npmjs.com/package/pg).
|
||||
|
||||
Du kannst *client.js* anpassen, um alle PostgreSQL-Vorgänge einzuschließen, die für Deinen Workflow erforderlich sind. In diesem Beispiel erstellt das Skript die Instanz des PostgreSQL-Clients, erstellt eine Tabelle, fügt Platzhalter-Daten hinzu und ruft dann die Daten ab.
|
||||
|
||||
{% data reusables.github-actions.service-container-add-script %}
|
||||
|
||||
```javascript
|
||||
const { Client } = require('pg');
|
||||
|
||||
const pgclient = new Client({
|
||||
host: process.env.POSTGRES_HOST,
|
||||
port: process.env.POSTGRES_PORT,
|
||||
user: 'postgres',
|
||||
password: 'postgres',
|
||||
database: 'postgres'
|
||||
});
|
||||
|
||||
pgclient.connect();
|
||||
|
||||
const table = 'CREATE TABLE student(id SERIAL PRIMARY KEY, firstName VARCHAR(40) NOT NULL, lastName VARCHAR(40) NOT NULL, age INT, address VARCHAR(80), email VARCHAR(40))'
|
||||
const text = 'INSERT INTO student(firstname, lastname, age, address, email) VALUES($1, $2, $3, $4, $5) RETURNING *'
|
||||
const values = ['Mona the', 'Octocat', 9, '88 Colin P Kelly Jr St, San Francisco, CA 94107, United States', 'octocat@github.com']
|
||||
|
||||
pgclient.query(table, (err, res) => {
|
||||
if (err) throw err
|
||||
});
|
||||
|
||||
pgclient.query(text, values, (err, res) => {
|
||||
if (err) throw err
|
||||
});
|
||||
|
||||
pgclient.query('SELECT * FROM student', (err, res) => {
|
||||
if (err) throw err
|
||||
console.log(err, res.rows) // Print the data in student table
|
||||
pgclient.end()
|
||||
});
|
||||
```
|
||||
|
||||
Das Skript erstellt einen neuen PostgreSQL-`Client`, der einen `host`- und einen `port`-Parameter akzeptiert. Das Skript verwendet die Umgebungsvariablen `POSTGRES_HOST` und `POSTGRES_PORT`, um die IP-Adresse und den Port des Clients festzulegen. Wenn `host` Und `port` nicht definiert sind, ist der Standard-Host `localhost` und der Standard-Port 5432.
|
||||
|
||||
Das Skript erstellt eine Tabelle und füllt sie mit Platzhalterdaten auf. Um zu testen, ob die PostgreSQL-Datenbank die Daten enthält, gibt das Skript den Inhalt der Tabelle in das Konsolenprotokoll aus.
|
||||
|
||||
Wenn Du diesen Workflow ausführst, solltest Du im Schritt „Mit PostgreSQL verbinden“ die folgende Ausgabe sehen, welche zeigt, dass Du den PostgreSQL-Client erstellt und Daten hinzugefügt hast:
|
||||
|
||||
```
|
||||
null [ { id: 1,
|
||||
firstname: 'Mona the',
|
||||
lastname: 'Octocat',
|
||||
age: 9,
|
||||
address:
|
||||
'88 Colin P Kelly Jr St, San Francisco, CA 94107, United States',
|
||||
email: 'octocat@github.com' } ]
|
||||
```
|
||||
@@ -0,0 +1,325 @@
|
||||
---
|
||||
title: Redis-Service-Container erstellen
|
||||
shortTitle: Redis service containers
|
||||
intro: Du kannst Service-Container verwenden, um einen Redis-Client in Deinem Workflow zu erstellen. Dieser Leitfaden zeigt Beispiele für die Erstellung eines Redis-Dienstes für Jobs, die in Containern oder direkt auf der Runner-Maschine ausgeführt werden.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/creating-redis-service-containers
|
||||
- /actions/configuring-and-managing-workflows/creating-redis-service-containers
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Diese Anleitung zeigt Dir Workflow-Beispiele, die einen Service-Container mit dem Docker-Hub-`redis`-Image konfigurieren. Der Workflow führt ein Skript aus, um einen Redis-Client zu erstellen und den Client mit Daten zu füllen. Um zu testen, ob der Workflow den Redis-Client erstellt und mit Daten füllt, gibt das Skript die Daten des Clients auf der Konsole aus.
|
||||
|
||||
{% data reusables.github-actions.docker-container-os-support %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
{% data reusables.github-actions.service-container-prereqs %}
|
||||
|
||||
Es kannst Dir helfen, wenn Du ein grundlegendes Verständnis von YAML, der Syntax für {% data variables.product.prodname_actions %} und Redis hast. Weitere Informationen findest Du unter:
|
||||
|
||||
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
|
||||
- „[Erste Schritte mit Redis](https://redislabs.com/get-started-with-redis/)“ in der Redis-Dokumentation
|
||||
|
||||
### Jobs in Containern ausführen
|
||||
|
||||
{% data reusables.github-actions.container-jobs-intro %}
|
||||
|
||||
{% data reusables.github-actions.copy-workflow-file %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Redis container example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
container-job:
|
||||
# Container muessen in Linux-basierten Betriebssystemen laufen
|
||||
runs-on: ubuntu-latest
|
||||
# Docker-Hub-Image, in dem der `container-job` laeuft
|
||||
container: node:10.18-jessie
|
||||
|
||||
# Service-Container, die mit dem `container-job` laufen
|
||||
services:
|
||||
# Label zum Zugriff auf den Service-Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
# Health-Checks so einstellen, dass sie warten, bis redis gestarted ist
|
||||
options: >-
|
||||
--health-cmd "redis-cli ping"
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI tests gestartet werden
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller abhaengigkeiten in der Datei `package.json` aus
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to Redis
|
||||
# fuehrt ein Skript aus, das einen Redis-Cient erzeugt,
|
||||
# Den Client mit Daten fuellt, und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, mittels der das Skript `client.js` einen neuen Redis-Client erzeugt.
|
||||
env:
|
||||
# Der Hostname fuer die Kommunikation mit dem Redis-Service-Container
|
||||
REDIS_HOST: redis
|
||||
# Standarmaessiger Redis-Port
|
||||
REDIS_PORT: 6379
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Den Container-Job konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-container-host %}
|
||||
|
||||
{% data reusables.github-actions.redis-label-description %}
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
# Label des Container-Jobs
|
||||
container-job:
|
||||
# Container muessen in Linux-basierten Betriebssystemen laufen
|
||||
runs-on: ubuntu-latest
|
||||
# Docker-Hub-Image, in dem der `container-job` laeuft
|
||||
container: node:10.18-jessie
|
||||
|
||||
# Service-Container, die mit dem `container-job` laufen
|
||||
services:
|
||||
# Label zum Zugriff auf den Service-Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
# Health-Checks so einstellen, dass sie warten, bis redis gestarted ist
|
||||
options: >-
|
||||
--health-cmd "redis-cli ping"
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
```
|
||||
|
||||
#### „Steps“ (Schritte) konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-template-steps %}
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI tests gestartet werden
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller abhaengigkeiten in der Datei `package.json` aus
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to Redis
|
||||
# Fuehrt ein Skript aus, das einen Redis-Cient erzeugt,
|
||||
# den Client mit Daten fuellt, und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, mittels der das Skript `client.js` einen neuen Redis-Client erzeugt.
|
||||
env:
|
||||
# Der Hostname fuer die Kommunikation mit dem Redis-Service-Container
|
||||
REDIS_HOST: redis
|
||||
# Standarmaessiger Redis-Port
|
||||
REDIS_PORT: 6379
|
||||
```
|
||||
|
||||
{% data reusables.github-actions.redis-environment-variables %}
|
||||
|
||||
Der Hostname des Redis-Dienstes ist das Label, das Du in Deinem Workflow konfiguriert hast, in diesem Fall `redis`. Da Docker-Container im selben benutzerdefinierten Bridge-Netzwerk standardmäßig alle Ports öffnen, kannst Du auf den Service-Container über den Standard-Redis-Port 6379 zugreifen.
|
||||
|
||||
### Jobs direkt auf der Runner-Maschine ausführen
|
||||
|
||||
Wenn Du einen Job direkt auf der Runner-Maschine ausführst, musst Du die Ports des Service-Containers den Ports des Docker-Hosts zuordnen. Du kannst über den Docker-Host auf den Service-Container zugreifen, indem Du `localhost` und die Port-Nummer des Docker-Hosts verwendest.
|
||||
|
||||
{% data reusables.github-actions.copy-workflow-file %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Redis runner example
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
# Label des Runner-Jobs
|
||||
runner-job:
|
||||
# Du brauchst eine Linux-Umgebung fuer Service-Container oder Container-Jobs
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# Service-Container, die mit dem `runner-job` laufen
|
||||
services:
|
||||
# Label zum Zugriff auf den Service-Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
# Health-Checks so einstellen, dass sie warten, bis redis gestarted ist
|
||||
options: >-
|
||||
--health-cmd "redis-cli ping"
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
ports:
|
||||
# Ordnet Port 6379 des Service-Containers dem Host zu
|
||||
- 6379:6379
|
||||
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI tests gestartet werden
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller abhaengigkeiten in der Datei `package.json` aus
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to Redis
|
||||
# Fuehrt ein Skript aus, das einen Redis-Cient erzeugt,
|
||||
# den Client mit Daten fuellt, und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, mittels der das Skript `client.js`
|
||||
# einen neuen Redis-Client erzeugt.
|
||||
env:
|
||||
# Der Hostname fuer die Kommunikation mit dem Redis-Service-Container
|
||||
REDIS_HOST: localhost
|
||||
# Standarmaessiger Redis-Port
|
||||
REDIS_PORT: 6379
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Runner-Job konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-container-host-runner %}
|
||||
|
||||
{% data reusables.github-actions.redis-label-description %}
|
||||
|
||||
Der Workflow ordnet Port 6379 des Redis-Service-Containers dem Docker-Host zu. Weitere Informationen über das Schlüsselwort `ports` findest Du unter "[Informationen über Service-Container](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)."
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
# Label des Runner-Jobs
|
||||
runner-job:
|
||||
# Fuer Service-Containers oder Container-Jobs brauchst Du eine Linux-Umgebung
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# Service-Container, die mit dem `runner-job` laufen
|
||||
services:
|
||||
# Label zum Zugriff auf den Service-Container
|
||||
redis:
|
||||
# Docker-Hub-Image
|
||||
image: redis
|
||||
# Health-Checks so einstellen, dass sie warten, bis redis gestarted ist
|
||||
options: >-
|
||||
--health-cmd "redis-cli ping"
|
||||
--health-interval 10s
|
||||
--health-timeout 5s
|
||||
--health-retries 5
|
||||
ports:
|
||||
# Ordnet Port 6379 des Service-Containers dem Host zu
|
||||
- 6379:6379
|
||||
```
|
||||
|
||||
#### „Steps“ (Schritte) konfigurieren
|
||||
|
||||
{% data reusables.github-actions.service-template-steps %}
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
# Laedt eine Kopie des Codes in Dein Repository herunter, bevor CI tests gestartet werden
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Fuehrt eine saubere Installation aller abhaengigkeiten in der Datei `package.json` durch
|
||||
# Weitere Informationen findest Du unter https://docs.npmjs.com/cli/ci.html
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to Redis
|
||||
# Fuehrt ein Skript aus, das einen Redis-Cient erzeugt,
|
||||
# den Client mit Daten fuellt, und Daten abruft
|
||||
run: node client.js
|
||||
# Umgebungsvariable, mittels der das Skript `client.js`
|
||||
# einen neuen Redis-Client erzeugt.
|
||||
env:
|
||||
# Der Hostname fuer die Kommunikation mit dem Redis-Service-Container
|
||||
REDIS_HOST: localhost
|
||||
# Standarmaessiger Redis-Port
|
||||
REDIS_PORT: 6379
|
||||
```
|
||||
|
||||
{% data reusables.github-actions.redis-environment-variables %}
|
||||
|
||||
{% data reusables.github-actions.service-container-localhost %}
|
||||
|
||||
### Redis-Sercive-Container testen
|
||||
|
||||
Du kannst Deinen Workflow mit dem folgenden Skript testen, das einen Redis-Client erstellt und den Client mit Platzhalter-Daten füllt. Das Skript gibt dann die im Redis-Client gespeicherten Werte auf dem Terminal aus. Dein Skript kann jede beliebige Sprache verwenden, aber dieses Beispiel verwendet Node.js und das `redis`-npm-Modul. Weitere Informationen findest Du unter [npm-Redis-Modul](https://www.npmjs.com/package/redis).
|
||||
|
||||
Du kannst *client.js* anpassen, um alle Redis-Operationen abzudecken, die Dein Workflow braucht. In diesem Beispiel erstellt das Skript die Redis-Client-Instanz, fügt Platzhalter-Daten hinzu und ruft dann die Daten ab.
|
||||
|
||||
{% data reusables.github-actions.service-container-add-script %}
|
||||
|
||||
```javascript
|
||||
const redis = require("redis");
|
||||
|
||||
// Erzeugt einen neuen Redis-Client
|
||||
// Falls REDIS_HOST nicht definiert ist, ist der Host standarmaessig localhost
|
||||
// Falls REDIS_PORT nicht definiert ist, ist der Standard-Port 6379
|
||||
const redisClient = redis.createClient({
|
||||
host: process.env.REDIS_HOST,
|
||||
port: process.env.REDIS_PORT
|
||||
});
|
||||
|
||||
redisClient.on("error", function(err) {
|
||||
console.log("Error " + err);
|
||||
});
|
||||
|
||||
// Setzt den Schluessel "octocat" auf den Wert "Mona the octocat"
|
||||
redisClient.set("octocat", "Mona the Octocat", redis.print);
|
||||
// Setzt einen Schluessel auf "octocat", Feld auf "species", und "value" auf "Cat and Octopus"
|
||||
redisClient.hset("species", "octocat", "Cat and Octopus", redis.print);
|
||||
// Setzt einen Schluessel auf "octocat", Feld auf "species", und "value" auf "Dinosaur and Octopus"
|
||||
redisClient.hset("species", "dinotocat", "Dinosaur and Octopus", redis.print);
|
||||
// Setzt einen Schluessel auf "octocat", Feld auf "species", und "value" auf "Cat and Robot"
|
||||
redisClient.hset(["species", "robotocat", "Cat and Robot"], redis.print);
|
||||
// Holt alle Felder vom Schluessel "species"
|
||||
|
||||
redisClient.hkeys("species", function (err, replies) {
|
||||
console.log(replies.length + " replies:");
|
||||
replies.forEach(function (reply, i) {
|
||||
console.log(" " + i + ": " + reply);
|
||||
});
|
||||
redisClient.quit();
|
||||
});
|
||||
```
|
||||
|
||||
Das Skript erstellt einen neuen Redis-Client mit der Methode `createClient`, welche die Parameter `host` und `port` akzeptiert. Das Skript verwendet die Umgebungsvariablen `REDIS_HOST` und `REDIS_PORT`, um die IP-Adresse und den Port des Clients festzulegen. Wenn `host` und `port` nicht definiert sind, ist der Standard-Host `localhost` und der Standard-Port 6379.
|
||||
|
||||
Das Skript verwendet die Methoden `set` und `hset`, um die Datenbank mit einigen Schlüsseln, Feldern und Werten zu füllen. Um zu bestätigen, dass der Redis-Client die Daten enthält, gibt das Skript den Inhalt der Datenbank in das Konsolen-Log aus.
|
||||
|
||||
Wenn Du diesen Workflow ausführst, solltest Du im Schritt „Mit Redis verbinden“ die folgende Ausgabe sehen, welche zeigt, dass Du den Redis-Client erstellt und Daten hinzugefügt hast:
|
||||
|
||||
```
|
||||
Reply: OK
|
||||
Reply: 1
|
||||
Reply: 1
|
||||
Reply: 1
|
||||
3 replies:
|
||||
0: octocat
|
||||
1: dinotocat
|
||||
2: robotocat
|
||||
```
|
||||
60
translations/de-DE/content/actions/guides/index.md
Normal file
60
translations/de-DE/content/actions/guides/index.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Leitfäden
|
||||
shortTitle: Leitfäden
|
||||
intro: 'These guides for {% data variables.product.prodname_actions %} include specific use cases and examples to help you configure workflows.'
|
||||
redirect_from:
|
||||
- /actions/guides/caching-and-storing-workflow-data
|
||||
- /actions/automating-your-workflow-with-github-actions/using-databases-and-services
|
||||
- /actions/configuring-and-managing-workflows/using-databases-and-service-containers
|
||||
- /actions/guides/using-databases-and-service-containers
|
||||
- /actions/language-and-framework-guides
|
||||
- /actions/language-and-framework-guides/github-actions-for-docker
|
||||
- /actions/language-and-framework-guides/github-actions-for-java
|
||||
- /actions/language-and-framework-guides/github-actions-for-javascript-and-typescript
|
||||
- /actions/language-and-framework-guides/github-actions-for-python
|
||||
- /actions/publishing-packages-with-github-actions
|
||||
- /actions/building-and-testing-code-with-continuous-integration
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Creating custom continuous integration workflows
|
||||
|
||||
You can use {% data variables.product.prodname_actions %} to create custom continuous integration (CI) workflows that build and test projects written in different programming languages.
|
||||
|
||||
{% link_in_list /about-continuous-integration %}
|
||||
{% link_in_list /setting-up-continuous-integration-using-workflow-templates %}
|
||||
{% link_in_list /building-and-testing-nodejs %}
|
||||
{% link_in_list /building-and-testing-python %}
|
||||
{% link_in_list /building-and-testing-java-with-maven %}
|
||||
{% link_in_list /building-and-testing-java-with-gradle %}
|
||||
{% link_in_list /building-and-testing-java-with-ant %}
|
||||
|
||||
### Publishing software packages
|
||||
|
||||
You can automate publishing software packages as part your continuous delivery (CD) workflow. Packages can be published to any package host and to {% data reusables.gated-features.packages %}.
|
||||
|
||||
{% link_in_list /about-packaging-with-github-actions %}
|
||||
{% link_in_list /publishing-nodejs-packages %}
|
||||
{% link_in_list /publishing-java-packages-with-maven %}
|
||||
{% link_in_list /publishing-java-packages-with-gradle %}
|
||||
{% link_in_list /publishing-docker-images %}
|
||||
|
||||
### Workflow-Daten speichern und zwischenspeichern
|
||||
|
||||
Abhängigkeiten zwischenspeichern und Artefakte speichern, um Deinen Workflow effizienter ablaufen zu lassen.
|
||||
|
||||
{% link_in_list /storing-workflow-data-as-artifacts %}
|
||||
{% link_in_list /caching-dependencies-to-speed-up-workflows %}
|
||||
|
||||
### Using service containers in a workflow
|
||||
|
||||
Connect services to your workflow using service containers.
|
||||
|
||||
{% link_in_list /about-service-containers %}
|
||||
{% link_in_list /creating-redis-service-containers %}
|
||||
{% link_in_list /creating-postgresql-service-containers %}
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: Docker-Images veröffentlichen
|
||||
intro: 'Du kannst Docker-Images im Rahmen Deines Workflows zur kontinuierlichen Integration (CI) in einer Registry wie zum Beispiel „Docker Hub“ oder {% data variables.product.prodname_registry %} veröffentlichen.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/publishing-docker-images
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Diese Anleitung zeigt Dir, wie Du einen Workflow erstellen kannst, der einen Docker-Build ausführt und dann Docker-Images auf „Docker Hub“ oder {% data variables.product.prodname_registry %} veröffentlicht. Mit einem einzelnen Workflow kannst Du Images in einer einzigen Registry oder in mehreren Registries veröffentlichen.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Wenn Du auf eine andere Docker-Registriery eines Drittanbieters pushen möchtest, kann das Beispiel im Abschnitt [Veröffentlichen von Images auf {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)" als gute Vorlage dienen.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Wir empfehlen, dass Du ein grundlegendes Verständnis von Workflowkonfigurations-Optionen hast und darüber, wie Du eine Workflow-Datei erstellst. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
Vielleicht findest Du es auch hilfreich, ein grundlegendes Verständnis von Folgendem zu haben:
|
||||
|
||||
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
|
||||
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
|
||||
- „[Docker für den Einsatz mit {% data variables.product.prodname_registry %} konfigurieren](/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages)“
|
||||
|
||||
### Informationen zur Image-Konfiguration
|
||||
|
||||
In dieser Anleitung wird davon ausgegangen, dass Du eine vollständige Definition für ein Docker-Image in einem {% data variables.product.prodname_dotcom %}-Repository gespeichert hast. Dein Projektarchiv muss beispielsweise eine _Dockerdatei_ und alle anderen Dateien enthalten, die benötigt werden, um einen Docker-Build zum Erstellen eines Images durchzuführen.
|
||||
|
||||
In dieser Anleitung wir werden die Docker-Aktion `build-push-action` verwenden, um das Docker-Image zu bauen und es auf eine oder mehrere Docker-Registries zu übertragen. Weitere Informationen findest Du unter [`build-push-action`](https://github.com/marketplace/actions/build-and-push-docker-images).
|
||||
|
||||
{% data reusables.actions.enterprise-marketplace-actions %}
|
||||
|
||||
### Images auf dem „Docker Hub“ veröffentlichen
|
||||
|
||||
{% data reusables.github-actions.release-trigger-workflow %}
|
||||
|
||||
Im folgenden Beispiel-Workflow verwenden wir die Docker-Aktion `build-push-action`, um das Docker-Image zu bauen und, wenn der Build erfolgreich ist, das gebaute Image auf „Docker Hub“ zu übertragen.
|
||||
|
||||
Um zum „Docker Hub“ zu pushen, benötigst Du ein Benutzerkonto auf „Docker Hub“ und musst ein „Docker Hub“-Repository erstellt haben. Weitere Informationen findest Du unter „[Images auf ‚Docker Hub‘ freigeben](https://docs.docker.com/get-started/part3/)“ in der Docker-Dokumentation.
|
||||
|
||||
„Docker Hub“ benötigt für `build-push-action` die folgenden Optionen:
|
||||
|
||||
* `username` und `password`: Dies ist Dein Benutzername und Passwort auf „Docker Hub“. Wir empfehlen Dir, Deinen „Docker Hub“-Benutzernamen und das -Passwort als verschlüsselte Geheimnisse in Deinem {% data variables.product.prodname_dotcom %}-Repository zu speichern, damit diese nicht in Deiner Workflow-Datei enthüllt werden. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
* `repository`: Dein „Docker Hub“-Repository im Format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY`.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish Docker image
|
||||
on:
|
||||
release:
|
||||
types: [published]
|
||||
jobs:
|
||||
push_to_registry:
|
||||
name: Push Docker image to Docker Hub
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out the repo
|
||||
uses: actions/checkout@v2
|
||||
- name: Push to Docker Hub
|
||||
uses: docker/build-push-action@v1
|
||||
with:
|
||||
username: ${{ secrets.DOCKER_USERNAME }}
|
||||
password: ${{ secrets.DOCKER_PASSWORD }}
|
||||
repository: my-docker-hub-namespace/my-docker-hub-repository
|
||||
tag_with_ref: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.docker-tag-with-ref %}
|
||||
|
||||
### Images in {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
{% data reusables.github-actions.release-trigger-workflow %}
|
||||
|
||||
Im folgenden Beispiel-Workflow verwenden wir die Docker-Aktion `build-push-action`, um das Docker-Image zu bauen und, wenn der Build erfolgreich ist, das gebaute Image nach {% data variables.product.prodname_registry %} zu übertragen.
|
||||
|
||||
Die für {% data variables.product.prodname_registry %} erforderlichen `build-push-action`-Optionen sind:
|
||||
|
||||
* `username`: Du kannst mithilfe des Kontexts von {% raw %}`${{ github.actor }}`{% endraw %} automatisch den Benutzernamen des Benutzers zu verwenden, der die Workflow-Ausführung angestoßen hat. Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für GitHub-Aktionen](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)“.
|
||||
* `password`: Du kannst das automatisch generierte Geheimnis `GITHUB_TOKEN` als Passwort verwenden. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)".
|
||||
* `registry`: Muss auf `docker.pkg.github.com` gesetzt werden.
|
||||
* `repository`: Muss im Format `OWNER/REPOSITORY/IMAGE_NAME` gesetzt werden. Beispiel: Für ein Bild namens `octo-image` auf {% data variables.product.prodname_dotcom %} unter `http://github. om/octo-org/octo-repo` sollte die Option `repository` auf `octo-org/octo-repo/octo-image` gesetzt werden.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish Docker image
|
||||
on:
|
||||
release:
|
||||
types: [published]
|
||||
jobs:
|
||||
push_to_registry:
|
||||
name: Push Docker image to GitHub Packages
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out the repo
|
||||
uses: actions/checkout@v2
|
||||
- name: Push to GitHub Packages
|
||||
uses: docker/build-push-action@v1
|
||||
with:
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
registry: docker.pkg.github.com
|
||||
repository: my-org/my-repo/my-image
|
||||
tag_with_ref: true
|
||||
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.docker-tag-with-ref %}
|
||||
|
||||
### Images auf dem „Docker Hub“ und in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
In einem einzigen Workflow kannst Du Dein Docker-Image in mehreren Registries veröffentlichen, indem Du die Aktion `build-push-action` auf jede Registry anwendest.
|
||||
|
||||
Der folgende Beispiel-Workflow verwendet die Schritte der `build-push-action` aus den vorherigen Abschnitten („[Veröffentlichung von Bildern auf ‚Docker Hub‘](#publishing-images-to-docker-hub)“ und „[Veröffentlichung von Bildern in {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)“), um einen einzigen Workflow zu erstellen, der in beide Registries pusht.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish Docker image
|
||||
on:
|
||||
release:
|
||||
types: [published]
|
||||
jobs:
|
||||
push_to_registries:
|
||||
name: Push Docker image to multiple registries
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out the repo
|
||||
uses: actions/checkout@v2
|
||||
- name: Push to Docker Hub
|
||||
uses: docker/build-push-action@v1
|
||||
with:
|
||||
username: ${{ secrets.DOCKER_USERNAME }}
|
||||
password: ${{ secrets.DOCKER_PASSWORD }}
|
||||
repository: my-docker-hub-namespace/my-docker-hub-repository
|
||||
tag_with_ref: true
|
||||
- name: Push to GitHub Packages
|
||||
uses: docker/build-push-action@v1
|
||||
with:
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
registry: docker.pkg.github.com
|
||||
repository: my-org/my-repo/my-image
|
||||
tag_with_ref: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Der obige Workflow checkt das {% data variables.product.prodname_dotcom %}-Repository aus und verwendet die Aktion `build-push-action` zweimal, um das Docker-Image zu erstellen und sowohl auf den „Docker Hub“ als auch in die {% data variables.product.prodname_registry %} zu übertragen. Für beide Schritte, setzt er die Option `build-push-action` auf [`tag_with_ref`](https://github.com/marketplace/actions/build-and-push-docker-images#tag_with_ref) um das gebaute Docker-Image automatisch mit der Git-Referenz des Workflow-Ereignisses zu kennzeichnen. Dieser Workflow wird bei der Veröffentlichung eines {% data variables.product.prodname_dotcom %}-Releases ausgelöst, so dass die Referenz für beide Registries das Git-Tag des Releases ist.
|
||||
@@ -0,0 +1,219 @@
|
||||
---
|
||||
title: Java-Pakete mit Gradle veröffentlichen
|
||||
intro: Du kannst Gradle verwenden, um Java-Pakete als Teil Deines Workflows zur kontinuierlichen Integration (CI) in einer Registry zu veröffentlichen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/publishing-java-packages-with-gradle
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
{% data reusables.github-actions.publishing-java-packages-intro %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Wir empfehlen Dir, ein grundlegendes Verständnis von Workflow-Dateien und Konfigurationsoptionen zu haben. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
Weitere Informationen zum Erstellen eines CI-Workflows für Dein Java-Projekt mit Gradle findest Du unter „[Java bauen und testen mit Gradle](/actions/language-and-framework-guides/building-and-testing-java-with-gradle)“.
|
||||
|
||||
Vielleicht findest Du es auch hilfreich, ein grundlegendes Verständnis von Folgendem zu haben:
|
||||
|
||||
- „[Konfiguration von npm für die Verwendung mit {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages/configuring-npm-for-use-with-github-packages)“
|
||||
- "[Environment variables](/actions/reference/environment-variables)"
|
||||
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
|
||||
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
|
||||
|
||||
### Informationen zur Paketkonfiguration
|
||||
|
||||
Die Felder `groupId` und `artifactId` im Abschnitt `MavenPublication` der Datei _build.gradle_ bilden eine eindeutige Kennung für Dein Paket. Registries verwenden diese Kennung, um Dein Paket mit einer Registry zu verknüpfen. Dies ist so ähnlich wie bei den Feldern `groupId` und `artifactId` der Maven-Datei _pom.xml_. Weitere Informationen findest Du unter „[‚Maven Publish Plugin‘](https://docs.gradle.org/current/userguide/publishing_maven.html)“ in der Gradle-Dokumentation.
|
||||
|
||||
Die Datei _build.gradle_ enthält auch die Konfiguration für die Distributionsverwaltungs-Repositories, zu denen Gradle dann Pakete veröffentlicht. Jedes Repository braucht einen Namen, eine Deployment-URL und Anmeldeinformationen zur Authentifizierung.
|
||||
|
||||
### Pakete im „Maven Central Repository“ veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel wird von dem Ereignis `release` vom Typ `created` angestoßen. Der Workflow veröffentlicht das Paket im „Maven Central Repository“, sofern es die CI-Tests besteht. Weitere Informationen zum Ereignis `release` findest Du unter „[Ereignisse, die Workflows anstoßen](/actions/reference/events-that-trigger-workflows#release)“.
|
||||
|
||||
Du kannst ein neues Maven-Repository im Block `publishing` Deiner Datei _build.gradle_ definieren, das auf Dein Paket-Repository verweist. Wenn Du zum Beispiel über das OSSRH-Hosting-Projekt in das „Maven Central Repository“ deployst, kann Deine _build.gradle_ ein Repository mit dem Namen `"OSSRH"` bestimmen.
|
||||
|
||||
{% raw %}
|
||||
```groovy
|
||||
publishing {
|
||||
...
|
||||
|
||||
repositories {
|
||||
maven {
|
||||
name = "OSSRH"
|
||||
url = "https://oss.sonatype.org/service/local/staging/deploy/maven2/"
|
||||
credentials {
|
||||
username = System.getenv("MAVEN_USERNAME")
|
||||
password = System.getenv("MAVEN_PASSWORD")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Mit dieser Konfiguration kannst Du einen Workflow erstellen, der mithilfe des Befehls `gradle publish` Dein Paket im „Maven Central Repository“ veröffentlicht. Du musst auch Umgebungsvariablen bereitstellen, die den Benutzernamen und das Kennwort enthalten, um Dich im Repository zu authentifizieren.
|
||||
|
||||
Im Deploy-Schritt musst Du Umgebungsvariablen für den Benutzernamen und das Passwort oder für den Token festlegen, mit dem Du Dich im Maven-Repository authentifizierst. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
|
||||
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to the Maven Central Repository
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Java
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish package
|
||||
run: gradle publish
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.gradle-workflow-steps %}
|
||||
1. Führt den Befehl `gradle publish` aus, um im Maven-Repository `OSSRH` zu veröffentlichen. Die Umgebungsvariable `MAVEN_USERNAME` wird mit dem Inhalt Deines Geheimnisses `OSSRH_USERNAME` gefüllt, und die Umgebungsvariable `MAVEN_PASSWORD` wird mit dem Inhalt Deines Geheimnisses `OSSRH_TOKEN` gefüllt.
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
### Pakete in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel wird von dem Ereignis `release` vom Typ `created` angestoßen. Der Workflow veröffentlicht das Paket in {% data variables.product.prodname_registry %} , wenn die CI-Tests bestanden wurden. Weitere Informationen zum Ereignis `release` findest Du unter „[Ereignisse, die Workflows anstoßen](/actions/reference/events-that-trigger-workflows#release)“.
|
||||
|
||||
Du kannst ein neues Maven-Repository im Block `publishing` Deiner Datei _build.gradle_ definieren, das auf {% data variables.product.prodname_registry %} verweist. In dieser Repository-Konfiguration kannst Du auch die in Deinem CI-Workflow-Lauf eingestellten Umgebungsvariablen nutzen. Du kannst die Umgebungsvariable `GITHUB_ACTOR` als Benutzernamen verwenden und die Umgebungsvariable `GITHUB_TOKEN` auf Dein `GITHUB_TOKEN`-Geheimnis setzen.
|
||||
|
||||
Der `GITHUB_TOKEN` existiert standardmäßig in Deinem Repository und hat Lese- und Schreibrechte für Pakete in dem Repository, in dem der Workflow läuft. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
|
||||
Wenn beispielsweise Deine Organisation „octocat“ und Dein Repository „hello-world“ heißt, sieht die {% data variables.product.prodname_registry %}-Konfiguration in _build.gradle_ so ähnlich wie im folgenden Beispiel aus.
|
||||
|
||||
{% raw %}
|
||||
```groovy
|
||||
publishing {
|
||||
...
|
||||
|
||||
repositories {
|
||||
maven {
|
||||
name = "GitHubPackages"
|
||||
url = "https://maven.pkg.github.com/octocat/hello-world"
|
||||
credentials {
|
||||
username = System.getenv("GITHUB_ACTOR")
|
||||
password = System.getenv("GITHUB_TOKEN")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Mit dieser Konfiguration kannst Du einen Workflow erstellen, der mithilfe des Befehls `gradle publish` Dein Paket im „Maven Central Repository“ veröffentlicht.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to GitHub Packages
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish package
|
||||
run: gradle publish
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.gradle-workflow-steps %}
|
||||
1. Führt den Befehl `gradle publish` aus, um in {% data variables.product.prodname_registry %} zu veröffentlichen. Die Umgebungsvariable `GITHUB_TOKEN` wird mit dem Inhalt des `GITHUB_TOKEN`-Geheimnisses gefüllt.
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
### Pakete im Maven Central Repository und in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
Du kannst Deine Pakete sowohl im Maven Central Repository als auch in der {% data variables.product.prodname_registry %} veröffentlichen, indem Du beides in Deiner Datei _build.gradle_ konfigurierst.
|
||||
|
||||
Stelle sicher, dass Deine Datei _build.gradle_ ein Repository sowohl für Dein {% data variables.product.prodname_dotcom %}-Repository als auch Deinen „Maven Central Repository“-Provider enthält.
|
||||
|
||||
Wenn Du beispielsweise über das OSSRH-Hosting-Projekt in das Central Repository deployen willst, kannst Du das in einem Distributionsverwaltungs-Repository angeben, wobei Du den `-name` auf `OSSRH` setzt. Wenn Du in die {% data variables.product.prodname_registry %} deployen willst, kannst Du das in einem Distributionsverwaltungs-Repository angeben, wobei Du den `-name` auf `GitHubPackages` setzt.
|
||||
|
||||
Wenn Deine Organisation „octocat“ und Dein Repository „hello-world“ heißt, sieht die {% data variables.product.prodname_registry %}-Konfiguration in _build.gradle_ so ähnlich wie im folgenden Beispiel aus.
|
||||
|
||||
{% raw %}
|
||||
```groovy
|
||||
publishing {
|
||||
...
|
||||
|
||||
repositories {
|
||||
maven {
|
||||
name = "OSSRH"
|
||||
url = "https://oss.sonatype.org/service/local/staging/deploy/maven2/"
|
||||
credentials {
|
||||
username = System.getenv("MAVEN_USERNAME")
|
||||
password = System.getenv("MAVEN_PASSWORD")
|
||||
}
|
||||
}
|
||||
maven {
|
||||
name = "GitHubPackages"
|
||||
url = "https://maven.pkg.github.com/octocat/hello-world"
|
||||
credentials {
|
||||
username = System.getenv("GITHUB_ACTOR")
|
||||
password = System.getenv("GITHUB_TOKEN")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Mit dieser Konfiguration kannst Du einen Workflow erstellen, der mithilfe des Befehls `gradle publish` Dein Paket sowohl im „Maven Central Repository“ als auch in der {% data variables.product.prodname_registry %} veröffentlicht.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to the Maven Central Repository and GitHub Packages
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Java
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish to the Maven Central Repository
|
||||
run: gradle publish
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% data reusables.github-actions.gradle-workflow-steps %}
|
||||
1. Führt den Befehl `gradle publish` aus, um im Maven-Repository `OSSRH` und in der {% data variables.product.prodname_registry %} zu veröffentlichen. Die Umgebungsvariable `MAVEN_USERNAME` wird mit dem Inhalt Deines Geheimnisses `OSSRH_USERNAME` gefüllt, und die Umgebungsvariable `MAVEN_PASSWORD` wird mit dem Inhalt Deines Geheimnisses `OSSRH_TOKEN` gefüllt. Die Umgebungsvariable `GITHUB_TOKEN` wird mit dem Inhalt des `GITHUB_TOKEN`-Geheimnisses gefüllt.
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
@@ -0,0 +1,210 @@
|
||||
---
|
||||
title: Java-Pakete mit Maven veröffentlichen
|
||||
intro: Du kannst Maven verwenden, um Java-Pakete als Teil Deines Workflows zur kontinuierlichen Integrations (CI) in eine Registry zu veröffentlichen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/language-and-framework-guides/publishing-java-packages-with-maven
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
{% data reusables.github-actions.publishing-java-packages-intro %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Wir empfehlen Dir, ein grundlegendes Verständnis von Workflow-Dateien und Konfigurationsoptionen zu haben. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
Weitere Informationen zum Erstellen eines CI-Workflows für Dein Java-Projekt mit Maven findest Du unter "[Java mit Maven erstellen und testen](/actions/language-and-framework-guides/building-and-testing-java-with-maven)."
|
||||
|
||||
Vielleicht findest Du es auch hilfreich, ein grundlegendes Verständnis von Folgendem zu haben:
|
||||
|
||||
- „[Konfiguration von npm für die Verwendung mit {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages/configuring-npm-for-use-with-github-packages)“
|
||||
- "[Environment variables](/actions/reference/environment-variables)"
|
||||
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
|
||||
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
|
||||
|
||||
### Informationen zur Paketkonfiguration
|
||||
|
||||
Die Felder `groupId` und `artifactId` in der Datei _pom.xml_ bilden eine eindeutige Kennung für Dein Paket. Registries verwenden diese Kennung, um Dein Paket mit einer Registry zu verknüpfen. Weitere Informationen findest Du unter [Leitfaden zum Hochladen von Artefakten in das Central Repository](http://maven.apache.org/repository/guide-central-repository-upload.html) in der „Apache Maven“-Dokumentation.
|
||||
|
||||
Die Datei _pom.xml_ enthält auch die Konfiguration für die Distributionsverwaltungs-Repositories, in denen Maven Pakete veröffentlicht. Jedes Repository braucht einen Namen und eine „Deployment-URL“ (Bereitstellungs-URL). Die Authentifizierung für diese Repositories kann in der Datei _.m2/settings.xml_ im Home-Verzeichnis des Benutzers konfiguriert werden, der Maven verwendet.
|
||||
|
||||
Du kannst die Aktion `setup-java` verwenden, um das Deployment-Repository sowie die Authentifizierung für dieses Repository zu konfigurieren. Weitere Informationen findest Du unter [`setup-java`](https://github.com/actions/setup-java).
|
||||
|
||||
### Pakete im „Maven Central Repository“ veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel wird von dem Ereignis `release` vom Typ `created` angestoßen. Der Workflow veröffentlicht das Paket im „Maven Central Repository“, sofern es die CI-Tests besteht. Weitere Informationen zum Ereignis `release` findest Du unter „[Ereignisse, die Workflows anstoßen](/actions/reference/events-that-trigger-workflows#release)“.
|
||||
|
||||
In diesem Workflow kannst Du die Aktion `setup-java` verwenden. Diese Aktion installiert die angegebene JDK-Version in den `PATH`, aber sie konfiguriert auch eine _settings.xml_ für Maven, um Pakete zu veröffentlichen. Standardmäßig wird die Settings-Datei für {% data variables.product.prodname_registry %} konfiguriert, aber sie kann dazu konfiguriert werden, in eine andere Paket-Registry wie z.B. das „Maven Central Repository“ zu deployen. Wenn Du bereits ein Distributions-Management-Repository im _pom.xml_ konfiguriert hast, dann kannst Du beim Aufruf der Aktion `setup-java` diese `id` angeben.
|
||||
|
||||
Wenn Du zum Beispiel über das OSSRH-Hosting-Projekt ins „Maven Central Repository“ deployst, kann Deine _pom.xml_ ein Distributions-Management-Repository mit `ossrh` als `id` angeben.
|
||||
|
||||
{% raw %}
|
||||
```xml
|
||||
<project ...>
|
||||
...
|
||||
<distributionManagement>
|
||||
<repository>
|
||||
<id>ossrh</id>
|
||||
<name>Central Repository OSSRH</name>
|
||||
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
|
||||
</repository>
|
||||
</distributionManagement>
|
||||
</project>
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Mit dieser Konfiguration kannst Du einen Workflow erstellen, der Dein Paket im „Maven Central Repository“ veröffentlicht, indem Du die Repository-Verwaltungs-`id` in der Aktion `setup-java` angibst. Du musst auch Umgebungsvariablen bereitstellen, die den Benutzernamen und das Kennwort enthalten, um Dich im Repository zu authentifizieren.
|
||||
|
||||
Im Deploy-Schritt musst Du die Umgebungsvariablen auf den Benutzernamen setzen, mit dem Du Dich im Repository anmeldest, und auf ein Geheimnis, das Du mit dem Passwort oder dem Token konfiguriert hast, mit dem Du Dich authentifizierst. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
|
||||
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to the Maven Central Repository
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Maven Central Repository
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
server-id: ossrh
|
||||
server-username: MAVEN_USERNAME
|
||||
server-password: MAVEN_PASSWORD
|
||||
- name: Publish package
|
||||
run: mvn -B deploy
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Checkt eine Kopie des Projekt-Repositorys aus.
|
||||
1. Richtet das „Java JDK“ ein und konfiguriert die Maven-Datei _settings.xml_, um die Authentifizierung für das Repository `ossrh` mit den Umgebungsvariablen `MAVEN_USERNAME` und `MAVEN_PASSWORD` hinzuzufügen.
|
||||
1. {% data reusables.github-actions.publish-to-maven-workflow-step %}
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
### Pakete in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel wird von dem Ereignis `release` vom Typ `created` angestoßen. Der Workflow veröffentlicht das Paket in {% data variables.product.prodname_registry %} , wenn die CI-Tests bestanden wurden. Weitere Informationen zum Ereignis `release` findest Du unter „[Ereignisse, die Workflows anstoßen](/actions/reference/events-that-trigger-workflows#release)“.
|
||||
|
||||
In diesem Workflow kannst Du die Aktion `setup-java` verwenden. Diese Aktion installiert die angegebene JDK-Version in den `PATH` und stellt auch Maven- _settings.xml_ ein, um Paket in der {% data variables.product.prodname_registry %} zu veröffentlichen. Die generierte _settings.xml_ definiert die Authentifizierung für einen Server mit einer `id` von `github` und verwendet die Umgebungsvariable `GITHUB_ACTOR` als Benutzername und die Umgebungsvariable `GITHUB_TOKEN` als Passwort.
|
||||
|
||||
Der `GITHUB_TOKEN` existiert standardmäßig in Deinem Repository und hat Lese- und Schreibrechte für Pakete in dem Repository, in dem der Workflow läuft. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
|
||||
Für ein Maven-basiertes Projekt kannst Du diese Einstellungen nutzen, indem Du ein Distributions-Repository in Deiner Datei _pom.xml_ mit einer `id` von `Github` erstellst, das auf Deinen {% data variables.product.prodname_registry %}-Endpunkt zeigt.
|
||||
|
||||
Wenn beispielsweise Deine Organisation „octocat“ und Dein Repository „hello-world“ heißt, sieht die {% data variables.product.prodname_registry %}-Konfiguration in _pom.xml_ so ähnlich wie im folgenden Beispiel aus.
|
||||
|
||||
{% raw %}
|
||||
```xml
|
||||
<project ...>
|
||||
...
|
||||
<distributionManagement>
|
||||
<repository>
|
||||
<id>github</id>
|
||||
<name>GitHub Packages</name>
|
||||
<url>https://maven.pkg.github.com/octocat/hello-world</url>
|
||||
</repository>
|
||||
</distributionManagement>
|
||||
</project>
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Mit dieser Konfiguration kannst Du einen Workflow erstellen, der Dein Paket in der {% data variables.product.prodname_registry %} veröffentlicht, indem Du die automatisch generierte _settings.xml_ verwendest.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to GitHub Packages
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish package
|
||||
run: mvn -B deploy
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Checkt eine Kopie des Projekt-Repositorys aus.
|
||||
1. Richtet das Java JDK ein und konfiguriert auch automatisch die Maven-Datei _settings.xml_, um Authentifizierung für das `github`-Maven-Repository hinzuzufügen, um die Umgebungsvariable `GITHUB_TOKEN` zu verwenden.
|
||||
1. {% data reusables.github-actions.publish-to-packages-workflow-step %}
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
### Pakete im Maven Central Repository und in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
Du kannst Deine Pakete sowohl im Maven Central Repository als auch in der {% data variables.product.prodname_registry %} veröffentlichen, indem Du die Aktion `setup-java` für jede Registry verwendest.
|
||||
|
||||
Stelle sicher, dass Deine Datei _pom.xml_ ein Distributionsmanagement-Repository sowohl für Dein {% data variables.product.prodname_dotcom %}-Repository als auch Deinen „Maven Central Repository“-Provider enthält. Wenn Du z.B. über das Hosting-Projekt OSSRH in das Central Repository deployst, solltest Du es vielleicht in einem Distributionsverwaltungs-Repository mit `ossrh` als `id` angeben, und Du solltest {% data variables.product.prodname_registry %} in einem Distributionsverwaltungs-Repository mit `github` als `id` setzen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Publish package to the Maven Central Repository and GitHub Packages
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Set up Java for publishing to Maven Central Repository
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
server-id: ossrh
|
||||
server-username: MAVEN_USERNAME
|
||||
server-password: MAVEN_PASSWORD
|
||||
- name: Publish to the Maven Central Repository
|
||||
run: mvn -B deploy
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
- name: Set up Java for publishing to GitHub Packages
|
||||
uses: actions/setup-java@v1
|
||||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish to GitHub Packages
|
||||
run: mvn -B deploy
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Dieser Workflow ruft die Aktion `setup-java` zweimal auf. Jedes Mal, wenn die Aktion `setup-java` ausgeführt wird, überschriebt sie die Maven-Datei _settings.xml_ zum Publizieren von Paketen. Für die Authentifizierung im Repository verweist die Datei _settings.xml_ auf die `id` des Distributionsverwaltungs-Repositorys sowie den Benutzernamen und das Kennwort.
|
||||
|
||||
Dieser Workflow führt die folgenden Schritte aus:
|
||||
|
||||
1. Checkt eine Kopie des Projekt-Repositorys aus.
|
||||
1. Ruft `setup-java` zum ersten Mal auf. Dies konfiguriert die Maven-Datei _settings.xml_ für das Repository `ossrh` und setzt die Authentifizierungsoptionen auf Umgebungsvariablen, die im nächsten Schritt definiert werden.
|
||||
1. {% data reusables.github-actions.publish-to-maven-workflow-step %}
|
||||
1. Ruft `setup-java` zum zweiten Mal auf. Dies konfiguriert automatisch die Maven-Datei _settings.xml_ für {% data variables.product.prodname_registry %}.
|
||||
1. {% data reusables.github-actions.publish-to-packages-workflow-step %}
|
||||
|
||||
Weitere Informationen zur Verwendung von Geheimnissen in Deinem Workflow findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
@@ -0,0 +1,210 @@
|
||||
---
|
||||
title: Node.js-Pakete veröffentlichen
|
||||
intro: Du kannst Node.js-Pakete als Teil Deines Workflows zur kontinuierlichen Integrations (CI) in einer Registry veröffentlichen.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages
|
||||
- /actions/language-and-framework-guides/publishing-nodejs-packages
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der Node.js Pakete nach den Tests der fortlaufenden Integration (CI) in die {% data variables.product.prodname_registry %} und npm Registrierungen veröffentlicht. Mit einem einzigen Workflow kannst Du Pakete in einer einzigen Registry oder in mehreren Registries veröffentlichen.
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
Wir empfehlen, dass Du ein grundlegendes Verständnis von Workflowkonfigurations-Optionen hast und darüber, wie Du eine Workflow-Datei erstellst. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
Weitere Informationen zum Erstellen eines CI-Workflows für Dein Node.js-Projekt findest Du unter „[Node.js mit {% data variables.product.prodname_actions %} verwenden](/actions/automating-your-workflow-with-github-actions/using-nodejs-with-github-actions)“.
|
||||
|
||||
Vielleicht findest Du es auch hilfreich, ein grundlegendes Verständnis von Folgendem zu haben:
|
||||
|
||||
- „[Konfiguration von npm für die Verwendung mit {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages/configuring-npm-for-use-with-github-packages)“
|
||||
- "[Environment variables](/actions/reference/environment-variables)"
|
||||
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
|
||||
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
|
||||
|
||||
### Informationen zur Paketkonfiguration
|
||||
|
||||
Die Felder `name` und `version` in der Datei *package.json* bilden eine eindeutige Kennung. Registries verwenden diese Kennung, um Dein Paket mit einer Registry zu verknüpfen. Du kannst eine Zusammenfassung für die Paketlisten-Seite hinzufügen, indem Du in die Datei *package.json* ein Feld `description` einfügst. Weitere Informationen findest Du unter „[Eine Datei package.json erstellen](https://docs.npmjs.com/creating-a-package-json-file)“ und „[Node.js-Module erstellen](https://docs.npmjs.com/creating-node-js-modules)“ in der npm-Dokumentation.
|
||||
|
||||
Wenn eine lokale Datei *.npmrc* existiert, in der ein Wert `registry` angegeben ist, dann verwendet der Befehl `npm publish` die in der Datei *.npmrc* konfigurierte Registry. {% data reusables.github-actions.setup-node-intro %}
|
||||
|
||||
Du kannst die auf dem Runner installierte Node.js-Version mit der Aktion `setup-node` angeben.
|
||||
|
||||
Wenn Du Schritte in Deinen Workflow einfügst, um die `publishConfig`-Felder in Deiner *package.json*-Datei zu konfigurieren, brauchst Du die Registry-URL nicht mittels der Aktion `setup-node` anzugeben, aber Du kannst das Paket in nur einer einzigen Registry veröffentlichen. Weitere Informationen finden Sie unter „[publishConfig](https://docs.npmjs.com/files/package.json#publishconfig)“ in der NPM-Dokumentation.
|
||||
|
||||
### Pakete in der npm-Registry veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel wird von dem Ereignis `release` vom Typ `created` angestoßen. Der Workflow veröffentlicht das Paket im npm-Registry sofern es die CI-Tests besteht.
|
||||
|
||||
Um in Deinem Workflow authentifizierte Operationen gegenüber der npm-Registry durchzuführen, musst Du Dein npm-Authentifizierungstoken als Geheimnis in Deinen Repository-Einstellungen ablegen. Erstelle z.B. ein Geheimnis namens `NPM_TOKEN`. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
Standardmäßig verwendet npm das Feld `name` der Datei *package.json*, um die npm-Registry zu ermitteln. Wenn Du in einem globalen Namespace veröffentlichst, brauchst Du nur den Paketnamen anzugeben. Zum Beispiel würdest Du ein Paket namens `npm-hello-world-test` auf `https://www.npmjs.com/package/npm-hello-world-test` veröffentlichen.
|
||||
|
||||
Wenn Du ein Paket veröffentlichst, das einen Präfix für den „scope“ (Geltungsbereich) enthält, dann füge den Geltungsbereich als `name` in Deine Datei *package.json* ein. Wenn beispielsweise Dein Präfix für den npm-scope „octocat“ und der Paketname „hello-world“ ist, dann sollte der `name` in Deiner Datei *package.json* auf `@octocat/hallo-world` gesetzt sein. Wenn Dein npm-Paket einen Scope-Präfix verwendet und das Paket öffentlich ist, musst Du die Option `npm publish --access public` verwenden. Dies ist eine Option, die npm verlangt, um zu verhindern, dass jemand versehentlich ein privates Paket veröffentlicht.
|
||||
|
||||
Dieses Beispiel speichert das Geheimnis `NPM_TOKEN` in der Umgebungsvariablen `NODE_AUTH_TOKEN`. Wenn die Aktion `setup-node` eine Datei *.npmrc* erzeugt, referenziert sie das Token aus der Umgebungsvariable `NODE_AUTH_TOKEN`.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js Package
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Datei .npmrc zur Veroeffentlichung auf npm einrichten
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
- run: npm install
|
||||
- run: npm publish
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Im obigen Beispiel erzeugt die Aktion `setup-node` auf dem Runner eine Datei *.npmrc* mit folgendem Inhalt:
|
||||
|
||||
```
|
||||
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
|
||||
registry=https://registry.npmjs.org/
|
||||
always-auth=true
|
||||
```
|
||||
|
||||
### Pakete in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
Jedes Mal, wenn Du ein neues Release erstellst, kannst Du einen Workflow anstoßen, um Dein Paket zu veröffentlichen. Der Workflow im folgenden Beispiel läuft jedes Mal, wenn das Ereignis `release` vom Typ `created` auftritt. Der Workflow veröffentlicht das Paket in {% data variables.product.prodname_registry %} , wenn die CI-Tests bestanden wurden.
|
||||
|
||||
Standardmäßig veröffentlicht die {% data variables.product.prodname_registry %} ein Paket in dem Repository auf {% data variables.product.prodname_dotcom %}, das Du im Feld `name` der Datei *package.json* angibst. Ein Paket namens `@my-org/test` würde beispielsweise im Repository `my-org/test` auf {% data variables.product.prodname_dotcom %} veröffentlicht. Weitere Informationen finden Sie unter [„`npm-scope`“ (npm-Gültigkeitsbereich)](https://docs.npmjs.com/misc/scope) in der npm-Dokumentation.
|
||||
|
||||
Um authentifizierte Vorgänge für die Registry {% data variables.product.prodname_registry %} in Deinem Workflow kannst Du den `GITHUB_TOKEN` verwenden. Der `GITHUB_TOKEN` existiert standardmäßig in Deinem Repository und hat Lese- und Schreibrechte für Pakete in dem Repository, in dem der Workflow läuft. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
Dieses Beispiel speichert das Geheimnis `GITHUB_TOKEN` in der Umgebungsvariablen `NODE_AUTH_TOKEN`. Wenn die Aktion `setup-node` eine Datei *.npmrc* erzeugt, referenziert sie das Token aus der Umgebungsvariable `NODE_AUTH_TOKEN`.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js Package
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to GitHub Packages
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://npm.pkg.github.com'
|
||||
# Defaults to the user or organization that owns the workflow file
|
||||
scope: '@octocat'
|
||||
- run: npm install
|
||||
- run: npm publish
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Die Aktion `setup-node` erzeugt eine Datei *.npmrc* auf dem Runner. Wenn Du für die Aktion `setup-node` die Eingabe `scope` verwendest, enthält die Datei *.npmrc* das Präfix „scope“. Standardmäßig legt die Aktion `setup-node` den „Scope“ (Geltungsbereich) in der Datei *.npmrc* auf das Konto fest, das diese Workflow-Datei enthält.
|
||||
|
||||
```
|
||||
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
|
||||
@octocat:registry=https://npm.pkg.github.com
|
||||
always-auth=true
|
||||
```
|
||||
|
||||
### Pakete mittels „Yarn“ veröffentlichen
|
||||
|
||||
Wenn Du den Paketmanager „Yarn“ verwendest, kannst Du mit Yarn Pakete installieren und veröffentlichen.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js Package
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
# Defaults to the user or organization that owns the workflow file
|
||||
scope: '@octocat'
|
||||
- run: yarn
|
||||
- run: yarn publish
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Pakete auf npm und in der {% data variables.product.prodname_registry %} veröffentlichen
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Wenn Du in Registries mit unterschiedlichen „Scope“-Präfixen publizieren musst, dann musst Du die Datei *package.json* auf dem Runner anpassen, um das „Scope“-Präfix zu ändern. Wenn Du beispielsweise ein Paket im Geltungsbereich `@mona` für npm und `@octocat` für {% data variables.product.prodname_registry %}veröffentlichst, kannst Du nach der Veröffentlichung auf npm und vor der Veröffentlichung in der {% data variables.product.prodname_registry %} auf dem Runner in der Datei *package.json* den Geltungsbereich `@mona` durch `@octocat` ersetzen.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Du kannst Deine Pakete sowohl in der npm-Registry als auch in {% data variables.product.prodname_registry %} veröffentlichen, indem Du die Aktion `setup-node` für jede Registry verwendest.
|
||||
|
||||
Wenn Du ein Paket in beiden Registries veröffentlichst, musst Du sicherstellen, dass Dein „Scope“-Präfix auf npm mit Deinem Benutzer- oder Organisationsnamen in {% data variables.product.prodname_dotcom %} übereinstimmt. Um Pakete in einer öffentlichen Registry mit einem „Scope“-Präfix zu veröffentlichen, kannst Du den Befehl `npm publish --access public` verwenden. Weitere Informationen findest Du unter [`npm-scope`](https://docs.npmjs.com/misc/scope) und „[Öffentliche Pakete mit „Scope“ (Geltungsbereich) anlegen und veröffentlichen](https://docs.npmjs.com/creating-and-publishing-scoped-public-packages)“ in der npm-Dokumentation.
|
||||
|
||||
Stelle sicher, dass in Deiner Datei *package.json* den Geltungsbereich Deines {% data variables.product.prodname_dotcom %}-Repositorys und der npm-Registry angegeben ist. Wenn Du beispielsweise ein Paket im Repository `octocat/npm-hello-world-test` auf {% data variables.product.prodname_dotcom %} und https://www.npmjs.com/package/@octocat/npm-hello-world-test veröffentlichen willst, dann sollte in Deiner Datei *package.json* der Name `"name": "@octocat/npm-hello-world-test"` stehen.
|
||||
|
||||
Um authentifizierte Vorgänge für die Registry {% data variables.product.prodname_registry %} in Deinem Workflow kannst Du den `GITHUB_TOKEN` verwenden. Der `GITHUB_TOKEN` existiert standardmäßig in Deinem Repository und hat Lese- und Schreibrechte für Pakete in dem Repository, in dem der Workflow läuft. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
|
||||
|
||||
Wenn Du für die Aktion `setup-node` die Eingabe `scope` verwendest, erstellt die Aktion eine Datei *.npmrc* mit dem Präfix „scope“. Standardmäßig legt die Aktion `setup-node` den Geltungsbereich in der Datei *.npmrc* auf den Benutzer oder die Organisation fest, der die Workflow-Datei gehört.
|
||||
|
||||
Dieser Workflow ruft die Aktion `setup-node` zweimal auf. Jedes Mal, wenn die Aktion `setup-node` ausgeführt wird, überschreibt sie die Datei *.npmrc*. Die Datei *.npmrc* referenziert den Token, mit dem Du authentifizierte Operationen in der Paket-Registry durchführen kannst, durch die Umgebungsvariable `NODE_AUTH_TOKEN`. Der Workflow setzt die Umgebungsvariable `NODE_AUTH_TOKEN` jedes Mal, wenn der Befehl `npm publish` ausgeführt wird; zuerst mit einem Token zum Veröffentlichen auf npm (`NPM_TOKEN`) und dann mit einem Token zum Veröffentlichen in der {% data variables.product.prodname_registry %} (`GITHUB_TOKEN`).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Node.js Package
|
||||
on:
|
||||
release:
|
||||
types: [created]
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '10.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
- run: npm install
|
||||
# Publish to npm
|
||||
- run: npm publish --access public
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
# Setup .npmrc file to publish to GitHub Packages
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
registry-url: 'https://npm.pkg.github.com'
|
||||
# Defaults to the user or organization that owns the workflow file
|
||||
scope: '@octocat'
|
||||
# Publish to GitHub Packages
|
||||
- run: npm publish
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Setting up continuous integration using workflow templates
|
||||
shortTitle: Setting up CI using templates
|
||||
intro: Du kannst die fortlaufende Integration für Dein Projekt mithilfe einer Workflow-Vorlage einrichten, die der Sprache und den Tools entspricht, die Du verwenden möchtest.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/setting-up-continuous-integration-using-github-actions
|
||||
- /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions
|
||||
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Jeder Benutzer mit Schreibberechtigung für ein Repository kann mit {% data variables.product.prodname_actions %} eine fortlaufende Integration (CI) einrichten.
|
||||
|
||||
Nach der Einrichtung der CI können Sie den Workflow an Ihre Bedürfnisse anpassen.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. Wähle die Vorlage aus, die der Sprache und den Tools entspricht, die Du verwenden möchtest, und klicke dann auf **Set up this workflow** (Diesen Workflow einrichten). 
|
||||
5. Klicke auf **Start commit** (Commit starten). 
|
||||
{% data reusables.files.write_commit_message %}
|
||||
{% data reusables.files.choose_commit_branch %}
|
||||
{% data reusables.files.propose_new_file %}
|
||||
|
||||
Sobald ein Push an Ihr Repository erfolgt ist, können Sie den Status und die detaillierten Protokolle Ihres fortlaufenden Integrationsworkflows verfolgen, der auf {% data variables.product.prodname_dotcom %} ausgeführt wird, und angepasste Benachrichtigungen erhalten. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#github-actions-notification-options)“ und „[Workflowausführung verwalten](/articles/managing-a-workflow-run)“.
|
||||
|
||||
{% data reusables.repositories.actions-workflow-status-badge-into %}
|
||||
|
||||
For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- „[Informationen zur kontinuierlichen Integration](/articles/about-continuous-integration)“
|
||||
- „[Einen Workflow-Lauf verwalten](/articles/managing-a-workflow-run)“
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
- „[Abrechnung für {{ site.data.variables.product.prodname_actions }} verwalten](/github/setting-up-and-managing-billing-and-payments-on-github/managing-billing-for-github-actions)“
|
||||
{% endif %}
|
||||
@@ -0,0 +1,249 @@
|
||||
---
|
||||
title: Storing workflow data as artifacts
|
||||
shortTitle: Storing workflow artifacts
|
||||
intro: Mit Artefakten kannst Du Daten zwischen Aufträgen in einem Workflow freigeben und Daten nach Abschluss des Workflows speichern.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/persisting-workflow-data-using-artifacts
|
||||
- /github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts
|
||||
- /actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts
|
||||
- /actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu Workflow-Artefakten
|
||||
|
||||
Artefakte erlauben es dir, Daten nach dem Job-Abschluss abzuspeichern und diese Daten an einen anderen Job im selben Workflow weiterzugeben. Ein Artefakt ist eine Datei oder eine Dateisammlung, die während einer Workflow-Ausführung erstellt wird. Zum Beispiel kannst Du Artefakte verwenden, um Deine Build- und Testausgabe zu speichern, nachdem ein Workflow-Lauf beendet ist.
|
||||
|
||||
{% data reusables.github-actions.artifact-log-retention-statement %} The retention period for a pull request restarts each time someone pushes a new commit to the pull request.
|
||||
|
||||
Dies sind einige der gängigen Artefakte, die du hochladen kannst:
|
||||
|
||||
- Protokolldateien und Coredumps
|
||||
- Testergebnisse, Fehler und Screenshots
|
||||
- Binäre oder komprimierte Dateien
|
||||
- Ergebnisse zur Stresstest-Leistungsausgabe und Codeabdeckung
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
Das Speichern von Artefakten verwendet Speicherplatz auf {% data variables.product.product_name %}. {% data reusables.github-actions.actions-billing %} Weitere Informationen findest Du unter „[Abrechnung für {% data variables.product.prodname_actions %} verwalten](/github/setting-up-and-managing-billing-and-payments-on-github/managing-billing-for-github-actions)“.
|
||||
|
||||
{% else %}
|
||||
|
||||
Artefakte verfallen automatisch nach 90 Tagen, aber du kannst jederzeit den verwendeten Speicher auf {% data variables.product.prodname_actions %} wieder verfügbar machen, indem du Artefakte löschst, bevor sie auf {% data variables.product.product_name %} ablaufen.
|
||||
|
||||
{% endif %}
|
||||
|
||||
Artefakte werden während eines Workflow-Laufs hochgeladen und Du kannst den Namen und die Größe eines Artefakts in der Benutzeroberfläche anzeigen. Wenn ein Artefakt mit der {% data variables.product.product_name %}-Oberfläche heruntergeladen wird, werden alle Dateien, die als Teil des Artefakts einzeln hochgeladen wurden, zusammen in eine einzige Datei gezippt. Die Abrechnung erfolgt anhand der Größe des hochgeladenen Artefakts und nicht der Größe der Zip-Datei erfolgt.
|
||||
|
||||
{% data variables.product.product_name %} bietet zwei Aktionen, über die Sie Build-Artefakte hoch- und herunterladen können. For more information, see the {% if currentVersion == "free-pro-team@latest" %}[actions/upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `actions/upload-artifact` and `download-artifact` actions on {% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
Daten zwischen Aufträgen freigeben:
|
||||
|
||||
* **Dateien hochladen**: Gib der hochgeladenen Datei einen Namen und lade die Daten hoch, bevor der Job endet.
|
||||
* **Dateien herunterladen**: Du kannst nur Artefakte herunterladen, die während des gleichen Workflow-Laufs hochgeladen wurden. Wenn Du eine Datei herunterlädst, kannst Du sie mit Namen referenzieren.
|
||||
|
||||
Die Steps („Schritte“) eines Jobs teilen sich die selbe Umgebung auf der Runner-Maschine, laufen aber in ihren eigenen individuellen Prozessen. Mithilfe von Ein- und Ausgaben können Sie Daten zwischen den Schritten in einem Auftrag weitergeben. Weitere Informationen zu Ein- und Ausgaben finden Sie unter „[Metadatensyntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)“.
|
||||
|
||||
### Build- und Testartefakte hochladen
|
||||
|
||||
Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Deinen Code zu bauen und zu testen. For more information about using {% data variables.product.prodname_actions %} to perform CI, see "[About continuous integration](/articles/about-continuous-integration)."
|
||||
|
||||
Durch die Ergebnisse der Erstellung und des Tests Deines Codes werden oft zum Debuggen von Testfehlern einsetzbare Dateien und bereitstellbarer Produktionscode erstellt. Du kannst einen Workflow konfigurieren, um den per Push-Vorgang an Dein Repository übertragenen Code zu erstellen und zu testen und um einen erfolgreichen oder fehlerhaften Status zu melden. Du kannst die Build- und Testausgabe hochladen, um sie für Bereitstellungen, zum Debuggen fehlerhafter Tests oder von Abstürzen und zum Anzeigen der Testsuite-Abdeckung zu verwenden.
|
||||
|
||||
Du kannst die Aktion `upload-artifact` verwenden um Artefakte hochzuladen. Beim Hochladen eines Artefakts können Sie eine einzelne Datei oder ein Verzeichnis oder mehrere Dateien oder Verzeichnisse angeben. Sie können auch bestimmte Dateien oder Verzeichnisse ausschließen und Platzhaltermuster verwenden. Es wird empfohlen, einen Namen für ein Artefakt bereitzustellen, aber wenn kein Name angegeben wird, wird `Artefakt` als Standardname verwendet. For more information on syntax, see the {% if currentVersion == "free-pro-team@latest" %}[actions/upload-artifact](https://github.com/actions/upload-artifact) action{% else %} `actions/upload-artifact` action on {% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
#### Beispiel
|
||||
|
||||
Zum Beispiel kann Dein Projektarchiv oder eine Webanwendung SASS- und TypeScript-Dateien enthalten, die Du in CSS und JavaScript konvertieren musst. Falls Dein Build-Konfiguration die kompilierten Dateien im Verzeichnis `dist` ausgibt, würdest Du die im Verzeichnis `dist` enthaltenen Dateien auf Deinem Webanwendungsserver bereitstellen, sofern alle Tests erfolgreich abgeschlossen werden.
|
||||
|
||||
```
|
||||
|-- hello-world (repository)
|
||||
| └── dist
|
||||
| └── tests
|
||||
| └── src
|
||||
| └── sass/app.scss
|
||||
| └── app.ts
|
||||
| └── output
|
||||
| └── test
|
||||
|
|
||||
```
|
||||
|
||||
In diesem Beispiel wird gezeigt, wie Du einen Workflow für ein Node.js-Projekt erstellst, das den Code im `src`-Verzeichnis `erstellt` und die Tests im `tests`-Verzeichnis ausführt. Wenn `npm test` ausgeführt wird, wird im Verzeichnis `output/test/` ein Bericht zur Codeabdeckung mit dem Namen `code-coverage.html` erstellt und gespeichert.
|
||||
|
||||
Der Workflow lädt die Produktionsartefakte in das `dist` Verzeichnis, schließt jedoch alle Markdowndateien aus. Es lädt auch die `code-coverage.html` Bericht als ein weiteres Artefakt.
|
||||
|
||||
```yaml
|
||||
Name: Node CI
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build_and_test:
|
||||
läuft auf: ubuntu-latest
|
||||
schritte:
|
||||
- name: Checkout repository
|
||||
verwendet: actions/checkout@v2
|
||||
- name: npm install, build, and test
|
||||
run: |
|
||||
npm installieren sie
|
||||
npm run build --if-present
|
||||
npm test
|
||||
- name: Archiv production artifacts
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: dist-without-markdown
|
||||
path: |
|
||||
dist
|
||||
!dist/**/*md
|
||||
- Name: Archivcodeabdeckungsergebnisse
|
||||
verwendet: Aktionen/Upload-artifact@v2
|
||||
mit:
|
||||
Name: code-coverage-report
|
||||
pfad: output/test/code-coverage.html
|
||||
```
|
||||
|
||||
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
### Configuring a custom artifact retention period
|
||||
|
||||
You can define a custom retention period for individual artifacts created by a workflow. When using a workflow to create a new artifact, you can use `retention-days` with the `upload-artifact` action. This example demonstrates how to set a custom retention period of 5 days for the artifact named `my-artifact`:
|
||||
|
||||
```
|
||||
- name: 'Upload Artifact'
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: my-artifact
|
||||
path: my_file.txt
|
||||
retention-days: 5
|
||||
```
|
||||
|
||||
The `retention-days` value cannot exceed the retention limit set by the repository, organization, or enterprise.
|
||||
{% endif %}
|
||||
|
||||
### Artefakte herunterladen oder löschen
|
||||
|
||||
During a workflow run, you can use the [`download-artifact`](https://github.com/actions/download-artifact)action to download artifacts that were previously uploaded in the same workflow run.
|
||||
|
||||
After a workflow run has been completed, you can download or delete artifacts on {% data variables.product.prodname_dotcom %} or using the REST API. For more information, see "[Downloading workflow artifacts](/actions/managing-workflow-runs/downloading-workflow-artifacts)," "[Removing workflow artifacts](/actions/managing-workflow-runs/removing-workflow-artifacts)," and the "[Artifacts REST API](/v3/actions/artifacts/)."
|
||||
|
||||
#### Herunterladen von Artefakten während einer Workflowausführung
|
||||
|
||||
The [`actions/download-artifact`](https://github.com/actions/download-artifact) action can be used to download previously uploaded artifacts during a workflow run.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Sie können nur Artefakte in einem Workflow herunterladen, die während desselben Workflowlaufs hochgeladen wurden.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Geben Sie den Namen eines Artefakts an, um ein einzelnes Artefakt herunterzuladen. Wenn Sie ein Artefakt hochgeladen haben, ohne einen Namen anzugeben, lautet der Standardname `Artefakt`.
|
||||
|
||||
```yaml
|
||||
- Name: Laden Sie ein einzelnes Artefakt
|
||||
verwendet: Aktionen/Download-artifact@v2
|
||||
mit:
|
||||
Name: my-artifact
|
||||
```
|
||||
|
||||
Sie können auch alle Artefakte in einem Workflow herunterladen, der ausgeführt wird, indem Sie keinen Namen angeben. Dies kann nützlich sein, wenn Sie mit vielen Artefakten arbeiten.
|
||||
|
||||
```yaml
|
||||
- Name: Laden Sie alle Workflow-Ausführungsartefakte
|
||||
verwendet: Aktionen/Download-artifact@v2
|
||||
```
|
||||
|
||||
Wenn Sie alle Artefakte einer Workflowausführung herunterladen, wird ein Verzeichnis für jedes Artefakt mit seinem Namen erstellt.
|
||||
|
||||
For more information on syntax, see the {% if currentVersion == "free-pro-team@latest" %}[actions/download-artifact](https://github.com/actions/download-artifact) action{% else %} `actions/download-artifact` action on {% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
### Daten zwischen Aufträgen in einem Workflow weitergeben
|
||||
|
||||
Du kannst die Aktionen `upload-artifact` und `download-artifact` verwenden, um innerhalb eines Workflows Daten zwischen Jobs auszutauschen. In diesem Beispiel-Workflow wird veranschaulicht, wie Daten zwischen Aufträgen im selben Workflow weitergegeben werden. For more information, see the {% if currentVersion == "free-pro-team@latest" %}[actions/upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `actions/upload-artifact` and `download-artifact` actions on {% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
Von den Artefakten eines vorherigen Auftrags abhängige Aufträge müssen auf den erfolgreichen Abschluss des abhängigen Auftrags warten. Bei diesem Workflow kommt das Stichwort `needs` zum Einsatz, um sicherzustellen, dass `job_1`, `job_2` und `job_3` sequenziell ausgeführt werden. Beispielsweise schreibt `job_2` vor, dass `job_1` die Syntax `needs: job_1` verwendet.
|
||||
|
||||
Auftrag 1 führt die folgenden Schritte durch:
|
||||
- Führt eine mathematische Berechnung aus und speichert das Ergebnis in einer Textdatei namens `math-homework.txt`.
|
||||
- Verwendet die Aktion `upload-artifact`, um die Datei `math-homework.txt` mit dem Namen `homework` hochzuladen. Die Aktion platziert die Datei in einem Verzeichnis mit dem Namen `homework`.
|
||||
|
||||
Auftrag 2 verwendet das Ergebnis des vorherigen Auftrags:
|
||||
- Lädt das im vorherigen Auftrag hochgeladene `homework`-Artefakt herunter. Die Aktion `download-artifact` lädt die Artefakte standardmäßig in das Verzeichnis der Arbeitsoberfläche, in dem der Schritt ausgeführt wird. Du kannst den Eingabeparameter `path` verwenden, um ein anderes Download-Verzeichnis anzugeben.
|
||||
- Liest den Wert in der Datei `homework/math-homework.txt`, führt eine mathematische Berechnung durch und speichert das Ergebnis in `math-homework.txt`.
|
||||
- Lädt die Datei `math-homework.txt` hoch. Dieser Upload überschreibt den vorherigen Upload, da beide Uploads den gleichen Namen haben.
|
||||
|
||||
Auftrag 3 zeigt das im vorherigen Auftrag hochgeladene Ergebnis an:
|
||||
- Lädt das `homework`-Artefakt herunter.
|
||||
- Gibt das Ergebnis der mathematischen Gleichung im Protokoll aus.
|
||||
|
||||
Die vollständige, in diesem Workflow-Beispiel durchgeführte mathematische Operation lautet `(3 + 7) x 9 = 90`.
|
||||
|
||||
```yaml
|
||||
name: Daten zwischen Jobs
|
||||
|
||||
teilen: [push]
|
||||
|
||||
Jobs:
|
||||
job_1:
|
||||
Name: Hinzufügen von 3 und 7
|
||||
-Runs-on: ubuntu-latest
|
||||
Schritte:
|
||||
- shell: bash
|
||||
run: |
|
||||
expr 3 + 7 > math-homework.txt
|
||||
- Name: Math-Ergebnis für Job 1
|
||||
verwendet: Aktionen/Upload-artifact@v2
|
||||
mit:
|
||||
Name: Hausaufgaben
|
||||
Pfad: math-homework.txt
|
||||
|
||||
job_2:
|
||||
Name: Multiplizieren mit 9
|
||||
benötigt: job_1
|
||||
-Run-on: Windows-neueste
|
||||
Schritte:
|
||||
- Name: Download Mathe-Ergebnis für Job 1
|
||||
verwendet: Aktionen
|
||||
|
||||
|
||||
artifact@v2
|
||||
/
|
||||
value='cat math-homework.txt'
|
||||
expr $value '* 9 > math-homework.txt
|
||||
- Name: Math-Ergebnis für Job 2
|
||||
verwendet: aktionen/upload-artifact@v2
|
||||
mit:
|
||||
Name: Hausaufgaben
|
||||
Pfad: math-homework.txt
|
||||
|
||||
job_3:
|
||||
Name: Anzeigeergebnisse
|
||||
Bedürfnisse: job_2
|
||||
-Auslauf: macOS-neueste
|
||||
Schritte:
|
||||
- Name: Mathematisches Ergebnis für Job 2
|
||||
verwendet: Aktionen/Download-artifact@v2
|
||||
mit:
|
||||
Name: Hausaufgaben
|
||||
- Name: Drucken sie das Endergebnis
|
||||
Shell: bash
|
||||
run: |
|
||||
value='cat math-homework.txt'
|
||||
echo Das Ergebnis ist $value
|
||||
```
|
||||
|
||||
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- "[ Abrechnung für {% data variables.product.prodname_actions %} verwalten](/github/setting-up-and-managing-billing-and-payments-on-github/managing-billing-for-github-actions)".
|
||||
|
||||
{% endif %}
|
||||
@@ -53,6 +53,15 @@ You can use any machine as a self-hosted runner as long at it meets these requir
|
||||
* Der Rechner verfügt über genügend Hardwareressourcen für den Typ der Workflows, den Du ausführen möchtest. Die Anwendung für selbst-gehostete Runner selbst erfordert nur minimale Ressourcen.
|
||||
* Wenn Du Workflows ausführen willst, die Docker-Container-Aktionen oder Service-Container verwenden, brauchst Du eine Linux-Maschine und Docker muss installiert sein.
|
||||
|
||||
### Nutzungseinschränkungen
|
||||
|
||||
There are some limits on {% data variables.product.prodname_actions %} usage when using self-hosted runners. Die Einschränkungen können sich jederzeit ändern.
|
||||
|
||||
{% data reusables.github-actions.usage-workflow-run-time %}
|
||||
- **Job queue time** (Job-Warteschlangenzeit) - Jeder Auftrag für selbst-gehostete Läufer kann maximal 24 Stunden lang in die Warteschlange gestellt werden. Wenn ein selbst-gehosteter Läufer die Ausführung des Auftrags nicht innerhalb dieses Limits startet, wird der Auftrag beendet und kann nicht abgeschlossen werden.
|
||||
{% data reusables.github-actions.usage-api-requests %}
|
||||
- **Auftrags-Matrix** - {% data reusables.github-actions.usage-matrix-limits %}
|
||||
|
||||
### Unterstützte Betriebssysteme für selbst-gehostete Runner
|
||||
|
||||
The following operating systems are supported for the self-hosted runner application.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Selbst-gehostete Runner hinzufügen
|
||||
intro: 'Du kannst einen selbst-gehosteten Runner zu {% data variables.product.prodname_actions %} hinzufügen.'
|
||||
intro: 'Du kannst einen selbst-gehosteten Runner zu {{ site.data.variables.product.prodname_actions }} hinzufügen.'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/adding-self-hosted-runners
|
||||
- /actions/automating-your-workflow-with-github-actions/adding-self-hosted-runners
|
||||
@@ -51,7 +51,8 @@ You can add self-hosted runners to an enterprise, where they can be assigned to
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
To add a self-hosted runner to an enterprise account, you must be an enterprise owner.
|
||||
{% else if currentVersion != "free-pro-team@latest" and currentVersion ver_gt "enterprise-server@2.21"%}
|
||||
To add a self-hosted runner at the enterprise level of {% data variables.product.product_location %}, you must be a site administrator.
|
||||
To add a self-hosted runner at the enterprise level of
|
||||
{% data variables.product.product_location %}, you must be a site administrator.
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Die Anwendung für selbst-gehostete Runner als Dienst konfigurieren
|
||||
intro: 'Du kannst die Anwendung für selbst-gehostete Runner als Dienst konfigurieren, um die Runner-Anwendung automatisch zu starten, wenn der Rechner hochfährt.'
|
||||
intro: Du kannst die Anwendung für selbst-gehostete Runner als Dienst konfigurieren, um die Runner-Anwendung automatisch zu starten, wenn der Rechner hochfährt.
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/configuring-the-self-hosted-runner-application-as-a-service
|
||||
versions:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Deinen eigenen Runner hosten
|
||||
intro: 'Du kannst selbst-gehostete Runner erstellen, um Workflows in einer hochgradig anpassbaren Umgebung zu betreiben.'
|
||||
intro: Du kannst selbst-gehostete Runner erstellen, um Workflows in einer hochgradig anpassbaren Umgebung zu betreiben.
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/hosting-your-own-runners
|
||||
- /actions/automating-your-workflow-with-github-actions/hosting-your-own-runners
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Überwachung und Fehlerbehebung selbst-gehosteter Runner
|
||||
intro: 'Du kannst Deine selbst gehosteten Runner überwachen, um ihre Aktivität zu sehen und gewöhnliche Probleme zu diagnostizieren.'
|
||||
intro: Du kannst Deine selbst gehosteten Runner überwachen, um ihre Aktivität zu sehen und gewöhnliche Probleme zu diagnostizieren.
|
||||
redirect_from:
|
||||
- /actions/hosting-your-own-runners/checking-the-status-of-self-hosted-runners
|
||||
- /github/automating-your-workflow-with-github-actions/checking-the-status-of-self-hosted-runners
|
||||
@@ -13,7 +13,7 @@ versions:
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Den Status eines selbst-gehosteten Runners mittels {% data variables.product.prodname_dotcom %} überprüfen
|
||||
### Den Status eines selbst-gehosteten Runners mittels {{ site.data.variables.product.prodname_dotcom }} überprüfen
|
||||
|
||||
{% data reusables.github-actions.self-hosted-runner-management-permissions-required %}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Selbst-gehostete Runner entfernen
|
||||
intro: 'Du kannst einen selbst-gehosteten Runner dauerhaft von {% data variables.product.prodname_actions %} entfernen.'
|
||||
intro: 'Du kannst einen selbst-gehosteten Runner dauerhaft von {{ site.data.variables.product.prodname_actions }} entfernen.'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/removing-self-hosted-runners
|
||||
- /actions/automating-your-workflow-with-github-actions/removing-self-hosted-runners
|
||||
@@ -63,7 +63,8 @@ Um einen selbst-gehosteten Runner aus einer Organisation zu entfernen, musst Du
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
To remove a self-hosted runner from an enterprise account, you must be an enterprise owner. We recommend that you also have access to the self-hosted runner machine.
|
||||
{% else if currentVersion != "free-pro-team@latest" and currentVersion ver_gt "enterprise-server@2.21"%}
|
||||
Um einen selbst-gehosteten Runner aus einer Organisation zu entfernen, musst Du ein Organisationsinhaber sein. We recommend that you also have access to the self-hosted runner machine.
|
||||
To remove a self-hosted runner at the enterprise level of
|
||||
{% data variables.product.product_location %}, you must be a site administrator. We recommend that you also have access to the self-hosted runner machine.
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.github-actions.self-hosted-runner-reusing %}
|
||||
|
||||
@@ -33,8 +33,8 @@ versions:
|
||||
<!-- {% link_with_intro /reference %} -->
|
||||
|
||||
<!-- Article links -->
|
||||
<div class="d-flex gutter my-6 py-6">
|
||||
<div class="col-4">
|
||||
<div class="d-lg-flex gutter my-6 py-6">
|
||||
<div class="col-12 col-lg-4 mb-4 mb-lg-0">
|
||||
<div class="featured-links-heading pb-4">
|
||||
<h3 class="f5 text-normal text-mono underline-dashed color-gray-5">{% data ui.toc.getting_started %}</h3>
|
||||
</div>
|
||||
@@ -45,7 +45,7 @@ versions:
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="col-4">
|
||||
<div class="col-12 col-lg-4 mb-4 mb-lg-0">
|
||||
<div class="featured-links-heading pb-4">
|
||||
<h3 class="f5 text-normal text-mono underline-dashed color-gray-5">{% data ui.toc.popular_articles %}</h3>
|
||||
</div>
|
||||
@@ -56,7 +56,7 @@ versions:
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="col-4">
|
||||
<div class="col-12 col-lg-4 mb-4 mb-lg-0">
|
||||
<div class="featured-links-heading pb-4">
|
||||
<h3 class="f5 text-normal text-mono underline-dashed color-gray-5">Manage workflows</h3>
|
||||
</div>
|
||||
@@ -68,22 +68,28 @@ versions:
|
||||
</div>
|
||||
</div>
|
||||
<!-- Featured resources -->
|
||||
<div class="d-flex gutter my-6 py-6 text-center flex-items-stretch">
|
||||
<a href="/actions/creating-actions" class="col-4 mx-3 d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-blue text-white">{% octicon "bookmark" width="24" %}</div></div>
|
||||
<h4>Create actions</h4>
|
||||
<p class="mb-0">A complete guide to creating and sharing actions with the community.</p>
|
||||
</a>
|
||||
<a href="https://github.com/actions/starter-workflows" class="col-4 mx-3 d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-purple text-white">{% octicon "rocket" width="24" %}</div></div>
|
||||
<h4>Starter workflows</h4>
|
||||
<p class="mb-0">A collection of workflow files to help you get started with GitHub Actions.</p>
|
||||
</a>
|
||||
<a href="https://github.com/marketplace?type=actions" class="col-4 mx-3 d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-orange text-white">{% octicon "light-bulb" width="24" %}</div></div>
|
||||
<h4>GitHub Actions Marketplace</h4>
|
||||
<p class="mb-0">Explore community actions and supercharge your workflow.</p>
|
||||
</a>
|
||||
<div class="d-lg-flex gutter-lg my-6 py-6 text-center flex-items-stretch">
|
||||
<div class="col-12 col-lg-4 mb-2 mb-lg-0">
|
||||
<a href="/actions/creating-actions" class="d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-blue text-white">{% octicon "bookmark" width="24" %}</div></div>
|
||||
<h4>Create actions</h4>
|
||||
<p class="mb-0">A complete guide to creating and sharing actions with the community.</p>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-12 col-lg-4 mb-2 mb-lg-0">
|
||||
<a href="https://github.com/actions/starter-workflows" class="d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-purple text-white">{% octicon "rocket" width="24" %}</div></div>
|
||||
<h4>Starter workflows</h4>
|
||||
<p class="mb-0">A collection of workflow files to help you get started with GitHub Actions.</p>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-12 col-lg-4 mb-2 mb-lg-0">
|
||||
<a href="https://github.com/marketplace?type=actions" class="d-block text-gray-dark no-underline hover-grow Box p-5 bg-gray-light">
|
||||
<div class="mb-4 d-flex flex-justify-center"><div class="circle p-3 bg-orange text-white">{% octicon "light-bulb" width="24" %}</div></div>
|
||||
<h4>GitHub Actions Marketplace</h4>
|
||||
<p class="mb-0">Explore community actions and supercharge your workflow.</p>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Code examples -->
|
||||
@@ -91,7 +97,7 @@ versions:
|
||||
<h2 class="mb-2">Leitfäden</h2>
|
||||
|
||||
<div class="d-flex flex-wrap gutter">
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/building-and-testing-nodejs">
|
||||
<div class="p-4">
|
||||
<h4>Building and testing Node.js</h4>
|
||||
@@ -107,7 +113,7 @@ versions:
|
||||
</footer>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/building-and-testing-python">
|
||||
<div class="p-4">
|
||||
<h4>Building and testing Python</h4>
|
||||
@@ -123,7 +129,7 @@ versions:
|
||||
</footer>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/building-and-testing-java-with-maven">
|
||||
<div class="p-4">
|
||||
<h4>Building and testing Java with Maven</h4>
|
||||
@@ -139,7 +145,7 @@ versions:
|
||||
</footer>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/building-and-testing-java-with-gradle">
|
||||
<div class="p-4">
|
||||
<h4>Building and testing Java with Gradle</h4>
|
||||
@@ -155,7 +161,7 @@ versions:
|
||||
</footer>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/building-and-testing-java-with-ant">
|
||||
<div class="p-4">
|
||||
<h4>Building and testing Java with Ant</h4>
|
||||
@@ -171,7 +177,7 @@ versions:
|
||||
</footer>
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-4 mb-4">
|
||||
<div class="col-12 col-lg-4 mb-4">
|
||||
<a class="Box d-block hover-grow no-underline text-gray-dark" href="/actions/guides/publishing-nodejs-packages">
|
||||
<div class="p-4">
|
||||
<h4>Publishing Node.js packages</h4>
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Essential features of GitHub Actions
|
||||
shortTitle: Essential features
|
||||
intro: '{% data variables.product.prodname_actions %} are designed to help you build robust and dynamic automations. This guide will show you how to craft {% data variables.product.prodname_actions %} workflows that include environment variables, customized scripts, and more.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
{% data variables.product.prodname_actions %} allow you to customize your workflows to meet the unique needs of your application and team. In this guide, we'll discuss some of the essential customization techniques such as using variables, running scripts, and sharing data and artifacts between jobs.
|
||||
|
||||
### Using variables in your workflows
|
||||
|
||||
{% data variables.product.prodname_actions %} include default environment variables for each workflow run. If you need to use custom environment variables, you can set these in your YAML workflow file. This example demonstrates how to create custom variables named `POSTGRES_HOST` and `POSTGRES_PORT`. These variables are then available to the `node client.js` script.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- name: Connect to PostgreSQL
|
||||
run: node client.js
|
||||
env:
|
||||
POSTGRES_HOST: postgres
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
|
||||
Weitere Informationen findest Du unter „[Umgebungsvariablen verwenden](/actions/configuring-and-managing-workflows/using-environment-variables)“.
|
||||
|
||||
### Adding scripts to your workflow
|
||||
|
||||
You can use actions to run scripts and shell commands, which are then executed on the assigned runner. This example demonstrates how an action can use the `run` keyword to execute `npm install -g bats` on the runner.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- run: npm install -g bats
|
||||
```
|
||||
|
||||
For example, to run a script as an action, you can store the script in your repository and supply the path and shell type.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- name: Run build script
|
||||
run: ./.github/scripts/build.sh
|
||||
shell: bash
|
||||
```
|
||||
|
||||
Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)“.
|
||||
|
||||
### Sharing data between jobs
|
||||
|
||||
If your job generates files that you want to share with another job in the same workflow, or if you want to save the files for later reference, you can store them in {% data variables.product.prodname_dotcom %} as _artifacts_. Artefakte sind die Dateien, die erstellt werden, wenn Sie Ihren Code erstellen und testen. Artefakte können beispielsweise Binär- oder Paketdateien, Testergebnisse, Screenshots oder Protokolldateien sein. Artifacts are associated with the workflow run where they were created and can be used by another job.
|
||||
|
||||
For example, you can create a file and then upload it as an artifact.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
name: Save output
|
||||
steps:
|
||||
- shell: bash
|
||||
run: |
|
||||
expr 1 + 1 > output.log
|
||||
- name: Upload output file
|
||||
uses: actions/upload-artifact@v1
|
||||
with:
|
||||
name: output-log-file
|
||||
path: output.log
|
||||
```
|
||||
|
||||
To download an artifact from a separate workflow run, you can use the `actions/download-artifact` action. For example, you can download the artifact named `output-log-file`.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- name: Download a single artifact
|
||||
uses: actions/download-artifact@v2
|
||||
with:
|
||||
name: output-log-file
|
||||
```
|
||||
|
||||
For more information about artifacts, see "[Persisting workflow data using artifacts](/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts)."
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Managing complex workflows](/actions/learn-github-actions/managing-complex-workflows)."
|
||||
@@ -0,0 +1,156 @@
|
||||
---
|
||||
title: Finding and customizing actions
|
||||
shortTitle: Finding and customizing actions
|
||||
intro: 'Actions are the building blocks that power your workflow. A workflow can contain actions created by the community, or you can create your own actions directly within your application''s repository. This guide will show you how to discover, use, and customize actions.'
|
||||
redirect_from:
|
||||
- /actions/automating-your-workflow-with-github-actions/using-github-marketplace-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/using-actions-from-github-marketplace-in-your-workflow
|
||||
- /actions/getting-started-with-github-actions/using-actions-from-github-marketplace
|
||||
- /actions/getting-started-with-github-actions/using-community-workflows-and-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
The actions you use in your workflow can be defined in:
|
||||
|
||||
- Ein öffentliches Repository
|
||||
- The same repository where your workflow file references the action
|
||||
- Ein veröffentlichtes Docker-Containerimage auf Docker Hub
|
||||
|
||||
{% data variables.product.prodname_marketplace %} ist eine zentrale Stelle, an der Du Aktionen findest, die von der {% data variables.product.prodname_dotcom %}-Community erstellt wurden. [{% data variables.product.prodname_marketplace %} page](https://github.com/marketplace/actions/) enables you to filter for actions by category.
|
||||
|
||||
{% data reusables.actions.enterprise-marketplace-actions %}
|
||||
|
||||
### Browsing Marketplace actions in the workflow editor
|
||||
|
||||
Direkt im Workflow-Editor Deines Repositorys kannst Du Aktionen suchen und durchstöbern und auch suchen. In der Seitenleiste kannst Du nach einer bestimmten Aktion suchen, vorgestellte Aktionen anzeigen und vorgestellte Kategorien durchsuchen. Du kannst auch nach der Anzahl der Sterne schauen, die eine Aktion von der {% data variables.product.prodname_dotcom %}-Community erhalten hat.
|
||||
|
||||
1. Navigiere in Deinem Repository zu der Workflow-Datei, die Du bearbeiten möchtest.
|
||||
1. Um den Workflow-Editor zu öffnen, klickst Du in der oberen rechten Ecke der Dateiansicht auf {% octicon "pencil" aria-label="The edit icon" %}. 
|
||||
1. Rechts vom Editor befindet sich die Sidebar {% data variables.product.prodname_marketplace %} , um Aktionen zu durchsuchen. Actions with the {% octicon "verified" aria-label="The verified badge" %} badge indicate {% data variables.product.prodname_dotcom %} has verified the creator of the action as a partner organization. 
|
||||
|
||||
### Adding an action to your workflow
|
||||
|
||||
Die Listing-Seite einer Aktion enthält die Version der Aktion und die erforderliche Workflow-Syntax, um die Aktion zu benutzen. To keep your workflow stable even when updates are made to an action, you can reference the version of the action to use by specifying the Git or Docker tag number in your workflow file.
|
||||
|
||||
1. Navigiere zu der Aktion, die Du in Deinem Workflow verwenden möchtest.
|
||||
1. Klicke unter „Installation“ auf {% octicon "clippy" aria-label="The edit icon" %} , um die Workflow-Syntax zu kopieren. 
|
||||
1. Füge die Syntax als neuen Schritt in Deinen Workflow ein. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)“.
|
||||
1. If the action requires you to provide inputs, set them in your workflow. For information on inputs an action might require, see "[Using inputs and outputs with an action](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
{% data reusables.dependabot.version-updates-for-actions %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Using release management for your custom actions
|
||||
|
||||
The creators of a community action have the option to use tags, branches, or SHA values to manage releases of the action. Similar to any dependency, you should indicate the version of the action you'd like to use based on your comfort with automatically accepting updates to the action.
|
||||
|
||||
You will designate the version of the action in your workflow file. Check the action's documentation for information on their approach to release management, and to see which tag, branch, or SHA value to use.
|
||||
|
||||
#### Using tags
|
||||
|
||||
Tags are useful for letting you decide when to switch between major and minor versions, but these are more ephemeral and can be moved or deleted by the maintainer. This example demonstrates how to target an action that's been tagged as `v1.0.1`:
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
- verwendet: actions/javascript-action@v1.0.1
|
||||
```
|
||||
|
||||
#### Using SHAs
|
||||
|
||||
If you need more reliable versioning, you should use the SHA value associated with the version of the action. SHAs are immutable and therefore more reliable than tags or branches. However this approach means you will not automatically receive updates for an action, including important bug fixes and security updates. This example targets an action's SHA:
|
||||
|
||||
```yaml
|
||||
Schritte:
|
||||
- verwendet: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89
|
||||
```
|
||||
|
||||
#### Using branches
|
||||
|
||||
Referring to a specific branch means that the action will always use include the latest updates on the target branch, but can create problems if those updates include breaking changes. This example targets a branch named `@main`:
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/javascript-action@main
|
||||
```
|
||||
|
||||
For more information, see "[Using release management for actions](/actions/creating-actions/about-actions#using-release-management-for-actions)."
|
||||
|
||||
### Using inputs and outputs with an action
|
||||
|
||||
An action often accepts or requires inputs and generates outputs that you can use. For example, an action might require you to specify a path to a file, the name of a label, or other data it will uses as part of the action processing.
|
||||
|
||||
To see the inputs and outputs of an action, check the `action.yml` or `action.yaml` in the root directory of the repository.
|
||||
|
||||
In this example `action.yml`, the `inputs` keyword defines a required input called `file-path`, and includes a default value that will be used if none is specified. The `outputs` keyword defines an output called `results-file`, which tells you where to locate the results.
|
||||
|
||||
```yaml
|
||||
name: 'Example'
|
||||
description: 'Receives file and generates output'
|
||||
inputs:
|
||||
file-path: # id of input
|
||||
description: "Path to test script"
|
||||
required: true
|
||||
default: 'test-file.js'
|
||||
outputs:
|
||||
results-file: # id of output
|
||||
description: "Path to results file"
|
||||
```
|
||||
|
||||
### Verweisen auf eine Aktion im selben Repository, in dem eine Workflowdatei die Aktion verwendet
|
||||
|
||||
Wenn eine Aktion im selben Repository definiert ist, in dem Ihre Workflowdatei die Aktion verwendet, können Sie auf die Aktion mit der`{owner}/{repo}-{ref}` oder `./path/to/dir-` Syntax in ihrer Workflowdatei verweisen.
|
||||
|
||||
Beispiel-Repository-Dateistruktur:
|
||||
|
||||
```
|
||||
|-- hello-world (Repository)
|
||||
| |__ .github
|
||||
| Workflows
|
||||
| My-First-Workflow.yml
|
||||
| • Maßnahmen
|
||||
| |__ hello-world-action
|
||||
| • action.yml
|
||||
```
|
||||
|
||||
Beispiel-Workflowdatei:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
läuft auf: ubuntu-latest
|
||||
Schritte:
|
||||
- Dieser Schritt checkt eine Kopie Ihres Repositorys aus.
|
||||
- verwendet: actions/checkout@v2
|
||||
- Dieser Schritt verweist auf das Verzeichnis, das die Aktion enthält.
|
||||
- verwendet: ./.github/actions/hello-world-action
|
||||
```
|
||||
|
||||
The `action.yml` file is used to provide metadata for the action. Learn about the content of this file in "[Metadata syntax for GitHub Actions](/actions/creating-actions/metadata-syntax-for-github-actions)"
|
||||
|
||||
### Verweisen auf einen Container auf Docker Hub
|
||||
|
||||
Wenn eine Aktion in einem veröffentlichten Docker-Containerimage auf Docker Hub definiert ist, müssen Sie auf die Aktion mit der `docker://{image}:{tag}` Syntax in Ihrer Workflowdatei verweisen. Zum Schutz Ihres Codes und Ihrer Daten wird dringend empfohlen, die Integrität des Docker-Containerimages von Docker Hub zu überprüfen, bevor Sie es in Ihrem Workflow verwenden.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
my_first_job:
|
||||
Schritte:
|
||||
- Name: Mein erster Schritt
|
||||
verwendet: docker://alpine:3.8
|
||||
```
|
||||
|
||||
Einige Beispiele für Docker-Aktionen findest Du im [Docker-image.yml-Workflow](https://github.com/actions/starter-workflows/blob/main/ci/docker-image.yml) oder unter „[Eine Docker-Container-Aktion erstellen](/articles/creating-a-docker-container-action)“.
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Essential features of {% data variables.product.prodname_actions %}](/actions/learn-github-actions/essential-features-of-github-actions)."
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Learn GitHub Actions
|
||||
shortTitle: Learn GitHub Actions
|
||||
intro: 'Whether you are new to {% data variables.product.prodname_actions %} or interested in learning all they have to offer, this guide will help you use {% data variables.product.prodname_actions %} to accelerate your application development workflows.'
|
||||
redirect_from:
|
||||
- /articles/about-github-actions
|
||||
- /github/automating-your-workflow-with-github-actions/about-github-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/about-github-actions
|
||||
- /actions/getting-started-with-github-actions
|
||||
- /actions/getting-started-with-github-actions/about-github-actions
|
||||
- /actions/getting-started-with-github-actions/overview
|
||||
- /actions/getting-started-with-github-actions/getting-started-with-github-actions
|
||||
- /articles/migrating-github-actions-from-hcl-syntax-to-yaml-syntax/
|
||||
- /actions/configuring-and-managing-workflows/configuring-a-workflow
|
||||
- /articles/creating-a-workflow-with-github-actions/
|
||||
- /articles/configuring-a-workflow
|
||||
- /github/automatisieren-ihren-workflow-mit-github-aktionen/configuring-a-workflow
|
||||
- /actions/automating-your-workflow-with-github-actions/configuring-a-workflow
|
||||
- /actions/creating-workflows/workflow-configuration-options
|
||||
- /articles/configuring-workflows
|
||||
- /github/automating-your-workflow-with-github-actions/configuring-workflows
|
||||
- /actions/automating-your-workflow-with-github-actions/configuring-workflows
|
||||
- /github/automating-your-workflow-with-github-actions/getting-started-with-github-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/getting-started-with-github-actions
|
||||
- /actions/configuring-and-managing-workflows
|
||||
- /articles/getting-started-with-github-actions
|
||||
- /actions/migrating-to-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% link_with_intro /introduction-to-github-actions %}
|
||||
{% link_with_intro /finding-and-customizing-actions %}
|
||||
{% link_with_intro /essential-features-of-github-actions %}
|
||||
{% link_with_intro /managing-complex-workflows %}
|
||||
{% link_with_intro /sharing-workflows-with-your-organization %}
|
||||
{% link_with_intro /security-hardening-for-github-actions %}
|
||||
{% link_with_intro /migrating-from-circleci-to-github-actions %}
|
||||
{% link_with_intro /migrating-from-gitlab-cicd-to-github-actions %}
|
||||
{% link_with_intro /migrating-from-azure-pipelines-to-github-actions %}
|
||||
{% link_with_intro /migrating-from-jenkins-to-github-actions %}
|
||||
@@ -0,0 +1,225 @@
|
||||
---
|
||||
title: Introduction to GitHub Actions
|
||||
shortTitle: Introduction to GitHub Actions
|
||||
intro: 'Learn about the core concepts and various components of {% data variables.product.prodname_actions %}, and see an example that shows you how to add automation to your repository.'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/core-concepts-for-github-actions
|
||||
- /actions/automating-your-workflow-with-github-actions/core-concepts-for-github-actions
|
||||
- /actions/getting-started-with-github-actions/core-concepts-for-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
{% data variables.product.prodname_actions %} help you automate tasks within your software development life cycle. {% data variables.product.prodname_actions %} are event-driven, meaning that you can run a series of commands after a specified event has occurred. For example, every time someone creates a pull request for a repository, you can automatically run a command that executes a software testing script.
|
||||
|
||||
This diagram demonstrates how you can use {% data variables.product.prodname_actions %} to automatically run your software testing scripts. An event automatically triggers the _workflow_, which contains a _job_. The job then uses _steps_ to control the order in which _actions_ are run. These actions are the commands that automate your software testing.
|
||||
|
||||
|
||||
|
||||
### The components of {% data variables.product.prodname_actions %}
|
||||
|
||||
Below is a list of the multiple {% data variables.product.prodname_actions %} components that work together to run jobs. You can see how these components interact with each other.
|
||||
|
||||
|
||||
|
||||
#### Workflows
|
||||
|
||||
The workflow is an automated procedure that you add to your repository. Workflows are made up of one or more jobs and can be scheduled or triggered by an event. The workflow can be used to build, test, package, release, or deploy a project on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
#### Ereignisse
|
||||
|
||||
An event is a specific activity that triggers a workflow. Die Aktivität kann beispielsweise von {% data variables.product.prodname_dotcom %} stammen, wenn ein Commit an Repository gepusht oder wenn ein Issue oder ein Pull Request erstellt wird. You can also use the repository dispatch webhook to trigger a workflow when an external event occurs. For a complete list of events that can be used to trigger workflows, see [Events that trigger workflows](/actions/reference/events-that-trigger-workflows).
|
||||
|
||||
#### Jobs
|
||||
|
||||
A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel. You can also configure a workflow to run jobs sequentially. Ein Workflow kann beispielsweise zwei sequentielle Aufträge umfassen, in denen der Code erstellt und getestet wird, wobei der Testauftrag vom Status des Build-Auftrags abhängig ist. Wenn der Build-Auftrag fehlschlägt, wird der Testauftrag nicht ausgeführt.
|
||||
|
||||
#### Steps
|
||||
|
||||
A step is an individual task that can run commands (known as _actions_). Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
|
||||
|
||||
#### Actions
|
||||
|
||||
_Actions_ are standalone commands that are combined into _steps_ to create a _job_. Aktionen sind der kleinste portable Baustein eines Workflows. You can create your own actions, or use actions created by the {% data variables.product.prodname_dotcom %} community. Soll eine Aktion in einem Workflow verwendet werden, müssen Sie sie als Schritt einfügen.
|
||||
|
||||
#### Runners
|
||||
|
||||
A runner is a server that has the {% data variables.product.prodname_actions %} runner application installed. You can use a runner hosted by {% data variables.product.prodname_dotcom %}, or you can host your own. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to {% data variables.product.prodname_dotcom %}. For {% data variables.product.prodname_dotcom %}-hosted runners, each job in a workflow runs in a fresh virtual environment.
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners are based on Ubuntu Linux, Microsoft Windows, and macOS. For information on {% data variables.product.prodname_dotcom %}-hosted runners, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/virtual-environments-for-github-hosted-runners)." If you need a different operating system or require a specific hardware configuration, you can host your own runners. For information on self-hosted runners, see "[Hosting your own runners](/actions/hosting-your-own-runners)."
|
||||
|
||||
### Create an example workflow
|
||||
|
||||
{% data variables.product.prodname_actions %} uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called `.github/workflows`.
|
||||
|
||||
You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, {% data variables.product.prodname_actions %} checks out the pushed code, installs the software dependencies, and runs `bats -v`.
|
||||
|
||||
1. In your repository, create the `.github/workflows/` directory to store your workflow files.
|
||||
1. In the `.github/workflows/` directory, create a new file called `learn-github-actions.yml` and add the following code.
|
||||
```yaml
|
||||
name: learn-github-actions
|
||||
on: [push]
|
||||
jobs:
|
||||
check-bats-version:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-node@v1
|
||||
- run: npm install -g bats
|
||||
- run: bats -v
|
||||
```
|
||||
1. Commit these changes and push them to your {% data variables.product.prodname_dotcom %} repository.
|
||||
|
||||
Your new {% data variables.product.prodname_actions %} workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. For details about a job's execution history, see "[Viewing the workflow's activity](/actions/learn-github-actions/introduction-to-github-actions#viewing-the-jobs-activity)."
|
||||
|
||||
### Understanding the workflow file
|
||||
|
||||
To help you understand how YAML syntax is used to create a workflow file, this section explains each line of the introduction's example:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
name: learn-github-actions
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
<em>Optional</em> - The name of the workflow as it will appear in the Actions tab of the {% data variables.product.prodname_dotcom %} repository.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
on: [push]
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Specify the event that automatically triggers the workflow file. This example uses the <code>push</code> event, so that the jobs run every time someone pushes a change to the repository. You can set up the workflow to only run on certain branches, paths, or tags. For syntax examples including or excluding branches, paths, or tags, see <a href="https://docs.github.com/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths">"Workflow syntax for {% data variables.product.prodname_actions %}."</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Groups together all the jobs that run in the <code>learn-github-actions</code> workflow file.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
check-bats-version:
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Defines the name of the <code>check-bats-version</code> job stored within the <code>jobs</code> section.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
runs-on: ubuntu-latest
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Configures the job to run on an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see <a href="https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on">"Workflow syntax for {% data variables.product.prodname_actions %}."</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Groups together all the steps that run in the <code>check-bats-version</code> job. Each line nested under this section is a separate action.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
- uses: actions/checkout@v2
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
The <code>uses</code> keyword tells the job to retrieve <code>v2</code> of the community action named <code>actions/checkout@v2</code>. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will run against the repository's code or you are using an action defined in the repository.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
- uses: actions/setup-node@v1
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
This action installs the <code>node</code> software package on the runner, giving you access to the <code>npm</code> command.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
- run: npm install -g bats
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
The <code>run</code> keyword tells the job to execute a command on the runner. In this case, you are using <code>npm</code> to install the <code>bats</code> software testing package.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
- run: bats -v
|
||||
```
|
||||
</td>
|
||||
<td>
|
||||
Finally, you'll run the <code>bats</code> command with a parameter that outputs the software version.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### Visualizing the workflow file
|
||||
|
||||
In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action. Steps 1 and 2 use prebuilt community actions. To find more prebuilt actions for your workflows, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."
|
||||
|
||||
|
||||
|
||||
|
||||
### Viewing the job's activity
|
||||
|
||||
Once your job has started running, you can view each step's activity on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
1. Klicke unter Deinem Repository-Namen auf **Actions** (Aktionen). 
|
||||
1. In the left sidebar, click the workflow you want to see. 
|
||||
1. Under "Workflow runs", click the name of the run you want to see. 
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
1. Click on the job name to see the results of each step. 
|
||||
{% else %}
|
||||
1. Click on the job name to see the results of each step. 
|
||||
{% endif %}
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."
|
||||
|
||||
### Support kontaktieren
|
||||
|
||||
{% data reusables.github-actions.contacting-support %}
|
||||
@@ -0,0 +1,151 @@
|
||||
---
|
||||
title: Managing complex workflows
|
||||
shortTitle: Managing complex workflows
|
||||
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices, and labels.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
This article describes some of the advanced features of {% data variables.product.prodname_actions %} that help you work create more complex workflows.
|
||||
|
||||
### Storing secrets
|
||||
|
||||
If your workflows use sensitive data, such as passwords or certificates, you can save these in {% data variables.product.prodname_dotcom %} as _secrets_ and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the YAML workflow.
|
||||
|
||||
This example action demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- name: Retrieve secret
|
||||
env:
|
||||
super_secret: ${{ secrets.SUPERSECRET }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und speichern](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)“.
|
||||
|
||||
### Creating dependent jobs
|
||||
|
||||
By default, the jobs in your workflow all run in parallel at the same time. So if you have a job that must only run after another job has completed, you can use the `needs` keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the [`if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) conditional statement.
|
||||
|
||||
In this example, the `setup`, `build`, and `test` jobs run in series, with `build` and `test` being dependent on the successful completion of the job that precedes them:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
setup:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: ./setup_server.sh
|
||||
build:
|
||||
needs: setup
|
||||
steps:
|
||||
- run: ./build_server.sh
|
||||
test:
|
||||
needs: build
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: ./test_server.sh
|
||||
```
|
||||
|
||||
For more information, see [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds).
|
||||
|
||||
### Using a build matrix
|
||||
|
||||
You can use a build matrix if you want your workflow to run tests across multiple combinations of operating systems, platforms, and languages. The build matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this build matrix will run the job multiple times, using different versions of Node.js:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node: [6, 8, 10]
|
||||
steps:
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: ${{ matrix.node }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For more information, see [`jobs.<job_id>.strategy.matrix`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
|
||||
|
||||
### Abhängigkeiten „cachen“ (zwischenspeichern)
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners are started as fresh environments for each job, so if your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
|
||||
|
||||
This example demonstrates how to cache the `~/.npm` directory:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
steps:
|
||||
- name: Cache node modules
|
||||
uses: actions/cache@v2
|
||||
env:
|
||||
cache-name: cache-node-modules
|
||||
with:
|
||||
path: ~/.npm
|
||||
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-build-${{ env.cache-name }}-
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Weitere Informationen findest Du unter „[Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern](/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows)“.
|
||||
|
||||
### Datenbanken und Service-Container verwenden
|
||||
|
||||
If your job requires a database or cache service, you can use the [`services`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices) keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use `services` to create a `postgres` container, and then use `node` to connect to the service.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
container-job:
|
||||
runs-on: ubuntu-latest
|
||||
container: node:10.18-jessie
|
||||
services:
|
||||
postgres:
|
||||
image: postgres
|
||||
steps:
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
- name: Connect to PostgreSQL
|
||||
run: node client.js
|
||||
env:
|
||||
POSTGRES_HOST: postgres
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
|
||||
For more information, see "[Using databases and service containers](/actions/configuring-and-managing-workflows/using-databases-and-service-containers)."
|
||||
|
||||
### Using labels to route workflows
|
||||
|
||||
This feature helps you assign jobs to a specific self-hosted runner. If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner, and then refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way.
|
||||
|
||||
This example shows how a workflow can use labels to specify the required runner:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
example-job:
|
||||
runs-on: [self-hosted, linux, x64, gpu]
|
||||
```
|
||||
|
||||
For more information, see ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows with your organization](/actions/learn-github-actions/sharing-workflows-with-your-organization)."
|
||||
@@ -0,0 +1,327 @@
|
||||
---
|
||||
title: Von Azure-Pipelines zu GitHub-Aktionen migrieren
|
||||
intro: '{% data variables.product.prodname_actions %} und Azure-Pipelines haben mehrere Ähnlichkeiten in der Konfiguration, was die Migration zu {% data variables.product.prodname_actions %} relativ einfach macht.'
|
||||
redirect_from:
|
||||
- /actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Azure-Pipelines und {% data variables.product.prodname_actions %} ermöglichen es Dir, Workflows zu erstellen, die automatisch Code bauen, testen, publizieren, freigeben und bereitstellen. Azure-Pipelines und {% data variables.product.prodname_actions %} haben einige Ähnlichkeiten in der Workflow-Konfiguration:
|
||||
|
||||
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.
|
||||
- Workflows umfassen einen oder mehrere Jobs.
|
||||
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
|
||||
- Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.
|
||||
|
||||
Weitere Informationen findest Du unter „[Kernkonzepte für {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/core-concepts-for-github-actions)“.
|
||||
|
||||
### Wesentliche Unterschiede
|
||||
|
||||
Bei der Migration von Azure-Pipelines sollten die folgenden Unterschiede beachtet werden:
|
||||
|
||||
- Azure Pipelines unterstützt einen veralteten _klassischen Editor_, mit dem Du Deine CI-Konfiguration in einem GUI-Editor definieren kannst, anstatt die Pipeline-Definition in einer YAML-Datei zu erstellen. {% data variables.product.prodname_actions %} verwendet YAML-Dateien, um Workflows zu definieren, und unterstützt keinen grafischen Editor.
|
||||
- Azure Pipelines erlaubt Dir, einige Strukturen in Job-Definitionen zu weglassen. Wenn Du zum Beispiel nur einen einzigen Job hast, brauchst Du den Job an sich nicht zu definieren, sondern nur seine Schritte. {% data variables.product.prodname_actions %} erfordert eine explizite Konfiguration und die YAML-Struktur kann nicht weggelassen werden.
|
||||
- Azure Pipelines unterstützt _„stages“ (Phasen)_ die in der YAML-Datei definiert sind, welche verwendet werden kann, um Workflows für die Bereitstellung zu erstellen. {% data variables.product.prodname_actions %} erfordert, die Phasen in separate YAML-Workflowdateien zu aufzuteilen.
|
||||
- Bei Azure-Pipelines können lokale Build-Agenten nach Funktionalität ausgewählt werden. Bei {% data variables.product.prodname_actions %} können selbst-gehostete Runner nach Labels ausgewählt werden.
|
||||
|
||||
### Jobs und Schritte migrieren
|
||||
|
||||
Jobs und Schritte in Azure-Pipelines sind sehr ähnlich zu Jobs und Schritten in {% data variables.product.prodname_actions %}. In beiden Systemen haben Jobs folgende Merkmale:
|
||||
|
||||
* Jobs enthalten eine Reihe von Schritten, die nacheinander ausgeführt werden.
|
||||
* Jobs laufen auf separaten virtuellen Maschinen oder in separaten Containern.
|
||||
* Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.
|
||||
|
||||
### Skriptschritte migrieren
|
||||
|
||||
Du kannst in einem Workflow ein Skript oder einen Shell-Befehl als Schritt ausführen. In Azure-Pipelines können Skriptschritte mit dem Schlüssel `script`, `bash`, `powershell` oder `pwsh` festgelegt werden. Skripte können auch als Eingabe für den [Bash-Task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/bash?view=azure-devops) oder den [PowerShell-Task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/powershell?view=azure-devops) angegeben werden.
|
||||
|
||||
In {% data variables.product.prodname_actions %} sind alle Skripte mit dem Schlüssel `run` spezifiziert. Um eine bestimmte Shell auszuwählen, kannst Du den Schlüssel `shell` angeben, wenn Du das Skript zur Verfügung stellst. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)“.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
Azure-Pipelines
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
- job: scripts
|
||||
pool:
|
||||
vmImage: 'windows-latest'
|
||||
steps:
|
||||
- script: echo "This step runs in the default shell"
|
||||
- bash: echo "This step runs in bash"
|
||||
- pwsh: Write-Host "This step runs in PowerShell Core"
|
||||
- task: PowerShell@2
|
||||
inputs:
|
||||
script: Write-Host "This step runs in PowerShell"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
scripts:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- run: echo "This step runs in the default shell"
|
||||
- run: echo "This step runs in bash"
|
||||
shell: bash
|
||||
- run: Write-Host "This step runs in PowerShell Core"
|
||||
shell: pwsh
|
||||
- run: Write-Host "This step runs in PowerShell"
|
||||
shell: powershell
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Unterschiede in der Behandlung von Skriptfehlern
|
||||
|
||||
In Azure-Pipelines können Skripte dazu konfiguriert werden, fehlzuschlagen, wenn irgendeine Ausgabe an `stderr` gesendet wird. {% data variables.product.prodname_actions %} unterstützt diese Konfiguration nicht.
|
||||
|
||||
{% data variables.product.prodname_actions %} konfiguriert Shells zum "schnellen Scheitern" wann immer möglich , was das Skript sofort beendet, wenn einer der Befehle in einem Skript mit einem Fehlercode endet. Im Gegensatz dazu erfordern Azure-Pipelines explizite Konfiguration, um bei einem Fehler sofort abzubrechen. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference)“.
|
||||
|
||||
### Unterschiede in der Standard-Shell unter Windows
|
||||
|
||||
In Azure-Pipelines ist die Standard-Shell für Skripte auf Windows-Plattformen die Command-Shell (_cmd.exe_). In {% data variables.product.prodname_actions %} ist die Standard-Shell für Skripte auf Windows-Plattformen die PowerShell. PowerShell hat mehrere Unterschiede in internen Befehlen, Auswertung von Variablen und Flusssteuerung.
|
||||
|
||||
Wenn Du einen einfachen Befehl ausführst, kannst Du in PowerShell möglicherweise ein Skript der Command Shell ohne Änderungen laufen lassen. Aber in den meisten Fällen musst Du entweder Dein Skript zur Syntax der PowerShell aktualisieren oder {% data variables.product.prodname_actions %} anweisen, das Skript mit der Command Shell statt mit PowerShell auszuführen. Dies kannst Du tun, indem Du unter `shell` den Wert `cmd` angibst.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
Azure-Pipelines
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
- job: run_command
|
||||
pool:
|
||||
vmImage: 'windows-latest'
|
||||
steps:
|
||||
- script: echo "This step runs in CMD on Windows by default"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
run_command:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- run: echo "This step runs in PowerShell on Windows by default"
|
||||
- run: echo "This step runs in CMD on Windows explicitly"
|
||||
shell: cmd
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell)“.
|
||||
|
||||
### Syntax für Bedingungen und Ausdrücke migrieren
|
||||
|
||||
Sowohl Azure-Pipelines als auch {% data variables.product.prodname_actions %} können Schritte bedingt ausführen. In Azure-Pipelines werden bedingte Ausdrücke mit dem Schlüssel `condition` angegeben. In {% data variables.product.prodname_actions %} werden bedingte Ausdrücke mit dem Schlüssel `if` angegeben.
|
||||
|
||||
Azure-Pipelines verwenden Funktionen innerhalb von Ausdrücken, um Schritte bedingt auszuführen. Im Gegensatz dazu verwenden {% data variables.product.prodname_actions %} eine Infix-Notation. Zum Beispiel musst Du die Funktion `eq` in Azure-Pipelines durch den Operator `==` in {% data variables.product.prodname_actions %} ersetzen.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
Azure-Pipelines
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
- job: conditional
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
steps:
|
||||
- script: echo "This step runs with str equals 'ABC' and num equals 123"
|
||||
condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
conditional:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "This step runs with str equals 'ABC' and num equals 123"
|
||||
if: ${{ env.str == 'ABC' && env.num == 123 }}
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
### Abhängigkeiten zwischen Jobs
|
||||
|
||||
Sowohl bei Azure-Pipelines als auch bei {% data variables.product.prodname_actions %} kannst Du Abhängigkeiten für einen Job festlegen. In beiden Systemen laufen Jobs standardmäßig parallel, aber Jobabhängigkeiten können explizit angegeben werden. In Azure-Pipelines erfolgt dies mit dem Schlüssel `dependsOn`. In {% data variables.product.prodname_actions %}wird dies mit dem Schlüssel `needs` getan.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System. Die Workflows starten einen ersten Job namens `initial` und wenn dieser Job beendet ist, laufen zwei Jobs namens `fanout1` und `fanout2`. Schließlich, wenn diese Jobs abgeschlossen sind, läuft der Job `fanin`.
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
Azure-Pipelines
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
- job: initial
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
steps:
|
||||
- script: echo "This job will be run first."
|
||||
job: fanout1
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
dependsOn: initial
|
||||
steps:
|
||||
- script: echo "This job will run after the initial job, in parallel with fanout2."
|
||||
job: fanout2
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
dependsOn: initial
|
||||
steps:
|
||||
- script: echo "This job will run after the initial job, in parallel with fanout1."
|
||||
job: fanin:
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
dependsOn: [fanout1, fanout2]
|
||||
steps:
|
||||
- script: echo "This job will run after fanout1 and fanout2 have finished."
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
initial:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "This job will be run first."
|
||||
fanout1:
|
||||
runs-on: ubuntu-latest
|
||||
needs: initial
|
||||
steps:
|
||||
- run: echo "This job will run after the initial job, in parallel with fanout2."
|
||||
fanout2:
|
||||
runs-on: ubuntu-latest
|
||||
needs: initial
|
||||
steps:
|
||||
- run: echo "This job will run after the initial job, in parallel with fanout1."
|
||||
fanin:
|
||||
runs-on: ubuntu-latest
|
||||
needs: [fanout1, fanout2]
|
||||
steps:
|
||||
- run: echo "This job will run after fanout1 and fanout2 have finished."
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)“.
|
||||
|
||||
### „Tasks“ (Aufgaben) zu Aktionen migrieren
|
||||
|
||||
Azure-Pipelines verwenden _tasks_. Das sind Anwendungskomponenten, die in mehreren Workflows wiederverwendet werden können. {% data variables.product.prodname_actions %} verwenden _Aktionen_, Diese können verwendet werden, um Aufgaben auszuführen und Ihren Workflow anzupassen. In beiden Systemen kannst Du den Namen der zu ausführenden Aufgabe oder Aktion sowie alle erforderlichen Eingaben als Schlüssel/Wert-Paare angeben.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Azure-Pipelines
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
- job: run_python
|
||||
pool:
|
||||
vmImage: 'ubuntu-latest'
|
||||
steps:
|
||||
- task: UsePythonVersion@0
|
||||
inputs:
|
||||
versionSpec: '3.7'
|
||||
architecture: 'x64'
|
||||
- script: python script.py
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
run_python:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.7'
|
||||
architecture: 'x64'
|
||||
- run: python script.py
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Aktionen zur Verwendung in Deinem Workflow findest du entweder auf dem [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) oder Du kannst eigene Aktionen erstellen. For more information, see "[Creating actions](/actions/creating-actions)."
|
||||
|
||||
@@ -0,0 +1,447 @@
|
||||
---
|
||||
title: Von CircleCI zu GitHub-Aktionen migrieren
|
||||
intro: 'GitHub-Aktionen und CircleCI haben mehrere Ähnlichkeiten in der Konfiguration, was die Migration zu GitHub-Aktionen relativ einfach macht.'
|
||||
redirect_from:
|
||||
- /actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
CircleCI und {% data variables.product.prodname_actions %} ermöglichen es Dir, Workflows zu erstellen, die Code automatisch bauen, testen, veröffentlichen, freigeben und bereitstellen. CircleCI und {% data variables.product.prodname_actions %} haben einige Ähnlichkeiten in der Workflow-Konfiguration:
|
||||
|
||||
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Repository gespeichert.
|
||||
- Workflows umfassen einen oder mehrere Jobs.
|
||||
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
|
||||
- Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.
|
||||
|
||||
Weitere Informationen findest Du unter „[Kernkonzepte für {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/core-concepts-for-github-actions)“.
|
||||
|
||||
### Wesentliche Unterschiede
|
||||
|
||||
Betrachte bei der Migration von CircleCI folgende Unterschiede:
|
||||
|
||||
- Die automatische Testparallelität des CircleCI gruppiert die Tests automatisch nach benutzerdefinierten Regeln oder historischen Zeitinformationen. Diese Funktionalität ist in {% data variables.product.prodname_actions %} nicht eingebaut.
|
||||
- Aktionen, die in Docker-Containern ausgeführt werden, sind sensibel für Berechtigungsprobleme, da Container eine andere Zuordnung von Benutzern haben. Du kannst viele dieser Probleme vermeiden, indem Du die Anweisung `USER` in Deinem *Dockerfile* nicht verwendest. Weitere Informationen über das Docker-Dateisystem findest Du unter „[Virtuelle Umgebungen für {% data variables.product.product_name %}-gehostete Runner](/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem)“.
|
||||
|
||||
### Workflows und Jobs migrieren
|
||||
|
||||
CircleCI definiert `Workflows` in der Datei *config.yml*, wodurch Du mehrere Workflows konfigurieren kannst. {% data variables.product.product_name %} benötigt pro Workflow eine Workflow-Datei und erfordert daher nicht `Workflows` zu deklarieren. Du musst für jeden Workflow, der in *config.yml* konfiguriert ist, eine neue Workflow-Datei erstellen.
|
||||
|
||||
Sowohl CircleCI als auch {% data variables.product.prodname_actions %} konfigurieren `Jobs` in der Konfigurationsdatei, und das mit ähnlicher Syntax. Wenn Du Abhängigkeiten zwischen Jobs in Deinem CircleCI-Workflow mit `requires` konfigurierst, kannst Du in {% data variables.product.prodname_actions %} die äquivalente Syntax `needs` verwenden. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)“.
|
||||
|
||||
### „Orbs“ (Gestirne) zu Aktionen migrieren
|
||||
|
||||
Sowohl CircleCI als auch {% data variables.product.prodname_actions %} bieten einen Mechanismus, um Aufgaben in einem Workflow wiederzuverwenden und weiterzugeben. CircleCI verwendet ein Konzept namens „Orbs“ (Gestirne), das in YAML geschrieben ist, um Aufgaben bereitzustellen, die man in einem Workflow wiederverwenden kann. {% data variables.product.prodname_actions %} hat mächtige und flexible wiederverwendbare Komponenten namens Aktionen, die man entweder mit JavaScript-Dateien oder mit Docker-Images erstellt. Um Aktionen zu erstellen, kannst Du eigenen Code schreiben, der mit Deinem Repository auf die gewünschte Weise interagiert und dabei beispielsweise in die APIs von {% data variables.product.product_name %} und beliebige öffentlich zugänglichen Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen. For more information, see "[Creating actions](/actions/creating-actions)."
|
||||
|
||||
CircleCI kann Workflows mit YAML-Ankern und Aliasen wiederverwenden. {% data variables.product.prodname_actions %} unterstützen den üblichen Bedarf an Wiederverwendbarkeit durch Build-Matrizen. For more information about build matrixes, see "[Managing complex workflows](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix)."
|
||||
|
||||
### Docker-Images verwenden
|
||||
|
||||
|
||||
Sowohl CircleCI als auch {% data variables.product.prodname_actions %} können Schritte innerhalb eines Docker-Images ausführen.
|
||||
|
||||
CircleCI stellt eine Reihe von vordefinierten Images mit üblichen Abhängigkeiten zur Verfügung. Diese Images haben `circleci` als `USER` gesetzt, was zu Konflikten mit {% data variables.product.prodname_actions %} führt.
|
||||
|
||||
Wir empfehlen Dir, von vordefinierten CircleCI-Images zu wegzugehen, wenn Du zu {% data variables.product.prodname_actions %} migrierst. In vielen Fällen kannst Du die zusätzlich benötigten Abhängigkeiten mithilfe von Aktionen installieren.
|
||||
|
||||
Weitere Informationen über das Docker-Dateisystem findest Du unter „[Virtuelle Umgebungen für {% data variables.product.product_name %}-gehostete Runner](/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem)“.
|
||||
|
||||
For more information about the tools and packages available on {% data variables.product.prodname_dotcom %}-hosted virtual environments, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
|
||||
|
||||
### Variablen und Geheimnisse verwenden
|
||||
|
||||
CircleCI und {% data variables.product.prodname_actions %} unterstützen das Setzen von Umgebungsvariablen in der Konfigurationsdatei und das Erstellen von Geheimnissen mit der Benutzeroberfläche von entweder CircleCI oder {% data variables.product.product_name %}.
|
||||
|
||||
Weitere Informationen findest Du unter „[Umgebungsvariablen verwenden](/actions/configuring-and-managing-workflows/using-environment-variables)“ und „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)“.
|
||||
|
||||
### Im Cache zwischenspeichern
|
||||
|
||||
CircleCI und {% data variables.product.prodname_actions %} bieten in der Konfigurationsdatei eine Methode an, um Dateien manuell im Cache zwischenzuspeichern.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System.
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
CircleCI
|
||||
</th>
|
||||
<th>
|
||||
GitHub Actions
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
- restore_cache:
|
||||
keys:
|
||||
- v1-npm-deps-{{ checksum "package-lock.json" }}
|
||||
- v1-npm-deps-
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
- name: Cache node modules
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
path: ~/.npm
|
||||
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: v1-npm-deps-
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern](/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows)“.
|
||||
|
||||
{% data variables.product.prodname_actions %} hat kein Äquivalent zum „Docker Layer Caching“ („DLC“, im Cache auf Docker-Ebene zwischenspeichern).
|
||||
|
||||
### Daten zwischen Jobs persistieren
|
||||
|
||||
Sowohl CircleCI als auch {% data variables.product.prodname_actions %} bieten Mechanismen für die Persistierung von Daten zwischen Jobs.
|
||||
|
||||
Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und {% data variables.product.prodname_actions %}.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
CircleCI
|
||||
</th>
|
||||
<th>
|
||||
GitHub Actions
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
- persist_to_workspace:
|
||||
root: workspace
|
||||
paths:
|
||||
- math-homework.txt
|
||||
|
||||
...
|
||||
|
||||
- attach_workspace:
|
||||
at: /tmp/workspace
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
- name: Upload math result for job 1
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: homework
|
||||
path: math-homework.txt
|
||||
|
||||
...
|
||||
|
||||
- name: Download math result for job 1
|
||||
uses: actions/download-artifact@v2
|
||||
with:
|
||||
name: homework
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts)“.
|
||||
|
||||
### Datenbanken und Service-Container verwenden
|
||||
|
||||
Mit beiden Systemen kannst Du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.
|
||||
|
||||
In CircleCI ist das erste in der *config.yaml* aufgelistete Image, das primäre Image, welches benutzt wird, um Befehle auszuführen. {% data variables.product.prodname_actions %} verwendet explizite Abschnitte: `container` für den primären Container und zusätzliche Container aufgelistet in `services`.
|
||||
|
||||
Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und {% data variables.product.prodname_actions %}.
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
CircleCI
|
||||
</th>
|
||||
<th>
|
||||
GitHub Actions
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
---
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
|
||||
ruby-26:
|
||||
docker:
|
||||
- image: circleci/ruby:2.6.3-node-browsers-legacy
|
||||
environment:
|
||||
PGHOST: localhost
|
||||
PGUSER: administrate
|
||||
RAILS_ENV: test
|
||||
- image: postgres:10.1-alpine
|
||||
environment:
|
||||
POSTGRES_USER: administrate
|
||||
POSTGRES_DB: ruby26
|
||||
POSTGRES_PASSWORD: ""
|
||||
|
||||
working_directory: ~/administrate
|
||||
|
||||
steps:
|
||||
- checkout
|
||||
|
||||
# Abhaengigkeiten gebuendelt installieren
|
||||
- run: bundle install --path vendor/bundle
|
||||
|
||||
# auf DB warten
|
||||
- run: dockerize -wait tcp://localhost:5432 -timeout 1m
|
||||
|
||||
# Umgebung einrichten
|
||||
- run: cp .sample.env .env
|
||||
|
||||
# Datenbank einrichten
|
||||
- run: bundle exec rake db:setup
|
||||
|
||||
# Tests durchfuehren
|
||||
- run: bundle exec rake
|
||||
|
||||
|
||||
workflows:
|
||||
version: 2
|
||||
build:
|
||||
jobs:
|
||||
- ruby-26
|
||||
...
|
||||
|
||||
- attach_workspace:
|
||||
at: /tmp/workspace
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Containers
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
container: circleci/ruby:2.6.3-node-browsers-legacy
|
||||
|
||||
env:
|
||||
PGHOST: postgres
|
||||
PGUSER: administrate
|
||||
RAILS_ENV: test
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: postgres:10.1-alpine
|
||||
env:
|
||||
POSTGRES_USER: administrate
|
||||
POSTGRES_DB: ruby25
|
||||
POSTGRES_PASSWORD: ""
|
||||
ports:
|
||||
- 5432:5432
|
||||
# einen Gesundheitscheck zufuegen
|
||||
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
|
||||
|
||||
steps:
|
||||
# Diese Docker-Datei Setzt USER auf circleci statt dem Standardbenutzer, daher muessen wir die Datei-Berechtigungen fuer dieses Image aktualisieren, um auf GH-Aktionen arbeiten zu koennen.
|
||||
# See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
|
||||
- name: Setup file system permissions
|
||||
run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
|
||||
- uses: actions/checkout@v2
|
||||
- name: Install dependencies
|
||||
run: bundle install --path vendor/bundle
|
||||
- name: Setup environment configuration
|
||||
run: cp .sample.env .env
|
||||
- name: Setup database
|
||||
run: bundle exec rake db:setup
|
||||
- name: Run tests
|
||||
run: bundle exec rake
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Informationen zu Servicecontainern](/actions/configuring-and-managing-workflows/about-service-containers)“.
|
||||
|
||||
### Vollständiges Beispiel
|
||||
|
||||
Nachfolgend siehst Du ein Beispiel aus der realen Welt. Die linke Seite zeigt die tatsächliche *config.yml* unter CircleCI für das Repository [thoughtbot/administrator](https://github.com/thoughtbot/administrate). Die rechte Seite zeigt das Äquivalent unter {% data variables.product.prodname_actions %}.
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
CircleCI
|
||||
</th>
|
||||
<th>
|
||||
GitHub Actions
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
---
|
||||
version: 2.1
|
||||
|
||||
commands:
|
||||
shared_steps:
|
||||
steps:
|
||||
- checkout
|
||||
|
||||
# Abhaengigkeiten aus dem Cache wiederherstellen
|
||||
- restore_cache:
|
||||
name: Restore bundle cache
|
||||
key: administrate-{{ checksum "Gemfile.lock" }}
|
||||
|
||||
# Abhaengigkeiten gebuendelt installieren
|
||||
- run: bundle install --path vendor/bundle
|
||||
|
||||
# Abhaengigkeiten im Cache zwischenspeichern
|
||||
- save_cache:
|
||||
name: Store bundle cache
|
||||
key: administrate-{{ checksum "Gemfile.lock" }}
|
||||
paths:
|
||||
- vendor/bundle
|
||||
|
||||
# auf DB warten
|
||||
- run: dockerize -wait tcp://localhost:5432 -timeout 1m
|
||||
|
||||
# Umgebung einrichten
|
||||
- run: cp .sample.env .env
|
||||
|
||||
# Datenbank einrichten
|
||||
- run: bundle exec rake db:setup
|
||||
|
||||
# Tests durchfuehren
|
||||
- run: bundle exec rake
|
||||
|
||||
default_job: &default_job
|
||||
working_directory: ~/administrate
|
||||
steps:
|
||||
- shared_steps
|
||||
# Test mit verschiedenen Versionen von Rails durchfuehren
|
||||
- run: bundle exec appraisal install
|
||||
- run: bundle exec appraisal rake
|
||||
|
||||
jobs:
|
||||
ruby-25:
|
||||
<<: *default_job
|
||||
docker:
|
||||
- image: circleci/ruby:2.5.0-node-browsers
|
||||
environment:
|
||||
PGHOST: localhost
|
||||
PGUSER: administrate
|
||||
RAILS_ENV: test
|
||||
- image: postgres:10.1-alpine
|
||||
environment:
|
||||
POSTGRES_USER: administrate
|
||||
POSTGRES_DB: ruby25
|
||||
POSTGRES_PASSWORD: ""
|
||||
|
||||
ruby-26:
|
||||
<<: *default_job
|
||||
docker:
|
||||
- image: circleci/ruby:2.6.3-node-browsers-legacy
|
||||
environment:
|
||||
PGHOST: localhost
|
||||
PGUSER: administrate
|
||||
RAILS_ENV: test
|
||||
- image: postgres:10.1-alpine
|
||||
environment:
|
||||
POSTGRES_USER: administrate
|
||||
POSTGRES_DB: ruby26
|
||||
POSTGRES_PASSWORD: ""
|
||||
|
||||
|
||||
workflows:
|
||||
version: 2
|
||||
multiple-rubies:
|
||||
jobs:
|
||||
- ruby-26
|
||||
- ruby-25
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Containers
|
||||
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
ruby: [2.5, 2.6.3]
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
env:
|
||||
PGHOST: localhost
|
||||
PGUSER: administrate
|
||||
RAILS_ENV: test
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: postgres:10.1-alpine
|
||||
env:
|
||||
POSTGRES_USER: administrate
|
||||
POSTGRES_DB: ruby25
|
||||
POSTGRES_PASSWORD: ""
|
||||
ports:
|
||||
- 5432:5432
|
||||
# Add a health check
|
||||
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Setup Ruby
|
||||
uses: eregon/use-ruby-action@master
|
||||
with:
|
||||
ruby-version: ${{ matrix.ruby }}
|
||||
- name: Cache dependencies
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
path: vendor/bundle
|
||||
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
|
||||
- name: Install postgres headers
|
||||
run: sudo apt-get install libpq-dev
|
||||
- name: Install dependencies
|
||||
run: bundle install --path vendor/bundle
|
||||
- name: Setup environment configuration
|
||||
run: cp .sample.env .env
|
||||
- name: Setup database
|
||||
run: bundle exec rake db:setup
|
||||
- name: Run tests
|
||||
run: bundle exec rake
|
||||
- name: Install appraisal
|
||||
run: bundle exec appraisal install
|
||||
- name: Run appraisal
|
||||
run: bundle exec appraisal rake
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -0,0 +1,476 @@
|
||||
---
|
||||
title: Migrating from GitLab CI/CD to GitHub Actions
|
||||
intro: '{% data variables.product.prodname_actions %} and GitLab CI/CD share several configuration similarities, which makes migrating to {% data variables.product.prodname_actions %} relatively straightforward.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
GitLab CI/CD and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab CI/CD and {% data variables.product.prodname_actions %} share some similarities in workflow configuration:
|
||||
|
||||
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.
|
||||
- Workflows umfassen einen oder mehrere Jobs.
|
||||
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
|
||||
- Jobs can run on either managed or self-hosted machines.
|
||||
|
||||
There are a few differences, and this guide will show you the important differences so that you can migrate your workflow to {% data variables.product.prodname_actions %}.
|
||||
|
||||
### Jobs
|
||||
|
||||
Jobs in GitLab CI/CD are very similar to jobs in {% data variables.product.prodname_actions %}. In beiden Systemen haben Jobs folgende Merkmale:
|
||||
|
||||
* Jobs contain a series of steps or scripts that run sequentially.
|
||||
* Jobs can run on separate machines or in separate containers.
|
||||
* Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.
|
||||
|
||||
You can run a script or a shell command in a job. In GitLab CI/CD, script steps are specified using the `script` key. In {% data variables.product.prodname_actions %} sind alle Skripte mit dem Schlüssel `run` spezifiziert.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
job1:
|
||||
variables:
|
||||
GIT_CHECKOUT: "true"
|
||||
script:
|
||||
- echo "Run your script here"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
job1:
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- run: echo "Run your script here"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Runners
|
||||
|
||||
Runners are machines on which the jobs run. Both GitLab CI/CD and {% data variables.product.prodname_actions %} offer managed and self-hosted variants of runners. In GitLab CI/CD, `tags` are used to run jobs on different platforms, while in {% data variables.product.prodname_actions %} it is done with the `runs-on` key.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
windows_job:
|
||||
tags:
|
||||
- windows
|
||||
script:
|
||||
- echo Hello, %USERNAME%!
|
||||
|
||||
linux_job:
|
||||
tags:
|
||||
- linux
|
||||
script:
|
||||
- echo "Hello, $USER!"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
windows_job:
|
||||
runs-on : windows-latest
|
||||
steps:
|
||||
- run: echo Hello, %USERNAME%!
|
||||
|
||||
linux_job:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "Hello, $USER!"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)."
|
||||
|
||||
### Docker images
|
||||
|
||||
Both GitLab CI/CD and {% data variables.product.prodname_actions %} support running jobs in a Docker image. In GitLab CI/CD, Docker images are defined with a `image` key, while in {% data variables.product.prodname_actions %} it is done with the `container` key.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
my_job:
|
||||
image: node:10.16-jessie
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
my_job:
|
||||
container: node:10.16-jessie
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)."
|
||||
|
||||
### Condition and expression syntax
|
||||
|
||||
GitLab CI/CD uses `rules` to determine if a job will run for a specific condition. {% data variables.product.prodname_actions %} uses the `if` keyword to prevent a job from running unless a condition is met.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
deploy_prod:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "Deply to production server"
|
||||
rules:
|
||||
- if: '$CI_COMMIT_BRANCH == "master"'
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
deploy_prod:
|
||||
if: contains( github.ref, 'master')
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "Deply to production server"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
### Dependencies between Jobs
|
||||
|
||||
Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to set dependencies for a job. In both systems, jobs run in parallel by default, but job dependencies in {% data variables.product.prodname_actions %} can be specified explicitly with the `needs` key. GitLab CI/CD also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in {% data variables.product.prodname_actions %} with the `needs` key.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System. The workflows start with two jobs named `build_a` and `build_b` running in parallel, and when those jobs complete, another job called `test_ab` will run. Finally, when `test_ab` completes, the `deploy_ab` job will run.
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
stages:
|
||||
- build
|
||||
- test
|
||||
- deploy
|
||||
|
||||
build_a:
|
||||
stage: build
|
||||
script:
|
||||
- echo "This job will run first."
|
||||
|
||||
build_b:
|
||||
stage: build
|
||||
script:
|
||||
- echo "This job will run first, in parallel with build_a."
|
||||
|
||||
test_ab:
|
||||
stage: test
|
||||
script:
|
||||
- echo "This job will run after build_a and build_b have finished."
|
||||
|
||||
deploy_ab:
|
||||
stage: deploy
|
||||
script:
|
||||
- echo "This job will run after test_ab is complete"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
build_a:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "This job will be run first."
|
||||
|
||||
build_b:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "This job will be run first, in parallel with build_a"
|
||||
|
||||
test_ab:
|
||||
runs-on: ubuntu-latest
|
||||
needs: [build_a,build_b]
|
||||
steps:
|
||||
- run: echo "This job will run after build_a and build_b have finished"
|
||||
|
||||
deploy_ab:
|
||||
runs-on: ubuntu-latest
|
||||
needs: [test_ab]
|
||||
steps:
|
||||
- run: echo "This job will run after test_ab is complete"
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)“.
|
||||
|
||||
### Scheduling workflows
|
||||
|
||||
Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to run workflows at a specific interval. In GitLab CI/CD, pipeline schedules are configured with the UI, while in {% data variables.product.prodname_actions %} you can trigger a workflow on a scheduled interval with the "on" key.
|
||||
|
||||
For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#scheduled-events)."
|
||||
|
||||
### Variables and secrets
|
||||
|
||||
GitLab CI/CD and {% data variables.product.prodname_actions %} support setting environment variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI.
|
||||
|
||||
For more information, see "[Environment variables](/actions/reference/environment-variables)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
|
||||
|
||||
### Im Cache zwischenspeichern
|
||||
|
||||
GitLab CI/CD and {% data variables.product.prodname_actions %} provide a method in the configuration file to manually cache workflow files.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
image: node:latest
|
||||
|
||||
cache:
|
||||
key: $CI_COMMIT_REF_SLUG
|
||||
paths:
|
||||
- .npm/
|
||||
|
||||
before_script:
|
||||
- npm ci --cache .npm --prefer-offline
|
||||
|
||||
test_async:
|
||||
script:
|
||||
- node ./specs/start.js ./specs/async.spec.js
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
test_async:
|
||||
- name: Cache node modules
|
||||
uses: actions/cache@v2
|
||||
with:
|
||||
path: ~/.npm
|
||||
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: v1-npm-deps-
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)."
|
||||
|
||||
### Artifacts
|
||||
|
||||
Both GitLab CI/CD and {% data variables.product.prodname_actions %} can upload files and directories created by a job as artifacts. In {% data variables.product.prodname_actions %}, artifacts can be used to persist data across multiple jobs.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
script:
|
||||
artifacts:
|
||||
paths:
|
||||
- math-homework.txt
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
- name: Upload math result for job 1
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: homework
|
||||
path: math-homework.txt
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
For more information, see "[Storing workflow data as artifacts](/actions/guides/storing-workflow-data-as-artifacts)."
|
||||
|
||||
### Databases and service containers
|
||||
|
||||
Mit beiden Systemen kannst Du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.
|
||||
|
||||
In GitLab CI/CD, a container for the job is specified with the `image` key, while {% data variables.product.prodname_actions %} uses the `container` key. In both systems, additional service containers are specified with the `services` key.
|
||||
|
||||
Nachfolgend ein Beispiel für die Syntax in jedem System:
|
||||
|
||||
<table class="d-block">
|
||||
<tr>
|
||||
<th>
|
||||
GitLab CI/CD
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
container-job:
|
||||
variables:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
# The hostname used to communicate with the
|
||||
# PostgreSQL service container
|
||||
POSTGRES_HOST: postgres
|
||||
# The default PostgreSQL port
|
||||
POSTGRES_PORT: 5432
|
||||
image: node:10.18-jessie
|
||||
services:
|
||||
- postgres
|
||||
script:
|
||||
# Performs a clean installation of all dependencies
|
||||
# in the `package.json` file
|
||||
- npm ci
|
||||
# Runs a script that creates a PostgreSQL client,
|
||||
# populates the client with data, and retrieves data
|
||||
- node client.js
|
||||
tags:
|
||||
- docker
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
<td class="d-table-cell v-align-top">
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
container-job:
|
||||
runs-on: ubuntu-latest
|
||||
container: node:10.18-jessie
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: postgres
|
||||
env:
|
||||
POSTGRES_PASSWORD: postgres
|
||||
|
||||
steps:
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Performs a clean installation of all dependencies
|
||||
# in the `package.json` file
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Connect to PostgreSQL
|
||||
# Runs a script that creates a PostgreSQL client,
|
||||
# populates the client with data, and retrieves data
|
||||
run: node client.js
|
||||
env:
|
||||
# The hostname used to communicate with the
|
||||
# PostgreSQL service container
|
||||
POSTGRES_HOST: postgres
|
||||
# The default PostgreSQL port
|
||||
POSTGRES_PORT: 5432
|
||||
```
|
||||
{% endraw %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
For more information, see "[About service containers](/actions/guides/about-service-containers)."
|
||||
@@ -0,0 +1,293 @@
|
||||
---
|
||||
title: Von Jenkins zu GitHub-Aktionen migrieren
|
||||
intro: '{% data variables.product.prodname_actions %} und Jenkins haben mehrere Ähnlichkeiten, was die Migration zu {% data variables.product.prodname_actions %} relativ einfach macht.'
|
||||
redirect_from:
|
||||
- /actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Einführung
|
||||
|
||||
Jenkins und {% data variables.product.prodname_actions %} ermöglichen es Dir, Workflows zu erstellen, die automatisch Code bauen, testen, publizieren, freigeben und bereitstellen. Jenkins und {% data variables.product.prodname_actions %} haben einige Ähnlichkeiten in der Workflow-Konfiguration:
|
||||
|
||||
- Jenkins erstellt Workflows mit _Deklarativen Pipelines_, die den Workflow-Dateien in {% data variables.product.prodname_actions %} ähnlich sind.
|
||||
- Jenkins verwendet _„Stages“ (Phasen)_, um eine Gruppe von Schritten auszuführen, während {% data variables.product.prodname_actions %} Jobs verwenden, um einen oder mehrere Schritte oder einzelne Befehle zu gruppieren.
|
||||
- Jenkins und {% data variables.product.prodname_actions %} unterstützen Container-basierte Builds. Weitere Informationen finden Sie unter „[Eine Docker-Container-Aktion erstellen](/articles/creating-a-docker-container-action)“.
|
||||
- Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.
|
||||
|
||||
Weitere Informationen findest Du unter „[Kernkonzepte für {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/core-concepts-for-github-actions)“.
|
||||
|
||||
### Wesentliche Unterschiede
|
||||
|
||||
- Jenkins hat zwei Arten von Syntax zur Erzeugung von Pipelines: Deklarative Pipeline und „Scripted“ (Skript-basierte) Pipeline. {% data variables.product.prodname_actions %} verwendet YAML, um Workflows und Konfigurationsdateien zu erstellen. Weitere Informationen findest Du unter „[Workflow-Syntax für GitHub-Aktionen](/actions/reference/workflow-syntax-for-github-actions)."
|
||||
- Die Deployments von Jenkins ist üblicherweise selbst-gehosted, wobei die Benutzer die Server in ihren eigenen Rechenzentren betreuen. {% data variables.product.prodname_actions %} bieten einen hybriden Cloud-Ansatz, indem sie ihre eigenen Runner betreiben, die du zum Ausführen von Jobs verwenden kannst, während sie auch selbst-gehostete Läufer unterstützen. Weitere Informationen findest Du unter [Informationen zu selbst-gehosteten Runnnern](/actions/hosting-your-own-runners/about-self-hosted-runners).
|
||||
|
||||
### Funktionaltäten im Vergleich
|
||||
|
||||
#### Deine Builds verteilen
|
||||
|
||||
Mit Jenkins kannst Du Builds an einen einzelnen Build-Agenten senden oder sie über mehrere Agenten verteilen. Du kannst diese Agenten auch nach verschiedenen Attributen klassifizieren, wie zum Beispiel Arten von Betriebssystemen.
|
||||
|
||||
Similarly, {% data variables.product.prodname_actions %} can send jobs to {% data variables.product.prodname_dotcom %}-hosted or self-hosted runners, and you can use labels to classify runners according to various attributes. Die folgende Tabelle vergleicht, wie das Konzept für verteilte Builds sowohl bei Jenkins als auch bei {% data variables.product.prodname_actions %} umgesetzt ist.
|
||||
|
||||
| Jenkins | {% data variables.product.prodname_actions %}
|
||||
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [`Agenten`](https://wiki.jenkins.io/display/JENKINS/Distributed+builds) | [`Runner`](/actions/learn-github-actions/introduction-to-github-actions#runners) <br> [`selbst-gehostete Runner`](/actions/hosting-your-own-runners/about-self-hosted-runners) |
|
||||
|
||||
#### Sektionen verwenden, um Pipelines zu organisieren
|
||||
|
||||
Jenkins teilt seine Deklarative Pipelines in mehrere Sektionen auf. Similarly, {% data variables.product.prodname_actions %} organizes its workflows into separate sections. Die folgende Tabelle vergleicht Sektionen bei Jenkins mit dem Workflow bei {% data variables.product.prodname_actions %}.
|
||||
|
||||
| Anweisungen in Jenkins | {% data variables.product.prodname_actions %}
|
||||
| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| [`agent`](https://jenkins.io/doc/book/pipeline/syntax/#agent) | [`jobs.<job_id>.runs-on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-on) <br> [`jobs.<job_id>.container`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontainer) |
|
||||
| [`Beitrag`](https://jenkins.io/doc/book/pipeline/syntax/#post) | |
|
||||
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#stages) | [`jobs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobs) |
|
||||
| [`steps`](https://jenkins.io/doc/book/pipeline/syntax/#steps) | [`jobs.<job_id>.steps`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps) |
|
||||
|
||||
|
||||
### Anweisungen verwenden
|
||||
|
||||
Jenkins verwendet Anweisungen um _Deklarative Pipelines_ zu verwalten. Diese Anweisungen definieren die Merkmale Deines Workflows und die Art und weise, wie dieser ausgeführt wird. Die folgende Tabelle zeigt, wie diese Anweisungen den Konzepten innerhalb von {% data variables.product.prodname_actions %} entsprechen.
|
||||
|
||||
| Anweisungen in Jenkins | {% data variables.product.prodname_actions %}
|
||||
| ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment) | [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
|
||||
| [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`jobs.<job_id>.strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy) <br> [`jobs.<job_id>.strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast) <br> [`jobs.<job_id>.timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes) |
|
||||
| [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs) <br> [`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) |
|
||||
| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on) <br> [`on.<event_name>.types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes) <br> [<code>on.<push\|pull_request>.<branches\|tags></code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) <br> [<code>on.<push\|pull_request>.paths</code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) |
|
||||
| [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`jobs.<job_id>.needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) |
|
||||
| [Cron-Syntax in Jenkins](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax) | [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) |
|
||||
| [`Phase`](https://jenkins.io/doc/book/pipeline/syntax/#stage) | [`jobs.<job_id>`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id) <br> [`jobs.<job_id>.name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname) |
|
||||
| [`tools`](https://jenkins.io/doc/book/pipeline/syntax/#tools) | [Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software) |
|
||||
| [`input`](https://jenkins.io/doc/book/pipeline/syntax/#input) | [`inputs`](/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs) |
|
||||
| [`when`](https://jenkins.io/doc/book/pipeline/syntax/#when) | [`jobs.<job_id>.if`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) |
|
||||
|
||||
|
||||
### Sequenzielle „Stages“ (Phasen) verwenden
|
||||
|
||||
#### Parallele Verarbeitungvon Jobs
|
||||
|
||||
Jenkins kann die `Phasen` und `Schritte` parallel ausführen, wohingegen {% data variables.product.prodname_actions %} derzeit nur Jobs parallel ausführen.
|
||||
|
||||
| Jenkins Parallel | {% data variables.product.prodname_actions %}
|
||||
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [`parallel`](https://jenkins.io/doc/book/pipeline/syntax/#parallel) | [`jobs.<job_id>.strategy.max-parallel`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel) |
|
||||
|
||||
#### Build-Matrix
|
||||
|
||||
Sowohl {% data variables.product.prodname_actions %} als auch Jenkins lassen Dich eine Build-Matrix verwenden, um verschiedene Systemkombinationen zu definieren.
|
||||
|
||||
| Jenkins | {% data variables.product.prodname_actions %}
|
||||
| ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [`axis`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-axes) | [`strategy/matrix`](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix) <br> [`context`](/actions/reference/context-and-expression-syntax-for-github-actions) |
|
||||
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | [`steps-context`](/actions/reference/context-and-expression-syntax-for-github-actions#steps-context) |
|
||||
| [`excludes`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | |
|
||||
|
||||
#### Schritte verwenden, um „Tasks“ (Aufgaben) auszuführen
|
||||
|
||||
Jenkins gruppiert `„Steps“ (Schritte)` zusammen in `„Stages“ (Phasen)`. Jeder dieser Schritte kann unter anderem ein Skript, eine Funktion oder ein Befehl sein. In ähnlicher Weise verwenden {% data variables.product.prodname_actions %} `Jobs`, um bestimmte Gruppen von `Schritten` auszuführen.
|
||||
|
||||
| Jenkins-Schritte | {% data variables.product.prodname_actions %}
|
||||
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| [`script`](https://jenkins.io/doc/book/pipeline/syntax/#script) | [`jobs.<job_id>.steps`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps) |
|
||||
|
||||
### Beispiele für häufige Aufgaben
|
||||
|
||||
#### Zeitplanung einer Pipeline mit `cron`
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Jenkins-Pipeline
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}-Workflow
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
pipeline {
|
||||
agent any
|
||||
triggers {
|
||||
cron('H/15 * * * 1-5')
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
on:
|
||||
schedule:
|
||||
- cron: '*/15 * * * 1-5'
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### Umgebungsvariablen in einer Pipeline konfigurieren
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Jenkins-Pipeline
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}-Workflow
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
pipeline {
|
||||
agent any
|
||||
environment {
|
||||
MAVEN_PATH = '/usr/local/maven'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
maven-build:
|
||||
env:
|
||||
MAVEN_PATH: '/usr/local/maven'
|
||||
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### Aus „Upstream“ (vorgelagerten) Projekten bauen
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Jenkins-Pipeline
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}-Workflow
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
pipeline {
|
||||
triggers {
|
||||
upstream(
|
||||
upstreamProjects: 'job1,job2',
|
||||
threshold: hudson.model.Result.SUCCESS)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
job1:
|
||||
job2:
|
||||
needs: job1
|
||||
job3:
|
||||
needs: [job1, job2]
|
||||
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### Mit mehreren Betriebssystemen bauen
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Jenkins-Pipeline
|
||||
</th>
|
||||
<th>
|
||||
{% data variables.product.prodname_actions %}-Workflow
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```yaml
|
||||
pipeline {
|
||||
agent none
|
||||
stages {
|
||||
stage('Run Tests') {
|
||||
parallel {
|
||||
stage('Test On MacOS') {
|
||||
agent { label "macos" }
|
||||
tools { nodejs "node-12" }
|
||||
steps {
|
||||
dir("scripts/myapp") {
|
||||
sh(script: "npm install -g bats")
|
||||
sh(script: "bats tests")
|
||||
}
|
||||
}
|
||||
}
|
||||
stage('Test On Linux') {
|
||||
agent { label "linux" }
|
||||
tools { nodejs "node-12" }
|
||||
steps {
|
||||
dir("script/myapp") {
|
||||
sh(script: "npm install -g bats")
|
||||
sh(script: "bats tests")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: demo-workflow
|
||||
on:
|
||||
push:
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
os: [macos-latest, ubuntu-latest]
|
||||
steps:
|
||||
- uses: actions/checkout@v1
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: 12
|
||||
- run: npm install -g bats
|
||||
- run: bats tests
|
||||
working-directory: scripts/myapp
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: Security hardening for GitHub Actions
|
||||
shortTitle: Security hardening
|
||||
intro: 'Good security practices for using {% data variables.product.prodname_actions %} features.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/getting-started-with-github-actions/security-hardening-for-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
This guide explains how to configure security hardening for certain {% data variables.product.prodname_actions %} features. If the {% data variables.product.prodname_actions %} concepts are unfamiliar, see "[Core concepts for GitHub Actions](/actions/getting-started-with-github-actions/core-concepts-for-github-actions)."
|
||||
|
||||
### Using secrets
|
||||
|
||||
Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization or repository level, and allow you to store sensitive information in {% data variables.product.product_name %}.
|
||||
|
||||
Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository) or through the [REST API](/rest/reference/actions#secrets). This client-side encryption helps the minimize risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime.
|
||||
|
||||
To help prevent accidental disclosure, {% data variables.product.product_name %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets:
|
||||
|
||||
- **Never use structured data as a secret**
|
||||
- Unstructured data can cause secret redaction within logs to fail, because redaction largely relies on finding an exact match for the specific secret value. For example, do not use a blob of JSON, XML, or YAML (or similar) to encapsulate a secret value, as this significantly reduces the probability the secrets will be properly redacted. Instead, create individual secrets for each sensitive value.
|
||||
- **Register all secrets used within workflows**
|
||||
- If a secret is used to generate another sensitive value within a workflow, that generated value should be formally [registered as a secret](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret), so that it will be redacted if it ever appears in the logs. For example, if using a private key to generate a signed JWT to access a web API, be sure to register that JWT as a secret or else it won’t be redacted if it ever enters the log output.
|
||||
- Registering secrets applies to any sort of transformation/encoding as well. If your secret is transformed in some way (such as Base64 or URL-encoded), be sure to register the new value as a secret too.
|
||||
- **Audit how secrets are handled**
|
||||
- Audit how secrets are used, to help ensure they’re being handled as expected. You can do this by reviewing the source code of the repository executing the workflow, and checking any actions used in the workflow. For example, check that they’re not sent to unintended hosts, or explicitly being printed to log output.
|
||||
- View the run logs for your workflow after testing valid/invalid inputs, and check that secrets are properly redacted, or not shown. It's not always obvious how a command or tool you’re invoking will send errors to `STDOUT` and `STDERR`, and secrets might subsequently end up in error logs. As a result, it is good practice to manually review the workflow logs after testing valid and invalid inputs.
|
||||
- **Use credentials that are minimally scoped**
|
||||
- Make sure the credentials being used within workflows have the least privileges required, and be mindful that any user with write access to your repository has read access to all secrets configured in your repository.
|
||||
- **Audit and rotate registered secrets**
|
||||
- Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
|
||||
- Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
|
||||
|
||||
### Using third-party actions
|
||||
|
||||
The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them.
|
||||
|
||||
This means that a compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and can use the `GITHUB_TOKEN` to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. You can help mitigate this risk by following these good practices:
|
||||
|
||||
* **Pin actions to a full length commit SHA**
|
||||
|
||||
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** The short version of the commit SHA is insecure and should never be used for specifying an action's Git reference. Because of how repository networks work, any user can fork the repository and push a crafted commit to it that collides with the short SHA. This causes subsequent clones at that SHA to fail because it becomes an ambiguous commit. As a result, any workflows that use the shortened SHA will immediately fail.
|
||||
|
||||
{% endwarning %}
|
||||
* **Audit the source code of the action**
|
||||
|
||||
Ensure that the action is handling the content of your repository and secrets as expected. For example, check that secrets are not sent to unintended hosts, or are not inadvertently logged.
|
||||
|
||||
* **Pin actions to a tag only if you trust the creator**
|
||||
|
||||
Although pinning to a commit SHA is the most secure option, specifying a tag is more convenient and is widely used. If you’d like to specify a tag, then be sure that you trust the action's creators. The ‘Verified creator’ badge on {% data variables.product.prodname_marketplace %} is a useful signal, as it indicates that the action was written by a team whose identity has been verified by {% data variables.product.prodname_dotcom %}. Note that there is risk to this approach even if you trust the author, because a tag can be moved or deleted if a bad actor gains access to the repository storing the action.
|
||||
|
||||
### Considering cross-repository access
|
||||
|
||||
{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` used in the workflow environment grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to the workflow environment, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
|
||||
|
||||
We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow environment. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
|
||||
|
||||
This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference:
|
||||
|
||||
1. **The `GITHUB_TOKEN` in the workflow environment**
|
||||
- This token is intentionally scoped to the single repository that invoked the workflow, and has the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
- The `GITHUB_TOKEN` should be used whenever possible.
|
||||
2. **Repository deploy key**
|
||||
- Deploy keys are one of the only credential types that grant read or write access to a single repository, and can be used to interact with another repository within a workflow. For more information, see "[Managing deploy keys](/developers/overview/managing-deploy-keys#deploy-keys)."
|
||||
- Note that deploy keys can only clone and push to the repository using Git, and cannot be used to interact with the REST or GraphQL API, so they may not be appropriate for your requirements.
|
||||
3. **{% data variables.product.prodname_github_app %} tokens**
|
||||
- {% data variables.product.prodname_github_apps %} can be installed on select repositories, and even have granular permissions on the resources within them. You could create a {% data variables.product.prodname_github_app %} internal to your organization, install it on the repositories you need access to within your workflow, and authenticate as the installation within your workflow to access those repositories.
|
||||
4. **Persönliche Zugriffsstokens**
|
||||
- You should never use personal access tokens from your own account. These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your user account. This indirectly grants broad access to all write-access users of the repository the workflow is in. In addition, if you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging.
|
||||
- If a personal access token is used, it should be one that was generated for a new account that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.
|
||||
5. **SSH keys on a user account**
|
||||
- Workflows should never use the SSH keys on a user account. Similar to personal access tokens, they grant read/write permissions to all of your personal repositories as well as all the repositories you have access to through organization membership. This indirectly grants broad access to all write-access users of the repository the workflow is in. If you're intending to use an SSH key because you only need to perform repository clones or pushes, and do not need to interact with public APIs, then you should use individual deploy keys instead.
|
||||
|
||||
### Hardening for self-hosted runners
|
||||
|
||||
**{% data variables.product.prodname_dotcom %}-hosted** runners execute code within ephemeral and clean isolated virtual machines, meaning there is no way to persistently compromise this environment, or otherwise gain access to more information than was placed in this environment during the bootstrap process.
|
||||
|
||||
**Self-hosted** runners on {% data variables.product.product_name %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow.
|
||||
|
||||
As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a PR (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the more privileged `GITHUB_TOKEN` which grants write-access permissions on the repository.
|
||||
|
||||
You should also consider the environment of the self-hosted runner machines:
|
||||
- What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others.
|
||||
- Does the machine have network access to sensitive services? For example, Azure or AWS metadata services. The amount of sensitive information in this environment should be kept to a minimum, and you should always be mindful that any user capable of invoking workflows has access to this environment.
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
title: Sharing workflows with your organization
|
||||
shortTitle: Sharing workflows with your organization
|
||||
intro: 'Learn how you can use organization features to collaborate with your team, by sharing workflow templates, secrets, and self-hosted runners.'
|
||||
redirect_from:
|
||||
- /actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Übersicht
|
||||
|
||||
If you need to share workflows and other {% data variables.product.prodname_actions %} features with your team, then consider collaborating within a {% data variables.product.prodname_dotcom %} organization. An organization allows you to centrally store and and manage secrets, artifacts, and self-hosted runners. You can also create workflow templates in the `.github` repository and share them with other users in your organization.
|
||||
|
||||
### Erstellen einer Workflowvorlage
|
||||
|
||||
Workflowvorlagen können von Benutzern mit Schreibzugriff auf die `.github` Repository der Organisation erstellt werden. Die Vorlagen können dann von Organisationsmitgliedern verwendet werden, die über die Berechtigung zum Erstellen von Workflows verfügen. Workflowvorlagen können verwendet werden, um neue Workflows in öffentlichen Repositorys einer Organisation zu erstellen. Um Vorlagen zum Erstellen von Workflows in privaten Repositorys zu verwenden, muss die Organisation Teil eines Unternehmens- oder GitHub One-Plans sein.
|
||||
|
||||
In diesem Verfahren wird veranschaulicht, wie eine Workflowvorlage und eine Metadatendatei erstellt werden. Die Metadatendatei beschreibt, wie die Vorlage benutzern beim Erstellen eines neuen Workflows angezeigt wird.
|
||||
|
||||
1. Wenn es noch nicht vorhanden ist, erstellen Sie ein neues öffentliches Repository mit dem Namen `.github` in Ihrer Organisation.
|
||||
1. Erstellen Sie ein Verzeichnis mit dem Namen `Workflowvorlagen`.
|
||||
1. Erstellen Sie Ihre neue Workflowdatei im `Workflow-Vorlagen` Verzeichnis.
|
||||
|
||||
Wenn Sie auf den Standardzweig eines Repositorys verweisen müssen, können Sie den `$default-branch` Platzhalter verwenden. Wenn ein Workflow mit Ihrer Vorlage erstellt wird, wird der Platzhalter automatisch durch den Namen der Standardverzweigung des Repositorys ersetzt.
|
||||
|
||||
Diese Datei mit dem Namen `octo-organization-ci.yml` veranschaulicht beispielsweise einen grundlegenden Workflow.
|
||||
|
||||
```yaml
|
||||
Name: Octo Organization CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branch: [ $default-branch ]
|
||||
pull_request:
|
||||
branches: [ $default-branch ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Run a one-line script
|
||||
run: echo Hello from Octo Organization
|
||||
```
|
||||
1. Erstellen Sie eine Metadatendatei im `Workflow-Vorlagen` Verzeichnis. Die Metadatendatei muss denselben Namen wie die Workflowdatei haben, aber anstelle der Erweiterung `.yml` muss sie mit `.properties.json`angehängt werden. Diese Datei mit dem Namen `octo-organization-ci.properties.json enthält` beispielsweise die Metadaten für eine Workflowdatei mit dem Namen `octo-organization-ci.yml`:
|
||||
```yaml
|
||||
•
|
||||
"Name": "Octo Organization Workflow",
|
||||
"beschreibung": "Octo Organization CI workflow template.",
|
||||
"iconName": "example-icon",
|
||||
"categories": [
|
||||
"Go"
|
||||
],
|
||||
"filePatterns": [
|
||||
"package.json
|
||||
|
||||
|
||||
|
||||
"
|
||||
```
|
||||
* `Name` - **erforderlich.** Der Name der Workflowvorlage. Dies wird in der Liste der verfügbaren Vorlagen angezeigt.
|
||||
* `Beschreibung` - **erforderlich.** Die Beschreibung der Workflowvorlage. Dies wird in der Liste der verfügbaren Vorlagen angezeigt.
|
||||
* `iconName` - **Erforderlich.** Definiert ein Symbol für den Eintrag des Workflows in der Vorlagenliste. Der `iconName` muss ein SVG-Symbol mit demselben Namen sein und in den `Workflow-Vorlagen` Verzeichnis gespeichert werden. Beispielsweise wird eine SVG-Datei mit dem Namen `example-icon.svg` als `Beispielsymbol`referenziert.
|
||||
* `Kategorien` - **Optional.** Definiert die Sprachkategorie des Workflows. Wenn ein Benutzer die verfügbaren Vorlagen anzeigt, werden die Vorlagen, die derselben Sprache entsprechen, stärker in den Vordergrund gerückt. Informationen zu den verfügbaren Sprachkategorien finden Sie unter https://github.com/github/linguist/blob/master/lib/linguist/languages.yml.
|
||||
* `filePatterns` - **Optional.** Ermöglicht die Verwendung der Vorlage, wenn das Repository des Benutzers eine Datei im Stammverzeichnis enthält, die einem definierten regulären Ausdruck entspricht.
|
||||
|
||||
Um eine weitere Workflowvorlage hinzuzufügen, fügen Sie Ihre Dateien `Workflow-Vorlagen` -Verzeichnis hinzu. Ein Beispiel:
|
||||
|
||||
|
||||
|
||||
### Verwenden einer Workflowvorlage
|
||||
|
||||
In diesem Verfahren wird veranschaulicht, wie ein Mitglied Ihrer Organisation eine Workflowvorlage finden und verwenden kann, um einen neuen Workflow zu erstellen. Die Workflowvorlagen einer Organisation können von jedem Benutzer verwendet werden, der Mitglied der Organisation ist.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. Wenn Ihr Repository bereits über vorhandene Workflows verfügt: Klicken Sie in der linken oberen Ecke auf **Neuer Workflow**. 
|
||||
1. Die Workflowvorlagen Ihrer Organisation befinden sich in ihrem eigenen Abschnitt mit dem Titel "Workflows, die von _Organisationsnamen_erstellt wurden". Klicke unter dem Namen der zu verwendenden Vorlage auf **Set up this workflow** (Workflow einrichten). 
|
||||
|
||||
|
||||
### Sharing secrets within an organization
|
||||
|
||||
You can centrally manage your secrets within an organization, and then make them available to selected repositories. This also means that you can update a secret in one location, and have the change apply to all repository workflows that use the secret.
|
||||
|
||||
Beim Erstellen eines geheimen Schlüssels in einer Organisation können Sie eine Richtlinie verwenden, um einzuschränken, welche Repositorys auf diesen geheimen Schlüssel zugreifen können. Sie können z. B. Zugriff auf alle Repositorys gewähren oder den Zugriff auf nur private Repositorys oder eine angegebene Liste von Repositorys beschränken.
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-organization %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Klicken Sie auf **Neue geheime**.
|
||||
1. Geben Sie einen Namen für Ihr Geheimnis in das Eingabefeld **Name** ein.
|
||||
1. Geben Sie den **Value** für Ihr Geheimnis ein.
|
||||
1. Wählen Sie im **Repository-Zugriff** Dropdownliste eine Zugriffsrichtlinie aus.
|
||||
1. Klicken Sie auf **Add secret** (Geheimnis hinzufügen).
|
||||
|
||||
### Share self-hosted runners within an organization
|
||||
|
||||
Organization admins can add their self-hosted runners to groups, and then create policies that control which repositories can access the group.
|
||||
|
||||
For more information, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)."
|
||||
|
||||
|
||||
### Nächste Schritte:
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/security-hardening-for-github-actions)."
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: Adding a workflow status badge
|
||||
intro: You can display a status badge in your repository to indicate the status of your workflows.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% data reusables.repositories.actions-workflow-status-badge-into %}
|
||||
|
||||
Wenn Ihr Workflow den `Namen` Schlüsselwort verwendet, müssen Sie auf den Workflow anhand des Namens verweisen. Wenn der Name Ihres Workflows Leerraum enthält, müssen Sie das Leerzeichen durch die URL codierte Zeichenfolge `%20`ersetzen. Weitere Informationen zum Schlüsselwort `name` findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#name)“.
|
||||
|
||||
```
|
||||
https://github.com/<OWNER>/<REPOSITORY>/Workflows/<WORKFLOW_NAME>/badge.svg
|
||||
```
|
||||
|
||||
Wenn Ihr Workflow keinen `Namen`hat, müssen Sie auch auf die Workflowdatei verweisen, indem Sie den Dateipfad relativ zum Stammverzeichnis des Repositorys verwenden.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Verweisen auf die Workflowdatei mithilfe des Dateipfads funktioniert nicht, wenn der Workflow einen `Namen`hat.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
```
|
||||
https://github.com/<OWNER>/<REPOSITORY>/Workflows/<WORKFLOW_FILE_PATH>/badge.svg
|
||||
```
|
||||
|
||||
### Using a workflow name
|
||||
|
||||
In diesem Markdown-Beispiel wird ein Status-Badge für einen Workflow mit dem Namen "Greet Everyone" hinzugefügt. Die `owner` des Repositorys sind die `Aktionen` Organisation, und der name `REPOSITORY` ist `hello-world`.
|
||||
|
||||
```
|
||||
! [Beispiel-Workflowname] (https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg)
|
||||
```
|
||||
|
||||
### Using a workflow file path
|
||||
|
||||
In diesem Markdown-Beispiel wird ein Status-Badge für einen Workflow mit dem Dateipfad `.github/workflows/main.yml`hinzugefügt. Die `owner` des Repositorys sind die `Aktionen` Organisation, und der name `REPOSITORY` ist `hello-world`.
|
||||
|
||||
```
|
||||
! [Beispiel Workflowdateipfad] (https://github.com/actions/hello-world/workflows/.github/workflows/main.yml/badge.svg)
|
||||
```
|
||||
|
||||
### Using the `branch` parameter
|
||||
|
||||
In diesem Markdown-Beispiel wird ein Status-Badge für eine Verzweigung mit dem Namen `Feature-1-`hinzugefügt.
|
||||
|
||||
```
|
||||
! [Beispiel-Zweigparameter] (https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?branch=feature-1)
|
||||
```
|
||||
|
||||
### Using the `event` parameter
|
||||
|
||||
In diesem Markdown-Beispiel wird ein Badge hinzugefügt, das den Status von Workflowausführungen anzeigt, die durch das `pull_request` -Ereignis ausgelöst werden.
|
||||
|
||||
```
|
||||
! [Beispielereignisparameter] (https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?event=pull_request)
|
||||
```
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Canceling a workflow
|
||||
intro: 'You can cancel a workflow run that is in progress. When you cancel a workflow run, {% data variables.product.prodname_dotcom %} cancels all jobs and steps that are a part of that workflow.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-write %}
|
||||
|
||||
### Einen Workflow-Lauf abbrechen
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. In the upper-right corner of the workflow, click **Cancel workflow**. 
|
||||
|
||||
### Steps {% data variables.product.prodname_dotcom %} takes to cancel a workflow run
|
||||
|
||||
Beim Abbrechen der Workflowausführung führen Sie möglicherweise andere Software aus, die Ressourcen verwendet, die mit der Workflowausführung zusammenhängen. To help you free up resources related to the workflow run, it may help to understand the steps {% data variables.product.prodname_dotcom %} performs to cancel a workflow run.
|
||||
|
||||
1. Um die Workflowausführung abzubrechen, wertet der Server `neu aus, wenn` Bedingungen für alle derzeit ausgeführten Aufträge. Wenn die Bedingung als true</code>`wird, wird der Auftrag nicht abgebrochen. Beispielsweise <code>die Bedingung, ob: always()` als true ausgewertet wird und der Auftrag weiterhin ausgeführt wird. Wenn keine Bedingung vorhanden ist, entspricht dies der Bedingung `wenn: success()`, die nur ausgeführt wird, wenn der vorherige Schritt erfolgreich abgeschlossen wurde.
|
||||
2. Bei Aufträgen, die abgebrochen werden müssen, sendet der Server eine Abbruchnachricht an alle Läufercomputer mit Aufträgen, die abgebrochen werden müssen.
|
||||
3. Bei Aufträgen, die weiterhin ausgeführt werden, wertet der Server `neu aus, ob` Bedingungen für die unvollendeten Schritte. Wenn die Bedingung als true</code>`wird, wird der Schritt weiterhin ausgeführt.</li>
|
||||
<li>Für Schritte, die abgebrochen werden müssen, sendet die Läufermaschine <code>SIGINT/Ctrl-C-` an den Schritteingabeprozess (`Knoten` für Javascript-Aktion, `docker` für Containeraktion und `bash/cmd/pwd` , wenn sie</code> in einem Schritt verwenden `ausführen). Wenn der Prozess nicht innerhalb von 7500 ms beendet wird, sendet der Läufer <code>SIGTERM/Ctrl-Break-` an den Prozess, und wartet dann 2500 ms, bis der Prozess beendet wird. Wenn der Prozess noch ausgeführt wird, tötet der Läufer den Prozessbaum.
|
||||
5. Nach ablaufen 5 Minuten Abbruchzeit zeitoutt der Server das Beenden aller Aufträge und Schritte, die die Ausführung nicht beenden oder den Abbruchvorgang nicht abschließen können.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Löschen einer Workflowausführung
|
||||
intro: 'You can delete a workflow run that has been completed, or is more than two weeks old.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-write %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
1. Um eine Workflowausführung zu löschen, verwenden Sie das Dropdownmenü {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} , und wählen Sie **Workflow löschen**.
|
||||
|
||||
|
||||
2. Überprüfen Sie die Bestätigungsaufforderung, und klicken Sie auf **Ja, löschen Sie diesen Workflow, der**ausgeführt wird.
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Disabling and enabling a workflow
|
||||
intro: You can disable and re-enable a workflow using {% data variables.product.prodname_dotcom %} or the REST API.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.23'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Disabling a workflow allows you to stop a workflow from being triggered without having to delete the file from the repo. You can easily re-enable the workflow again on {% data variables.product.prodname_dotcom %}. You can also disable and enable a workflow using the REST API. For more information, see the "[Actions REST API](/rest/reference/actions#workflows)."
|
||||
|
||||
Temporarily disabling a workflow can be useful in many scenarios. These are a few examples where disabling a workflow might be helpful:
|
||||
|
||||
- A workflow error that produces too many or wrong requests, impacting external services negatively.
|
||||
- A workflow that is not critical and is consuming too many minutes on your account.
|
||||
- A workflow that sends requests to a service that is down.
|
||||
- Workflows on a forked repository that aren't needed (for example, scheduled workflows).
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** {% data reusables.actions.scheduled-workflows-disabled %}
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Disabling a workflow
|
||||
|
||||
You can manually disable a workflow so that it won't execute any workflow runs. A disabled workflow is not deleted, and can be re-enabled.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. In the left sidebar, click the workflow you want to disable. 
|
||||
1. Click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}. 
|
||||
1. Click **Disable workflow**.  The disabled workflow is marked {% octicon "stop" aria-label="The stop icon" %} to indicate its status. 
|
||||
|
||||
### Enabling a workflow
|
||||
|
||||
You can re-enable a workflow that was previously disabled.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. In the left sidebar, click the workflow you want to enable. 
|
||||
1. Click **Enable workflow**. 
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Downloading workflow artifacts
|
||||
intro: You can download archived artifacts before they automatically expire.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %} By default, {% data variables.product.product_name %} stores build logs and artifacts for 90 days, and you can customize this retention period, depending on the type of repository. For more information, see "[Configuring the retention period for GitHub Actions artifacts and logs in your repository](/github/administering-a-repository/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)."{% endif %}
|
||||
{% if currentVersion == "enterprise-server@2.22" %} {% data variables.product.product_name %} stores full build logs and artifacts for 90 days.{% endif %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. Under **Artifacts**, click the artifact you want to download. 
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Debug-Protokollierung aktivieren
|
||||
intro: 'Wenn die Workflow-Logs nicht genügend Details zur Diagnose enthalten, warum ein Workflow, ein Job oder ein Schritt nicht wie erwartet abläuft, können Sie die zusätzliche Debug-Protokollierung aktivieren.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Diese zusätzlichen Protokolle werden aktiviert, indem Geheimnisse im Repository, die den Workflow enthalten, gesetzt werden, sodass die gleichen Berechtigungsanforderungen gelten:
|
||||
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-repository %}
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-organization %}
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-api %}
|
||||
|
||||
Weitere Informationen zum Festlegen von Geheimnissen finden Sie unter "[Erstellen und Verwenden verschlüsselter Geheimnisse](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
|
||||
|
||||
### Diagnose-Protokollierung des Runners aktivieren
|
||||
|
||||
Die Runner-Diagnoseprotokollierung stellt zusätzliche Protokolldateien bereit, die Informationen darüber enthalten, wie ein Läufer einen Auftrag ausführt. In das Protokollarchiv werden zwei weitere Protokolldateien aufgenommen:
|
||||
|
||||
* das Runner-Prozessprotokoll mit Informationen zur Koordinierung und Einrichtung von Runnern für die Ausführung von Aufträgen
|
||||
* das Worker-Prozessprotokoll, in dem die Ausführung eines Auftrags protokolliert wird
|
||||
|
||||
1. Zum Aktivieren der Runner-Diagnoseprotokollierung legen Sie das folgende Geheimnis im Repository fest, in dem sich der Workflow befindet: `ACTIONS_RUNNER_DEBUG` auf `true`.
|
||||
|
||||
1. Sollen die Runner-Diagnoseprotokolle heruntergeladen werden, laden Sie das Protokollarchiv des Workflow-Laufs herunter. Die Runner-Diagnoseprotokolle befinden sich im Ordner `runner-diagnostic-logs`. For more information on downloading logs, see "[Downloading logs](/actions/managing-workflow-runs/using-workflow-run-logs/#downloading-logs)."
|
||||
|
||||
### Debug-Schrittprotokollierung aktivieren
|
||||
|
||||
Bei der Debug-Schrittprotokollierung werden ausführlichere Protokolle während und nach der Ausführung eines Auftrags erstellt.
|
||||
|
||||
1. Zum Aktivieren der Debug-Schrittprotokollierung legen Sie das folgende Geheimnis im Repository fest, in dem sich der Workflow befindet: `ACTIONS_STEP_DEBUG` auf `true`.
|
||||
|
||||
1. Sobald Sie das Geheimnis festgelegt haben, werden weitere Debug-Ereignisse in den Schrittprotokollen aufgeführt. Weitere Informationen finden Sie unter [„Protokolle zur Fehlerdiagnose anzeigen“](/actions/managing-workflow-runs/using-workflow-run-logs/#viewing-logs-to-diagnose-failures).
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Managing workflow runs
|
||||
shortTitle: Managing workflow runs
|
||||
intro: 'Sie können den Status und die Ergebnisse der einzelnen Schritte in Ihrem Workflow anzeigen, einen ausstehenden Workflow abbrechen, fakturierbare Auftragsausführungsminuten anzeigen, einen fehlgeschlagenen Workflow debuggen und erneut ausführen, Protokolle suchen und herunterladen und Artefakte herunterladen.'
|
||||
redirect_from:
|
||||
- /actions/configuring-and-managing-workflows/managing-a-workflow-run
|
||||
- /articles/viewing-your-repository-s-workflows
|
||||
- /articles/viewing-your-repositorys-workflows
|
||||
- /articles/managing-a-workflow-run
|
||||
- /github/automating-your-workflow-with-github-actions/managing-a-workflow-run
|
||||
- /actions/automating-your-workflow-with-github-actions/managing-a-workflow-run
|
||||
- /actions/configuring-and-managing-workflows/configuring-and-managing-workflow-files-and-runs
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% link_in_list /viewing-workflow-run-history %}
|
||||
{% link_in_list /using-workflow-run-logs %}
|
||||
{% link_in_list /manually-running-a-workflow %}
|
||||
{% link_in_list /re-running-a-workflow %}
|
||||
{% link_in_list /canceling-a-workflow %}
|
||||
{% link_in_list /disabling-and-enabling-a-workflow %}
|
||||
{% link_in_list /deleting-a-workflow-run %}
|
||||
{% link_in_list /viewing-job-execution-time %}
|
||||
{% link_in_list /downloading-workflow-artifacts %}
|
||||
{% link_in_list /removing-workflow-artifacts %}
|
||||
{% link_in_list /enabling-debug-logging %}
|
||||
{% link_in_list /adding-a-workflow-status-badge %}
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Manuelle Ausführung eines Workflows
|
||||
intro: 'When a workflow is configured to run on the `workflow_dispatch` event, you can run the workflow using the REST API or from the Actions tab on {% data variables.product.prodname_dotcom %}.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
To run a workflow manually, the workflow must be configured to run on the `workflow_dispatch` event. Weitere Informationen findest Du unter "[Ereignisse, die Workflows auslösen](/actions/reference/events-that-trigger-workflows)."
|
||||
|
||||
### Running a workflow on {% data variables.product.prodname_dotcom %}
|
||||
|
||||
To trigger the `workflow_dispatch` event on {% data variables.product.prodname_dotcom %}, your workflow must be in the default branch. Führen Sie die folgenden Schritte aus, um eine Workflowausführung manuell auszulösen.
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. Klicken Sie in der linken Seitenleiste auf den Workflow, den Sie ausführen möchten. 
|
||||
1. Wählen Sie über der Liste der Workflowausführungen **Workflow ausführen**. 
|
||||
1. Wählen Sie die Verzweigung aus, in der der Workflow ausgeführt wird, und geben Sie die Eingabeparameter ein, die vom Workflow verwendet werden. Klicken Sie auf **Workflow ausführen**. 
|
||||
|
||||
### Running a workflow using the REST API
|
||||
|
||||
Wenn Sie die REST-API verwenden, konfigurieren Sie die `eingaben` und `ref` als Anforderungstextparameter. Wenn die Eingaben weggelassen werden, werden die in der Workflowdatei definierten Standardwerte verwendet.
|
||||
|
||||
Weitere Informationen zur Verwendung der REST-API finden Sie unter "[Erstellen eines Workflow-Dispatch-Ereignisses](/rest/reference/actions/#create-a-workflow-dispatch-event)."
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Re-running a workflow
|
||||
intro: You can re-run an instance of a workflow. Re-running a workflow uses the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) of the original event that triggered the workflow run.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. In the upper-right corner of the workflow, use the **Re-run jobs** drop-down menu, and select **Re-run all jobs**. 
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Removing workflow artifacts
|
||||
intro: 'You can reclaim used {% data variables.product.prodname_actions %} storage by deleting artifacts before they expire on {% data variables.product.product_name %}.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Deleting an artifact
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warnung:** Sobald Du ein Artefakt löschst, kann es nicht wiederhergestellt werden.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-write %}
|
||||
|
||||
{% data reusables.github-actions.artifact-log-retention-statement %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. Under **Artifacts**, click {% octicon "trashcan" aria-label="The trashcan icon" %} next to the artifact you want to remove. 
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
### Setting the retention period for an artifact
|
||||
|
||||
Retention periods for artifacts and logs can be configured at the repository, organization, and enterprise level. For more information, see "[Usage limits, billing, and administration](/actions/reference/usage-limits-billing-and-administration#artifact-and-log-retention-policy)."
|
||||
|
||||
You can also define a custom retention period for individual artifacts using the `actions/upload-artifact` action in a workflow. For more information, see "[Storing workflow data as artifacts](/actions/guides/storing-workflow-data-as-artifacts#configuring-a-custom-artifact-retention-period)."
|
||||
|
||||
### Finding the expiration date of an artifact
|
||||
|
||||
You can use the API to confirm the date that an artifact is scheduled to be deleted. For more information, see the `expires_at` value returned by "[List artifacts for a repository](/rest/reference/actions#artifacts)."
|
||||
{% endif %}
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: Using workflow run logs
|
||||
intro: 'You can view, search, and download the logs for each job in a workflow run.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Auf der Workflow-Lauf-Seite können sie sehen, ob ein Workflow-Lauf ausgeführt wird oder abgeschlossen ist. Sie müssen mit einem {% data variables.product.prodname_dotcom %}-Konto angemeldet sein, um Workflow-Informationen anzuzeigen, auch für öffentliche Repositories. Weitere Informationen finden Sie unter „[Zugriffsberechtigungen auf GitHub](/articles/access-permissions-on-github)“.
|
||||
|
||||
Wenn der Lauf abgeschlossen ist, können Sie sehen, ob das Ergebnis erfolgreich, fehlerhaft, abgebrochen oder neutral war. Wenn der Lauf fehlgeschlagen ist, können Sie die Build-Protokolle anzeigen und durchsuchen, um den Fehler zu diagnostizieren und den Workflow erneut auszuführen. Sie können auch fakturierbare Auftragsausführungsminuten anzeigen oder Protokolle herunterladen und Artefakte erstellen.
|
||||
|
||||
{% data variables.product.prodname_actions %} verwenden die Checks API, um Status, Ergebnisse und Protokolle für einen Workflow auszugeben. {% data variables.product.prodname_dotcom %} erstellt eine neue Prüfsuite für jeden Workflow-Lauf. Die Prüfsuite enthält einen Prüflauf für jeden Auftrag im Workflow, und jeder Auftrag enthält Schritte. {% data variables.product.prodname_actions %} werden als Schritt in einem Workflow ausgeführt. Weitere Informationen zur Prüf-API finden Sie unter "[](/v3/checks/)".
|
||||
|
||||
{% data reusables.github-actions.invalid-workflow-files %}
|
||||
|
||||
### Protokolle zur Fehlerdiagnose anzeigen
|
||||
|
||||
Wenn Ihr Workflow-Lauf fehlschlägt, können Sie sehen, welcher Schritt den Fehler verursacht hat, und die Build-Protokolle des fehlgeschlagenen Schrittes zur Fehlerbehebung überprüfen. Sie sehen, wie lange es gedauert hat, bis jeder Schritt ausgeführt wurde. Sie können außerdem einen Permalink in eine bestimmte Zeile in der Protokolldatei kopieren, um ihn mit Ihrem Team zu teilen. {% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
In addition to the steps configured in the workflow file, {% data variables.product.prodname_dotcom %} adds two additional steps to each job to set up and complete the job's execution. These steps are logged in the workflow run with the names "Set up job" and "Complete job".
|
||||
|
||||
For jobs run on {% data variables.product.prodname_dotcom %}-hosted runners, "Set up job" records details of the runner's virtual environment, and includes a link to the list of preinstalled tools that were present on the runner machine.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow-superlinter %}
|
||||
{% data reusables.repositories.view-run-superlinter %}
|
||||
{% data reusables.repositories.navigate-to-job-superlinter %}
|
||||
{% data reusables.repositories.view-failed-job-results-superlinter %}
|
||||
{% data reusables.repositories.view-specific-line-superlinter %}
|
||||
|
||||
### Protokolle durchsuchen
|
||||
|
||||
Sie können die Build-Protokolle für einen bestimmten Schritt durchsuchen. Beim Durchsuchen von Protokollen werden nur eingeblendete Schritte in die Ergebnisse einbezogen. {% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow-superlinter %}
|
||||
{% data reusables.repositories.view-run-superlinter %}
|
||||
{% data reusables.repositories.navigate-to-job-superlinter %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
1. Gib in der oberen rechten Ecke der Protokollausgabe im Suchfeld **Search logs** (Protokolle durchsuchen) eine Suchanfrage ein. 
|
||||
{% else %}
|
||||
1. Um jeden Schritt, den Sie in Ihre Suche einbeziehen möchten, einzublenden, klicken Sie auf den Schritt. 
|
||||
1. Gib in der oberen rechten Ecke der Protokollausgabe im Suchfeld **Search logs** (Protokolle durchsuchen) eine Suchanfrage ein. 
|
||||
{% endif %}
|
||||
|
||||
### Herunterladen von Protokollen
|
||||
|
||||
Sie können die Protokolldateien von Ihrem Workflowlauf herunterladen. Sie können auch die Artefakte eines Workflows herunterladen. Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“. {% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow-superlinter %}
|
||||
{% data reusables.repositories.view-run-superlinter %}
|
||||
{% data reusables.repositories.navigate-to-job-superlinter %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
1. In the upper right corner, click
|
||||
{% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} and select **Download log archive**.
|
||||
|
||||
{% else %}
|
||||
1. In the upper right corner, click
|
||||
{% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} and select **Download log archive**.
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Logs löschen
|
||||
|
||||
Du kannst die Logdateien aus Deiner Workflow-Ausführung löschen. {% data reusables.repositories.permissions-statement-write %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow-superlinter %}
|
||||
{% data reusables.repositories.view-run-superlinter %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
1. In the upper right corner, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}. 
|
||||
2. Um die Logdateien zu löschen, klicke auf **Delete all logs** (Alle Logs löschen) und überprüfe die Bestätigungsanfrage.  Nach die Protokolle gelöscht sind, verschwindet die Schaltfläche **Delete all logs**, um anzuzeigen, dass keine Protokolldateien mehr im Workflowlauf verbleiben.
|
||||
{% else %}
|
||||
1. In the upper right corner, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}. 
|
||||
2. Um die Logdateien zu löschen, klicke auf **Delete all logs** (Alle Logs löschen) und überprüfe die Bestätigungsanfrage.  After the logs have been deleted, the **Delete all logs** button is removed to indicate that no log files remain in the workflow run.
|
||||
{% endif %}
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Viewing job execution time
|
||||
intro: 'Sie können die Ausführungszeit eines Auftrags anzeigen, einschließlich der fakturierbaren Minuten, die ein Einzelvorgang angesammelt hat.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Billable job execution minutes are only shown for jobs run on private repositories that use {% data variables.product.prodname_dotcom %}-hosted runners. There are no billable minutes when using {% data variables.product.prodname_actions %} in public repositories or for jobs run on self-hosted runners.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. Under the job summary, you can view the job's execution time. To view the billable job execution time, click **Run and billable time details**. 
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Die angezeigte Abrechnungszeit enthält keine Rundungen oder Minutenmultiplikatoren. To view your total {% data variables.product.prodname_actions %} usage, including rounding and minute multipliers, see "[Viewing your {% data variables.product.prodname_actions %} usage](/github/setting-up-and-managing-billing-and-payments-on-github/viewing-your-github-actions-usage)."
|
||||
|
||||
{% endnote %}
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Viewing workflow run history
|
||||
intro: You can view logs for each run of a workflow. Logs include the status for each job and step in a workflow.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
@@ -55,11 +55,12 @@ Committing the workflow file in your repository triggers the `push` event and ru
|
||||
|
||||
### Viewing your workflow results
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. Klicke in der linken Seitenleiste auf den Workflow, den Du sehen willst. 
|
||||
1. From the list of workflow runs, click the name of the run you want to see. 
|
||||
{% data reusables.repositories.navigate-to-workflow-superlinter %}
|
||||
{% data reusables.repositories.view-run-superlinter %}
|
||||
1. In the left sidebar, click the **Lint code base** job. 
|
||||
2. Expand the **Run Super-Linter** step to view the results. 
|
||||
{% data reusables.repositories.view-failed-job-results-superlinter %}
|
||||
|
||||
### More starter workflows
|
||||
|
||||
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Authentication in a workflow
|
||||
intro: '{% data variables.product.prodname_dotcom %} stellt ein Token zur Verfügung, mit dem Du Dich im Namen von {% data variables.product.prodname_actions %} authentifizieren kannst.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/authenticating-with-the-github_token
|
||||
- /actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token
|
||||
- /actions/configuring-and-managing-workflows/authenticating-with-the-github_token
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Jeder mit `write`(schreiben)-Zugriff auf ein Repository kann Geheimnisse erstellen, lesen und verwenden.
|
||||
|
||||
### Informationen zum `GITHUB_TOKEN`-Geheimnis
|
||||
|
||||
{% data variables.product.prodname_dotcom %} erstellt automatisch ein `GITHUB_TOKEN`-Geheimnis für den Workflow. Du kannst den `GITHUB_TOKEN` verwenden, um Dich in einem Workflow zu authentifizieren.
|
||||
|
||||
Wenn Du {% data variables.product.prodname_actions %} aktivierst, installiert {% data variables.product.prodname_dotcom %} eine {% data variables.product.prodname_github_app %} in Deinem Repository. Das `GITHUB_TOKEN`-Geheimnis ist ein {% data variables.product.prodname_github_app %}-Token für Installations-Zugriff. Du kannst das Installationszugriffs-Token verwenden, um Dich im Namen der auf Deinem Repository installierten {% data variables.product.prodname_github_app %} zu authentifizieren. Die Berechtigungen des Tokens sind auf das Repository beschränkt, in dem sich der Workflow befindet. Weitere Informationen findest Du unter "[Berechtigungen für das `GITHUB_TOKEN`](#permissions-for-the-github_token)."
|
||||
|
||||
Before each job begins, {% data variables.product.prodname_dotcom %} fetches an installation access token for the job. Das Token läuft ab, wenn der Auftrag abgeschlossen ist.
|
||||
|
||||
Das Token ist auch im `github.token`-Kontext verfügbar. Weitere Informationen findest Du unter "[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
|
||||
### Das `GITHUB_TOKEN` in einem Workflow verwenden
|
||||
|
||||
Um das `GITHUB_TOKEN`-Geheimnis zu verwenden, musst Du es in Deiner Workflow-Datei referenzieren. Hierbei musst Du das Token ggf. als Eingabe für eine Aktion übergeben, für die dieses Token erforderlich ist, oder authentifizierte Aufrufe der {% data variables.product.prodname_dotcom %}-API ausführen.
|
||||
|
||||
{% data reusables.github-actions.actions-do-not-trigger-workflows %}
|
||||
|
||||
#### Beispiel: Das `GITHUB_TOKEN` als Eingabe übergeben
|
||||
|
||||
Dieser Beispielworkflow verwendet die [Labeler-Aktion](https://github.com/actions/labeler), wofür das `GITHUB_TOKEN` als Wert für den Eingabeparameter `repo-token` benötigt wird:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Pull request labeler
|
||||
on:
|
||||
- pull_request
|
||||
jobs:
|
||||
triage:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/labeler@v2
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Beispiel zum Aufrufen der REST-API
|
||||
|
||||
Du kannst das `GITHUB_TOKEN` verwenden, um authentifizierte API-Aufrufe durchzuführen. Dieser Beispiel-Workflow erzeugt eine Lieferung („issue“) mittels der {% data variables.product.prodname_dotcom %}-REST-API:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Create issue on commit
|
||||
on:
|
||||
- push
|
||||
jobs:
|
||||
create_commit:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Create issue using REST API
|
||||
run: |
|
||||
curl --request POST \
|
||||
--url https://api.github.com/repos/${{ github.repository }}/issues \
|
||||
--header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
|
||||
--header 'content-type: application/json' \
|
||||
--data '{
|
||||
"title": "Automated issue for commit: ${{ github.sha }}",
|
||||
"body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n Der Commit-Hash lautete: _'{{ github.sha }}_."
|
||||
}'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Berechtigungen für das `GITHUB_TOKEN`
|
||||
|
||||
For information about the API endpoints {% data variables.product.prodname_github_apps %} can access with each permission, see "[{% data variables.product.prodname_github_app %} Permissions](/v3/apps/permissions/)."
|
||||
|
||||
| Berechtigung | Zugriffstyp | Zugriff durch geforktes Repository |
|
||||
| ------------------------ | --------------- | ---------------------------------- |
|
||||
| actions | Lesen/Schreiben | Lesen |
|
||||
| checks (Prüfungen) | Lesen/Schreiben | Lesen |
|
||||
| contents (Inhalte) | Lesen/Schreiben | Lesen |
|
||||
| deployments | Lesen/Schreiben | Lesen |
|
||||
| Issues (Lieferungen) | Lesen/Schreiben | Lesen |
|
||||
| Metadaten | Lesen | Lesen |
|
||||
| Pakete | Lesen/Schreiben | Lesen |
|
||||
| pull requests | Lesen/Schreiben | Lesen |
|
||||
| repository projects | Lesen/Schreiben | Lesen |
|
||||
| statuses (Statusangaben) | Lesen/Schreiben | Lesen |
|
||||
|
||||
Wenn Du ein Token benötigst, für das Berechtigungen erforderlich sind, die nicht im `GITHUB_TOKEN`-Geheimnis vorhanden sind, kannst Du ein persönliches Zugangstoken erstellen und als Geheimnis im Repository festlegen:
|
||||
|
||||
1. Verwende oder erstelle ein Token mit den entsprechenden Berechtigungen für dieses Repository. Weitere Informationen finden Sie unter "[Erstellen eines persönlichen Zugriffstokens](/github/authenticating-to-github/creating-a-personal-access-token)."
|
||||
1. Füge das Token als Geheimnis in das Repository Deines Workflows ein, und verweise darauf mit der Syntax {%raw%}`${{ secrets.SECRET_NAME }}`{% endraw %}. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
|
||||
@@ -81,27 +81,27 @@ Der `github`-Kontext enthält Informationen zum Workflow-Lauf und zu dem Ereigni
|
||||
|
||||
{% data reusables.github-actions.github-context-warning %}
|
||||
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| ------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `github` | `Objekt` | Der Top-Level-Kontext, der bei jedem Job oder Schritt im Workflow verfügbar ist. |
|
||||
| `github.event` | `Objekt` | Die vollständige Nutzlast des Ereignis-Webhooks. Weitere Informationen findest Du unter „[Ereignisse, die Workflows auslösen](/articles/events-that-trigger-workflows)“. You can access individual properties of the event using this context. |
|
||||
| `github.event_path` | `string` | Der Pfad zur vollständigen Event-Webhook-Nutzlast auf dem Runner. |
|
||||
| `github.workflow` | `string` | Der Name des Workflows. Wenn in der Workflow-Datei kein `name` festgelegt ist, entspricht der Wert dieser Eigenschaft dem vollständigen Pfad der Workflow-Datei im Repository. |
|
||||
| `github.job` | `string` | Die [`job_id`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) des aktuellen Jobs. |
|
||||
| `github.run_id` | `string` | {% data reusables.github-actions.run_id_description %} |
|
||||
| `github.run_number` | `string` | {% data reusables.github-actions.run_number_description %} |
|
||||
| `github.actor` | `string` | Der Anmeldename des Benutzers, der den Workflow-Lauf initiiert hat. |
|
||||
| `github.repository` | `string` | Der Inhaber- und Repository-Name, Beispielsweise `Codertocat/Hello-World`. |
|
||||
| `github.repository_owner` | `string` | Der Name des Repository-Besitzers. Beispielsweise `Codertocat`. |
|
||||
| `github.event_name` | `string` | Der Name des Ereignisses, das den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.sha` | `string` | Die Commit-SHA, die den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.ref` | `string` | Das Branch- oder Tag-Ref, das den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.head_ref` | `string` | Das `head_ref` oder der Quell-Branch des Pull Requests in einem Workflow-Lauf. Diese Eigenschaft ist nur verfügbar, wenn das Ereignis, das einen Workflow auslöst, ein `pull_request` (Pull Request) ist. |
|
||||
| `github.base_ref` | `string` | Das `base_ref` oder der Ziel-Branch des Pull Requests in einem Workflow-Lauf. Diese Eigenschaft ist nur verfügbar, wenn das Ereignis, das einen Workflow auslöst, ein `pull_request` (Pull Request) ist. |
|
||||
| `github.token` | `string` | Ein Token zum Authentifizieren im Namen der in Deinem Repository installierten GitHub-App. Funktionell entspricht dies dem Geheimnis `GITHUB_TOKEN`. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)". |
|
||||
| `github.workspace` | `string` | Das Standardarbeitsverzeichnis für Schritte und der Standardspeicherort Deines Repositorys bei Verwendung der Aktion [ `checkout`](https://github.com/actions/checkout). |
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| ------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `github` | `Objekt` | Der Top-Level-Kontext, der bei jedem Job oder Schritt im Workflow verfügbar ist. |
|
||||
| `github.action` | `string` | Der Name der aktuell laufenden Aktion. {% data variables.product.prodname_dotcom %} entfernt Sonderzeichen oder verwendet den Namen `run` wenn der aktuelle Schritt ein Skript ausführt. Wenn Du dieselbe Aktion mehr als einmal im selben Job verwendest, enthält der Name ein Suffix mit der Sequenznummer. Zum Beispiel wird das erste Skript, das Du ausführst, den Namen `run1`haben, und das zweite Skript heißt `run2`. Ebenso wird die zweite Anrufung von `actions/checkout` `actionscheckout2` sein. |
|
||||
| `github.action_path` | `string` | The path where your action is located. You can use this path to easily access files located in the same repository as your action. This attribute is only supported in composite run steps actions. |
|
||||
| `github.action_path` | `string` | The path where your action is located. You can use this path to easily access files located in the same repository as your action. This attribute is only supported in composite run steps actions. |
|
||||
| `github.actor` | `string` | Der Anmeldename des Benutzers, der den Workflow-Lauf initiiert hat. |
|
||||
| `github.base_ref` | `string` | Das `base_ref` oder der Ziel-Branch des Pull Requests in einem Workflow-Lauf. Diese Eigenschaft ist nur verfügbar, wenn das Ereignis, das einen Workflow auslöst, ein `pull_request` (Pull Request) ist. |
|
||||
| `github.event` | `Objekt` | Die vollständige Nutzlast des Ereignis-Webhooks. Weitere Informationen findest Du unter „[Ereignisse, die Workflows auslösen](/articles/events-that-trigger-workflows)“. You can access individual properties of the event using this context. |
|
||||
| `github.event_name` | `string` | Der Name des Ereignisses, das den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.event_path` | `string` | Der Pfad zur vollständigen Event-Webhook-Nutzlast auf dem Runner. |
|
||||
| `github.head_ref` | `string` | Das `head_ref` oder der Quell-Branch des Pull Requests in einem Workflow-Lauf. Diese Eigenschaft ist nur verfügbar, wenn das Ereignis, das einen Workflow auslöst, ein `pull_request` (Pull Request) ist. |
|
||||
| `github.job` | `string` | Die [`job_id`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) des aktuellen Jobs. |
|
||||
| `github.ref` | `string` | Das Branch- oder Tag-Ref, das den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.repository` | `string` | Der Inhaber- und Repository-Name, Beispielsweise `Codertocat/Hello-World`. |
|
||||
| `github.repository_owner` | `string` | Der Name des Repository-Besitzers. Beispielsweise `Codertocat`. |
|
||||
| `github.run_id` | `string` | {% data reusables.github-actions.run_id_description %}
|
||||
| `github.run_number` | `string` | {% data reusables.github-actions.run_number_description %}
|
||||
| `github.sha` | `string` | Die Commit-SHA, die den Workflow-Lauf ausgelöst hat. |
|
||||
| `github.token` | `string` | Ein Token zum Authentifizieren im Namen der in Deinem Repository installierten GitHub-App. Funktionell entspricht dies dem Geheimnis `GITHUB_TOKEN`. Weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)". |
|
||||
| `github.workflow` | `string` | Der Name des Workflows. Wenn in der Workflow-Datei kein `name` festgelegt ist, entspricht der Wert dieser Eigenschaft dem vollständigen Pfad der Workflow-Datei im Repository. |
|
||||
| `github.workspace` | `string` | Das Standardarbeitsverzeichnis für Schritte und der Standardspeicherort Deines Repositorys bei Verwendung der Aktion [ `checkout`](https://github.com/actions/checkout). |
|
||||
|
||||
#### **`env`-Kontext**
|
||||
|
||||
@@ -121,17 +121,17 @@ Du kannst den `env`-Kontext nur im Wert der Schlüssel `with` und `name` verwend
|
||||
|
||||
Der `job`-Kontext enthält Informationen zum gerade ausgeführten Auftrag.
|
||||
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| ----------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Auftrag` | `Objekt` | Dieser Kontext ändert sich bei jedem Auftrag in einem Workflow-Lauf. Du kannst bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. |
|
||||
| `job.status` | `string` | Der aktuelle Status des Auftrags. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen) oder `cancelled` (abgebrochen). |
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| ----------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Auftrag` | `Objekt` | Dieser Kontext ändert sich bei jedem Auftrag in einem Workflow-Lauf. Du kannst bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. |
|
||||
| `job.container` | `Objekt` | Informationen zum Container des Auftrags. Weitere Informationen zu Containern findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#jobsjob_idcontainer)“. |
|
||||
| `job.container.network` | `string` | Die ID des Container-Netzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
|
||||
| `job.container.id` | `string` | Die ID des Containers |
|
||||
| `job.container.id` | `string` | Die ID des Containers |
|
||||
| `job.container.network` | `string` | Die ID des Container-Netzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
|
||||
| `job.services` | `Objekt` | Die für einen Auftrag erstellten Dienstcontainer. Weitere Informationen zu Dienstcontainern findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#jobsjob_idservices)“. |
|
||||
| `job.services.<service id>.id` | `string` | Die ID des Service-Containers. |
|
||||
| `job.services.<service id>.ports` | `Objekt` | Die offengelegten Ports des Service-Containers |
|
||||
| `job.services.<service id>.network` | `string` | Die ID des Dienstcontainer-Netzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
|
||||
| `job.services.<service id>.id` | `string` | Die ID des Service-Containers. |
|
||||
| `job.services.<service id>.network` | `string` | Die ID des Dienstcontainer-Netzwerks. Der Runner erstellt das Netzwerk, das von allen Containern in einem Auftrag genutzt wird. |
|
||||
| `job.services.<service id>.ports` | `Objekt` | Die offengelegten Ports des Service-Containers |
|
||||
| `job.status` | `string` | Der aktuelle Status des Auftrags. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen) oder `cancelled` (abgebrochen). |
|
||||
|
||||
#### **`steps`-Kontext**
|
||||
|
||||
@@ -140,31 +140,31 @@ Der `steps`-Kontext enthält Informationen zu den Schritten im aktuellen Auftrag
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| --------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `steps` | `Objekt` | Dieser Kontext ändert sich bei jedem Schritt in einem Auftrag. Du kannst bei jedem Schritt in einem Auftrag auf diesen Kontext zugreifen. |
|
||||
| `steps.<step id>.outputs` | `Objekt` | Der Satz an Ausgaben, die für diesen Schritt definiert wurden. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions#outputs)“. |
|
||||
| `steps.<step id>.outputs.<output name>` | `string` | Der Wert einer bestimmten Ausgabe |
|
||||
| `steps.<step id>.outcome` | `string` | Das Ergebnis eines abgeschlossenen Schritts bevor [`continue-on-error` (bei Fehler weitermachen)](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) angewendet wird. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen), `cancelled` (abgebrochen) oder `skipped` (übersprungen). Wenn ein Schritt mit `continue-on-error` (bei Fehler weitermachen) fehlschlägt, ist `outcome` (Ergebnis) `failure` zwar (Fehler), aber `conclusion` (Schlussfolgerung) ist am Ende `success` (Erfolg). |
|
||||
| `steps.<step id>.outputs` | `Objekt` | Der Satz an Ausgaben, die für diesen Schritt definiert wurden. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions#outputs)“. |
|
||||
| `steps.<step id>.conclusion` | `string` | Das Ergebnis eines abgeschlossenen Schritts nachdem[`continue-on-error` (bei Fehler weitermachen)](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) angewendet wurde. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen), `cancelled` (abgebrochen) oder `skipped` (übersprungen). Wenn ein Schritt mit `continue-on-error` (bei Fehler weitermachen) fehlschlägt, ist `outcome` (Ergebnis) `failure` zwar (Fehler), aber `conclusion` (Schlussfolgerung) ist am Ende `success` (Erfolg). |
|
||||
| `steps.<step id>.outcome` | `string` | Das Ergebnis eines abgeschlossenen Schritts bevor [`continue-on-error` (bei Fehler weitermachen)](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) angewendet wird. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen), `cancelled` (abgebrochen) oder `skipped` (übersprungen). Wenn ein Schritt mit `continue-on-error` (bei Fehler weitermachen) fehlschlägt, ist `outcome` (Ergebnis) `failure` zwar (Fehler), aber `conclusion` (Schlussfolgerung) ist am Ende `success` (Erfolg). |
|
||||
| `steps.<step id>.outputs.<output name>` | `string` | Der Wert einer bestimmten Ausgabe |
|
||||
|
||||
#### **`runner`-Kontext**
|
||||
|
||||
Der `runner`-Kontext enthält Informationen über den Runner, der den aktuellen Job ausführt.
|
||||
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| -------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `runner.os` | `string` | Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind `Linux`, `Windows` oder `macOS`. |
|
||||
| `runner.temp` | `string` | Der Pfad des temporären Verzeichnisses für den Runner. Dieses Verzeichnis ist zu Beginn jedes Auftrags garantiert leer, sogar bei selbst-gehosteten Runnern. |
|
||||
| `runner.tool_cache` | `string` | Der Pfad des Verzeichnisses, das einige der vorinstallierten Tools für {% data variables.product.prodname_dotcom %}-gehostete Runner enthält. Weitere Informationen findest Du unter „[Auf GitHub-gehosteten Runnern installierte Software](/actions/automating-your-workflow-with-github-actions/software-installed-on-github-hosted-runners)". |
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| -------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `runner.os` | `string` | Das Betriebssystem des Runners, der den Job ausführt. Mögliche Werte sind `Linux`, `Windows` oder `macOS`. |
|
||||
| `runner.temp` | `string` | Der Pfad des temporären Verzeichnisses für den Runner. Dieses Verzeichnis ist zu Beginn jedes Auftrags garantiert leer, sogar bei selbst-gehosteten Runnern. |
|
||||
| `runner.tool_cache` | `string` | Der Pfad des Verzeichnisses, das einige der vorinstallierten Tools für {% data variables.product.prodname_dotcom %}-gehostete Runner enthält. For more information, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)". |
|
||||
|
||||
#### **`needs`-Kontext**
|
||||
|
||||
Der `needs`-Kontext enthält Ausgaben von allen Jobs, die als Abhängigkeit des aktuellen Jobs definiert sind. Weitere Informationen zur Definition von Jobabhängigkeiten findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)“.
|
||||
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| -------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `needs.<job id>` | `Objekt` | Ein einzelner Job, von dem der aktuelle Job abhängt. |
|
||||
| `needs.<job id>.result` | `string` | Das Ergebnis eines Jobs, von dem der aktuelle Job abhängt. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen) oder `cancelled` (abgebrochen). |
|
||||
| `needs.<job id>.outputs` | `Objekt` | Die Menge aller Ausgaben eines Jobs, von dem der aktuelle Job abhängt. |
|
||||
| `needs.<job id>.outputs.<output name>` | `string` | Der Wert einer bestimmten Ausgabe für einen Job, von dem der aktuelle Job abhängt. |
|
||||
| Name der Eigenschaft | Typ | Beschreibung |
|
||||
| -------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `needs.<job id>` | `Objekt` | Ein einzelner Job, von dem der aktuelle Job abhängt. |
|
||||
| `needs.<job id>.outputs` | `Objekt` | Die Menge aller Ausgaben eines Jobs, von dem der aktuelle Job abhängt. |
|
||||
| `needs.<job id>.outputs.<output name>` | `string` | Der Wert einer bestimmten Ausgabe für einen Job, von dem der aktuelle Job abhängt. |
|
||||
| `needs.<job id>.result` | `string` | Das Ergebnis eines Jobs, von dem der aktuelle Job abhängt. Mögliche Werte sind `success` (erfolgreich), `failure` (fehlgeschlagen), `cancelled` (abgebrochen) oder `skipped` (übersprungen). |
|
||||
|
||||
#### Beispiel für die Ausgabe von Kontextinformationen in der Protokolldatei
|
||||
|
||||
@@ -179,7 +179,7 @@ on: push
|
||||
|
||||
jobs:
|
||||
one:
|
||||
runs-on: ubuntu-16.04
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Dump GitHub context
|
||||
env:
|
||||
@@ -252,7 +252,7 @@ env:
|
||||
| `&&` | Und |
|
||||
| <code>\|\|</code> | Oder |
|
||||
|
||||
{% data variables.product.prodname_dotcom %} führt einen nicht strengen Gleichheitsvergleich aus.
|
||||
{% data variables.product.prodname_dotcom %} vergleicht auf Gleichheit in toleranter Weise.
|
||||
|
||||
* Wenn die Typen nicht übereinstimmen, wandelt {% data variables.product.prodname_dotcom %} den Typ in eine Zahl um. {% data variables.product.prodname_dotcom %} wandelt Daten verschiedener Typen folgendermaßen in eine Zahl um:
|
||||
|
||||
|
||||
@@ -0,0 +1,221 @@
|
||||
---
|
||||
title: Encrypted secrets
|
||||
intro: Verschlüsselte Geheimnisse ermöglichen es Ihnen, vertrauliche Informationen in Ihrem Repository oder Ihrer Organisation zu speichern.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
|
||||
- /actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
|
||||
- /actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu verschlüsselten Geheimnissen
|
||||
|
||||
Geheimnisse sind verschlüsselte Umgebungsvariablen, die Sie in einem Repository oder einer Organisation erstellen. The secrets you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} verwendet eine [versiegelte Libsodium-Box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) um sicherzustellen, dass Geheimnisse verschlüsselt werden, bevor sie {% data variables.product.prodname_dotcom %} erreichen, und verschlüsselt bleiben, bis Du sie in einem Workflow verwendest.
|
||||
|
||||
{% data reusables.github-actions.secrets-org-level-overview %}
|
||||
|
||||
#### Benennen Ihrer Geheimnisse
|
||||
|
||||
Die folgenden Regeln gelten für geheime Namen:
|
||||
|
||||
* Geheime Namen dürfen nur alphanumerische Zeichen (`[a-z]`, `[A-Z]`, `[0-9]`) oder Unterstriche (`_`) enthalten. Leerzeichen sind nicht zulässig.
|
||||
* Geheime Namen dürfen nicht mit dem `GITHUB_` -Präfix beginnen.
|
||||
* Geheime Namen dürfen nicht mit einer Zahl beginnen.
|
||||
* Geheime Namen müssen auf der Ebene eindeutig sein, auf der sie erstellt werden. Beispielsweise muss ein geheimer Schlüssel, der auf Organisationsebene erstellt wird, einen eindeutigen Namen auf dieser Ebene haben, und ein geheimer Schlüssel, der auf Repository-Ebene erstellt wird, muss einen eindeutigen Namen in diesem Repository haben. Wenn ein Geheimschlüssel auf Organisationsebene denselben Namen wie ein Geheimschlüssel auf Repository-Ebene hat, hat der geheime Schlüssel auf Repository-Ebene Vorrang.
|
||||
|
||||
To help ensure that {% data variables.product.prodname_dotcom %} redacts your secret in logs, avoid using structured data as the values of secrets. Vermeide beispielsweise Geheimnisse zu erstellen, die JSON oder codierte Git-Blobs enthalten.
|
||||
|
||||
#### Zugriff auf Ihre Geheimnisse
|
||||
|
||||
Um ein Geheimnis für eine Aktion verfügbar zu machen, legen Sie das Geheimnis als Eingabe oder Umgebungsvariable in der Workflow-Datei fest. In der README-Datei der Aktion erfahren Sie, welche Eingaben und Umgebungsvariablen die Aktion erwartet. Weitere Informationen finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)“.
|
||||
|
||||
Du kannst verschlüsselte Geheimnisse in einer Workflow-Datei verwenden und lesen, wenn Du auf die Datei Bearbeitungs-Zugriff hast. Weitere Informationen findest Du unter „[Zugriffsberechtigungen auf {% data variables.product.prodname_dotcom %}](/github/getting-started-with-github/access-permissions-on-github)“.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warnung:** {% data variables.product.prodname_dotcom %} redigiert Geheimnisse zwar automatisch bei Ausgabe ins Log, aber Du solltest nicht vorsätzlich Geheimnisse ins Log schreiben.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
Sie können Geheimnisse auch mit der REST-API verwalten. Weitere Informationen finden Sie unter "[Secrets](/v3/actions/secrets/)".
|
||||
|
||||
#### Einschränken von Anmeldeinformationsberechtigungen
|
||||
|
||||
Beim Generieren von Anmeldeinformationen wird empfohlen, möglichst geringe Berechtigungen zu erteilen. Anstatt z.B. persönliche Anmeldeinformationen zu verwenden, solltest Du [Bereitstellen von Schlüsseln](/v3/guides/managing-deploy-keys/#deploy-keys) oder einen „Service-Account“ (Dienstkonto) benuzen. Ziehe in Erwägung, Nur-Lese-Berechtigungen zu gewähren, wenn dies ausreicht, und schränke den Zugriff so weit wie möglich ein. Wähle beim Generieren eines persönlichen Zugriffstokens („personal access token“, PAT) die geringsmöglichen Anwendungsbereiche („scopes“) aus.
|
||||
|
||||
### Erstellen verschlüsselter Geheimnisse für ein Repository
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-repository %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Klicken Sie auf **Add a new secret** (Neues Geheimnis hinzufügen).
|
||||
1. Geben Sie einen Namen für Ihr Geheimnis in das Eingabefeld **Name** ein.
|
||||
1. Geben Sie den Wert für Ihr Geheimnis ein.
|
||||
1. Klicken Sie auf **Add secret** (Geheimnis hinzufügen).
|
||||
|
||||
Wenn Ihr Repository auf Geheimnisse der übergeordneten Organisation zugreifen kann, werden diese Geheimnisse auch auf dieser Seite aufgeführt.
|
||||
|
||||
### Erstellen verschlüsselter Geheimnisse für eine Organisation
|
||||
|
||||
Beim Erstellen eines geheimen Schlüssels in einer Organisation können Sie eine Richtlinie verwenden, um einzuschränken, welche Repositorys auf diesen geheimen Schlüssel zugreifen können. Sie können z. B. Zugriff auf alle Repositorys gewähren oder den Zugriff auf nur private Repositorys oder eine angegebene Liste von Repositorys beschränken.
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-organization %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Klicken Sie auf **Neue geheime**.
|
||||
1. Geben Sie einen Namen für Ihr Geheimnis in das Eingabefeld **Name** ein.
|
||||
1. Geben Sie den **Value** für Ihr Geheimnis ein.
|
||||
1. Wählen Sie im **Repository-Zugriff** Dropdownliste eine Zugriffsrichtlinie aus.
|
||||
1. Klicken Sie auf **Add secret** (Geheimnis hinzufügen).
|
||||
|
||||
### Überprüfen des Zugriffs auf Geheimnisse auf Organisationsebene
|
||||
|
||||
Sie können überprüfen, welche Zugriffsrichtlinien auf einen geheimen Schlüssel in Ihrer Organisation angewendet werden.
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Die Liste der Geheimnisse enthält alle konfigurierten Berechtigungen und Richtlinien. Ein Beispiel: 
|
||||
1. Weitere Informationen zu den konfigurierten Berechtigungen für jeden geheimen Schlüssel finden Sie unter **Aktualisieren**.
|
||||
|
||||
### Verschlüsselte Geheimnisse in einem Workflow verwenden
|
||||
|
||||
Mit Ausnahme von `GITHUB_TOKEN` werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository aus ausgelöst wird.
|
||||
|
||||
Um eine Aktion mit einem Geheimnis als Eingabe- oder Umgebungsvariable zu versehen, kannst Du den `secrets` Kontext verwenden, um auf Geheimnisse zuzugreifen, die Du in Deinem Repository erstellt hast. Weitere Informationen findest Du unter "[Kontext und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)" und "[Workflow-Syntax für {% data variables.product.prodname_actions %}](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)."
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
with: # Das Geheimnis als Eingabe setzen
|
||||
super_secret: ${{ secrets.SuperSecret }}
|
||||
env: # Oder als Umgebunsvariable ("environment variable")
|
||||
super_secret: ${{ secrets.SuperSecret }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Wann immer dies möglich ist, vermeide die Übergabe von Geheimnissen zwischen Prozessen von der Befehlszeile aus. Befehlszeilen-Prozesse können für andere Benutzer (mithilfe des Befehls `ps`) sichtbar sein oder von [„security audit events“ (Ereignissen zur Sicherheits-Überprüfung)](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing) erfasst werden. Um den Schutz von Geheimnissen zu unterstützen, solltest Du die Verwendung von Umgebungsvariablen, `STDIN` oder andere vom Zielprozess unterstützte Mechanismen in Betracht ziehen.
|
||||
|
||||
Wenn Sie Geheimnisse innerhalb einer Kommandozeile übergeben müssen, umschließe sie im Rahmen der gültigen Quotierungsregeln. Geheimnisse enthalten oft Sonderzeichen, die in Deiner Shell unbeabsichtigte Wirkungen entfalten können. Um diese Sonderzeichen zu vermeiden, verwende Deine Umgebungsvariablen mit Anführungszeichen. Ein Beispiel:
|
||||
|
||||
#### Beispiel mit Bash
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- shell: bash
|
||||
env:
|
||||
SUPER_SECRET: ${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Beispiel mit PowerShell
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- shell: pwsh
|
||||
env:
|
||||
SUPER_SECRET: ${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$env:SUPER_SECRET"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Beispiel mit Cmd.exe
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
steps:
|
||||
- shell: cmd
|
||||
env:
|
||||
SUPER_SECRET: ${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "%SUPER_SECRET%"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Einschränkungen für Geheimnisse
|
||||
|
||||
Dein Workflow kann bis zu 100 Geheimnisse haben. Die Namen von Geheimnis-Umgebungsvariablen müssen Repository-weit eindeutig sein.
|
||||
|
||||
Geheimnisse sind auf 64 KB beschränkt. Um Geheimnisse zu verwenden, die größer als 64 KB sind, können Sie verschlüsselte Geheimnisse in Ihrem Repository speichern und die Passphrase zur Entschlüsselung als Geheimnis auf {% data variables.product.prodname_dotcom %} speichern. Sie können beispielsweise `gpg` verwenden, um Ihre Anmeldeinformationen lokal zu verschlüsseln, bevor Sie die Datei in Ihrem Repository auf {% data variables.product.prodname_dotcom %} einchecken. Weitere Informationen finden Sie auf der „[gpg-Manpage](https://www.gnupg.org/gph/de/manual/r1023.html)“.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warnung**: Achte darauf, dass Deine Geheimnisse nicht gedruckt werden, wenn Deine Aktion ausgeführt wird. Wenn Sie diesen Workaround verwenden, redigiert {% data variables.product.prodname_dotcom %} keine Geheimnisse, die in Protokollen gedruckt werden.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
1. Führe den folgenden Befehl von Deinem Terminal aus, um die Datei `my_secret.json` mit `gpg` und dem Verschlüsselungs-Algorithmus AES256 zu verschlüsseln.
|
||||
|
||||
``` shell
|
||||
$ gpg --symmetric --cipher-algo AES256 my_secret.json
|
||||
```
|
||||
|
||||
1. Du wirst aufgefordert, eine Passphrase einzugeben. Merken Sie sich die Passphrase, denn Sie müssen ein neues Geheimnis auf {% data variables.product.prodname_dotcom %} mit der Passphrase als Wert erstellen.
|
||||
|
||||
1. Erstellen Sie einen neuen Geheimschlüssel, der die Passphrase enthält. Erstelle beispielsweise ein neues Geheimnis mit dem Namen `LARGE_SECRET_PASSPHRASE` und setze den Wert des Geheimnisses auf die Passphrase, die Du im obigen Schritt ausgewählt hast.
|
||||
|
||||
1. Kopiere Deine verschlüsselte Datei in Dein Repository und committe sie. In diesem Beispiel ist die verschlüsselte Datei `my_secret.json.gpg`.
|
||||
|
||||
1. Erstellen Sie ein Shell-Skript, um das Passwort zu entschlüsseln. Speichern Sie diese Datei als `decrypt_secret.sh`.
|
||||
|
||||
``` shell
|
||||
|
||||
|
||||
Die Datei
|
||||
mkdir $HOME/secrets
|
||||
--batch entschlüsseln, um den interaktiven Befehl
|
||||
zu verhindern - --ja, um "Ja" für Fragen
|
||||
gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE"
|
||||
--output $HOME/secrets/my_secret.json my_secret.json.gp
|
||||
```
|
||||
|
||||
1. Stellen Sie sicher, dass Ihr Shell-Skript ausführbar ist, bevor Sie es in Ihrem Repository einchecken.
|
||||
|
||||
``` shell
|
||||
$ chmod +x decrypt_secret.sh
|
||||
$ git add decrypt_secret.sh
|
||||
$ git commit -m "Add new decryption script"
|
||||
$ git push
|
||||
```
|
||||
|
||||
1. Verwenden Sie in Ihrem Workflow einen `step`, um das Shell-Skript aufzurufen und das Geheimnis zu entschlüsseln. Um in der Umgebung, in der Dein Workflow läuft, eine Kopie Deines Projektarchivs zu haben, musst Du die Aktion [`actions/checkout`](https://github.com/actions/checkout) verwenden. Referenzieren Sie Ihr Shell-Skript mit dem Befehl `run` relativ zum Root Ihres Repositorys.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
name: Workflows with large secrets
|
||||
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
my-job:
|
||||
name: My Job
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Decrypt large secret
|
||||
run: ./.github/scripts/decrypt_secret.sh
|
||||
env:
|
||||
LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
|
||||
# Dieser Befehl ist nur ein Beispiel, um zu zeigen, dass Dein Geheimnis ausgegeben wird
|
||||
# Stelle sicher, dass Du alle Druckanweisungen Deiner Geheimnisse entfernst. Github
|
||||
# verbirgt keine Geheimnisse, die diese Umgehung verwenden.
|
||||
- name: Test printing your secret (Remove this step in production)
|
||||
run: cat $HOME/secrets/my_secret.json
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Umgebungsvariablen
|
||||
intro: '{% data variables.product.prodname_dotcom %} setzt Standard-Umgebungsvariablen für jeden {% data variables.product.prodname_actions %}-Workflow-Lauf. Du kannst auch benutzerdefinierte Umgebungsvariablen in Deiner Workflow-Datei festlegen.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/using-environment-variables
|
||||
- /actions/automating-your-workflow-with-github-actions/using-environment-variables
|
||||
- /actions/configuring-and-managing-workflows/using-environment-variables
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu Umgebungsvariablen
|
||||
|
||||
{% data variables.product.prodname_dotcom %} setzt Standard-Umgebungsvariablen, die für jeden Schritt in einem Workflow-Lauf verfügbar sind. Bei Umgebungsvariablen wird die Groß-/Kleinschreibung berücksichtigt. Befehle, die in Aktionen oder „Steps“ (Schritten) ausgeführt werden, können Umgebungsvariablen erstellen, lesen und ändern.
|
||||
|
||||
Um benutzerdefinierte Umgebungsvariablen festzulegen, musst Du die Variablen in der Workflow-Datei angeben. Du kannst Umgebungsvariablen für einen „Step“ (Schritt), Job, oder ganzen Workflow festlegen, indem Du die Schlüsselworte [`jobs.<job_id>.steps.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv), [`jobs.<job_id>.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idenv) oder [`env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) verwendest. Weitere Informationen finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_dotcom %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)“.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world
|
||||
run: echo Hello world $FIRST_NAME $middle_name $Last_Name!
|
||||
env:
|
||||
FIRST_NAME: Mona
|
||||
middle_name: The
|
||||
Last_Name: Octocat
|
||||
```
|
||||
|
||||
You can also use the {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}`GITHUB_ENV` environment file{% else %} `set-env` workflow command{% endif %} to set an environment variable that the following steps in a workflow can use. The {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}environment file{% else %} `set-env` command{% endif %} can be used directly by an action or as a shell command in a workflow file using the `run` keyword. Weitere Informationen findest Du unter „[Workflow-Befehle für {% data variables.product.prodname_actions %}](/actions/reference/workflow-commands-for-github-actions/#setting-an-environment-variable)“.
|
||||
|
||||
### Standard-Umgebungsvariablen
|
||||
|
||||
Es wird dringend empfohlen, dass Aktionen Umgebungsvariablen verwenden, um auf das Dateisystem zuzugreifen, anstatt hartcodierte Dateipfade zu verwenden. {% data variables.product.prodname_dotcom %} legt Umgebungsvariablen für Aktionen fest, die in allen Runner-Umgebungen verwendet werden sollen.
|
||||
|
||||
| Umgebungsvariable | Beschreibung |
|
||||
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `CI` | Immer auf `true` gesetzt. |
|
||||
| `HOME` | Pfad zum {% data variables.product.prodname_dotcom %}-Startverzeichnis, in dem die Benutzerdaten gespeichert werden. Beispiel: `/github/home`. |
|
||||
| `GITHUB_WORKFLOW` | Der Name des Workflows. |
|
||||
| `GITHUB_RUN_ID` | {% data reusables.github-actions.run_id_description %}
|
||||
| `GITHUB_RUN_NUMBER` | {% data reusables.github-actions.run_number_description %}
|
||||
| `GITHUB_ACTION` | Die eindeutige Kennung (`id`) der Aktion. |
|
||||
| `GITHUB_ACTIONS` | Immer auf `true` gesetzt, wenn {% data variables.product.prodname_actions %} den Workflow ausführt. Du kannst diese Variable verwenden, um zu differenzieren, wann Tests lokal oder von {% data variables.product.prodname_actions %} durchgeführt werden. |
|
||||
| `GITHUB_ACTOR` | Name der Person oder App, die den Workflow initiiert hat. Beispiel: `octocat`. |
|
||||
| `GITHUB_REPOSITORY` | Der Inhaber- und Repository-Name, Beispiel: `octocat/Hello-World`. |
|
||||
| `GITHUB_EVENT_NAME` | Name des Webhook-Ereignisses, das den Workflow ausgelöst hat. |
|
||||
| `GITHUB_EVENT_PATH` | Pfad der Datei mit der gesamten Nutzlast des Webhook-Ereignisses. Beispiel: `/github/workflow/event.json`. |
|
||||
| `GITHUB_WORKSPACE` | Pfad zum Verzeichnis der Arbeitsoberfläche von {% data variables.product.prodname_dotcom %}. The workspace directory is a copy of your repository if your workflow uses the [actions/checkout](https://github.com/actions/checkout) action. Wenn Du die Aktion `actions/checkout` nicht verwendest, ist das Verzeichnis leer. Beispiel: `/home/runner/work/my-repo-name/my-repo-name`. |
|
||||
| `GITHUB_SHA` | Commit-SHA, die den Workflow ausgelöst hat. Beispiel: `ffac537e6cbbf934b08745a378932722df287a53`. |
|
||||
| `GITHUB_REF` | Branch- oder Tag-Ref, das den Workflow ausgelöst hat. Beispiel: `refs/heads/feature-branch-1`. Wenn für den Ereignistyp weder ein Branch noch ein Tag vorliegt, ist die Variable nicht vorhanden. |
|
||||
| `GITHUB_HEAD_REF` | Nur für geforkte Repositorys festgelegt. Der Branch des Head-Repositorys. |
|
||||
| `GITHUB_BASE_REF` | Nur für geforkte Repositorys festgelegt. Der Branch des Basis-Repositorys. |
|
||||
| `GITHUB_SERVER_URL` | Returns the URL of the {% data variables.product.product_name %} server. For example: `https://github.com`. |
|
||||
| `GITHUB_API_URL` | Gibt die API-URL zurück. For example: `https://api.github.com`. |
|
||||
| `GITHUB_GRAPHQL_URL` | Gibt die GraphQL-API-URL zurück. For example: `https://api.github.com/graphql`. |
|
||||
|
||||
### Namens-Konventionen für Umgebungsvariablen
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** In {% data variables.product.prodname_dotcom %} ist das Umgebungsvariablen-Präfix `GITHUB_` für den internen Gebrauch durch {% data variables.product.prodname_dotcom %} reserviert. Wenn Sie eine Umgebungsvariable oder ein Geheimnis mit dem Präfix `GITHUB_` anlegen, tritt ein Fehler auf.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Alle neuen Umgebungsvariablen, die auf einen Speicherort im Dateisystem verweisen, müssen das Suffix `_PATH` erhalten. Die Standardvariablen `HOME` und `GITHUB_WORKSPACE` sind von dieser Konvention ausgenommen, da die Bezeichnungen „home“ und „workspace“ bereits einen Speicherort implizieren.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 'Ereignisse, die Workflows auslösen'
|
||||
intro: 'Du kannst Deine Workflows so konfigurieren, dass sie zu einem geplanten Zeitpunkt ausgeführt werden oder dann, wenn eine bestimmte Aktivität auf {% data variables.product.product_name %} stattfindet oder ein Ereignis außerhalb von {% data variables.product.product_name %} eintrifft.'
|
||||
title: Ereignisse, die Workflows auslösen
|
||||
intro: 'Sie können konfigurieren, dass Ihre Workflows zu einem geplanten Zeitpunkt ausgeführt werden oder dann, wenn eine bestimmte Aktivität auf {% data variables.product.product_name %} stattfindet oder ein Ereignis außerhalb von {% data variables.product.product_name %} auftritt.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
miniTocMaxHeadingLevel: 4
|
||||
redirect_from:
|
||||
@@ -15,19 +15,11 @@ versions:
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu Workflow-Ereignissen
|
||||
### Configuring workflow events
|
||||
|
||||
Sie können Ihren Workflow so konfigurieren, dass er ausgeführt wird, wenn Webhook-Ereignisse anhand von Aktivitäten auf {% data variables.product.product_name %} erstellt werden. Workflows können mehrere Webhook-Ereignisse verwenden, um einen Workflow-Lauf auszulösen. For more information, see "[Webhooks](/webhooks)." Weitere Informationen zur Syntax für `on` finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#on)“.
|
||||
You can configure workflows to run for one or more events using the `on` workflow syntax. Weitere Informationen finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#on)“.
|
||||
|
||||
Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:
|
||||
|
||||
1. In Deinem Repository tritt ein Ereignis auf und zum dem daraus resultierenden Webhook gehören ein Commit-SHA und eine Git Ref.
|
||||
1. Das Verzeichnis `.github/workflows` in Deinem Repository wird nach Workflow-Dateien des zugehörigen Commit-SHA oder der zugehörigen Git Ref durchsucht. Die Workflow-Dateien müssen in diesem Commit-SHA oder dieser Git Ref vorhanden sein, um berücksichtigt zu werden.
|
||||
|
||||
Wenn zum Beispiel das Ereignis in einem bestimmten Repository-Zweig aufgetreten ist, müssen die Workflow-Dateien im Repository dieses Zweiges vorhanden sein.
|
||||
1. Die Workflow-Dateien für diesen Commit-SHA und diese Git Ref werden überprüft und für alle Workflows, deren `on:`-Werte zu dem auslösenden Ereignis passen, wird ein neuer Workflow-Lauf angestoßen.
|
||||
|
||||
Der Workflow läuft auf dem Code Deines Repositorys mit dem selben Commit-SHA und derselben Git Ref wie das auslösende Ereignis. Wenn ein Workflow läuft, setzt {% data variables.product.product_name %} die Umgebungsvariablen `GITHUB_SHA` (Commit-SHA) und `GITHUB_REF` (Git Ref) in der Umgebung auf dem Runner. Weitere Informationen findest Du unter „[Umgebungsvariablen verwenden](/actions/automating-your-workflow-with-github-actions/using-environment-variables)“.
|
||||
{% data reusables.github-actions.actions-on-examples %}
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -35,11 +27,130 @@ Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.github-actions.actions-on-examples %}
|
||||
Die folgenden Schritte laufen ab, um einen Workflow-Lauf auszulösen:
|
||||
|
||||
1. An event occurs on your repository, and the resulting event has an associated commit SHA and Git ref.
|
||||
2. Das Verzeichnis `.github/workflows` in Deinem Repository wird nach Workflow-Dateien des zugehörigen Commit-SHA oder der zugehörigen Git Ref durchsucht. Die Workflow-Dateien müssen in diesem Commit-SHA oder dieser Git Ref vorhanden sein, um berücksichtigt zu werden.
|
||||
|
||||
Wenn zum Beispiel das Ereignis in einem bestimmten Repository-Zweig aufgetreten ist, müssen die Workflow-Dateien im Repository dieses Zweiges vorhanden sein.
|
||||
1. Die Workflow-Dateien für diesen Commit-SHA und diese Git Ref werden überprüft und für alle Workflows, deren `on:`-Werte zu dem auslösenden Ereignis passen, wird ein neuer Workflow-Lauf angestoßen.
|
||||
|
||||
Der Workflow läuft auf dem Code Deines Repositorys mit dem selben Commit-SHA und derselben Git Ref wie das auslösende Ereignis. Wenn ein Workflow läuft, setzt {% data variables.product.product_name %} die Umgebungsvariablen `GITHUB_SHA` (Commit-SHA) und `GITHUB_REF` (Git Ref) in der Umgebung auf dem Runner. Weitere Informationen findest Du unter „[Umgebungsvariablen verwenden](/actions/automating-your-workflow-with-github-actions/using-environment-variables)“.
|
||||
|
||||
### Geplante Ereignisse
|
||||
|
||||
The `schedule` event allows you to trigger a workflow at a scheduled time.
|
||||
|
||||
#### `Zeitplan`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| -------------------------------- | --------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| – | – | Letzter Commit im Standard-Branch | Standardbranch | Zeitpunkt, zu dem der geplante Workflow ausgeführt werden soll. Für einen geplanten Workflow gilt die [POSIX-Cron-Syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). Weitere Informationen finden Sie unter „[Einen Workflow mit Ereignissen auslösen](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)“. |
|
||||
|
||||
{% data reusables.repositories.actions-scheduled-workflow-example %}
|
||||
|
||||
Die Cron-Syntax umfasst fünf durch Leerzeichen getrennte Felder, die jeweils eine Zeiteinheit darstellen.
|
||||
|
||||
```
|
||||
┌───────────── Minute (0–59)
|
||||
│ ┌───────────── Stunde (0–23)
|
||||
│ │ ┌───────────── Tag (1–31)
|
||||
│ │ │ ┌───────────── Monat (1–12 oder JAN–DEZ)
|
||||
│ │ │ │ ┌───────────── Wochentag (0–6 oder SON–SAM)
|
||||
│ │ │ │ │
|
||||
│ │ │ │ │
|
||||
│ │ │ │ │
|
||||
* * * * *
|
||||
```
|
||||
|
||||
In den fünf Feldern stehen die folgenden Operatoren zur Auswahl:
|
||||
|
||||
| Operator | Beschreibung | Beispiel |
|
||||
| -------- | -------------------------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| * | Beliebiger Wert | `* * * * *` wird jeden Tag jede Minute ausgeführt. |
|
||||
| , | Trennzeichen in Werteliste | `2,10 4,5 * * *` wird jeden Tag bei Minute 2 und 10 der 4. und 5. Stunde ausgeführt. |
|
||||
| - | Wertebereich | `0 4-6 * * *` wird bei Minute 0 der 4., 5. und 6. Stunde ausgeführt. |
|
||||
| / | Schrittwerte | `20/15 * * * *` wird alle 15 Minuten ausgeführt, von Minute 20 bis Minute 59 (also bei Minute 20, 35 und 50). |
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** {% data variables.product.prodname_actions %} bietet keine Unterstützung für die nicht standardmäßige Syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly` und `@reboot`.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Mit [crontab guru](https://crontab.guru/) können Sie die Cron-Syntax erzeugen und den Ausführungszeitpunkt bestätigen. Als Einstiegshilfe steht eine Liste mit [crontab-guru-Beispielen](https://crontab.guru/examples.html) bereit.
|
||||
|
||||
### Manual events
|
||||
|
||||
You can manually trigger workflow runs. To trigger specific workflows in a repository, use the `workflow_dispatch` event. To trigger more than one workflow in a repository and create custom events and event types, use the `repository_dispatch` event.
|
||||
|
||||
#### `workflow_dispatch`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------------------------- | --------------- | ------------------------------------- | -------------------------------------- |
|
||||
| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | – | Letzter Commit im Branch `GITHUB_REF` | Branch, der den Dispatch empfangen hat |
|
||||
|
||||
You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. Wenn der Workflow ausgeführt wird, können Sie auf die Eingabewerte im `github.event.inputs` Kontextzugreifen. Weitere Informationen findest Du unter "[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
|
||||
You can manually trigger a workflow run using the {% data variables.product.prodname_dotcom %} API and from {% data variables.product.prodname_dotcom %}. For more information, see "[Manually running a workflow](/actions/managing-workflow-runs/manually-running-a-workflow)."
|
||||
|
||||
When you trigger the event on {% data variables.product.prodname_dotcom %}, you can provide the `ref` and any `inputs` directly on {% data variables.product.prodname_dotcom %}. For more information, see "[Using inputs and outputs with an action](/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)."
|
||||
|
||||
To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% data variables.product.prodname_dotcom %} API endpoint and provide the `ref` and any required `inputs`. For more information, see the "[Create a workflow dispatch event](/rest/reference/actions/#create-a-workflow-dispatch-event)" REST API endpoint.
|
||||
|
||||
##### Example workflow configuration
|
||||
|
||||
In diesem Beispiel wird der `Name` definiert und</code> ein- und `zu Hause verwendet, und sie werden mit den Kontexten <code>github.event.inputs.name` und `github.event.inputs.home` gedruckt. Wenn ein `Name` nicht angegeben wird, wird der Standardwert 'Mona the Octocat' gedruckt.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
Name: Manuell ausgelöster Workflow
|
||||
auf:
|
||||
workflow_dispatch:
|
||||
Eingaben:
|
||||
Name:
|
||||
Beschreibung: 'Person zu grüßen'
|
||||
erforderlich: true
|
||||
Standard: 'Mona the Octocat'
|
||||
Home:
|
||||
Beschreibung: 'Standort'
|
||||
erforderlich: falsche
|
||||
|
||||
Jobs:
|
||||
say_hello:
|
||||
läuft auf: ubuntu-latest
|
||||
Schritte:
|
||||
- laufen: |
|
||||
Echo "Hallo{{ github.event.inputs.name }}!"
|
||||
echo "- in{{ github.event.inputs.home }}!"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `repository_dispatch`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| -------------------------------------------------------------------- | --------------- | ------------------------------------- | -------------------------------------- |
|
||||
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | – | Letzter Commit im Branch `GITHUB_REF` | Branch, der den Dispatch empfangen hat |
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
Mit der {% data variables.product.product_name %}-API können Sie das Webhook-Ereignis [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) auslösen, wenn ein Workflow für eine Aktivität ausgelöst werden soll, die außerhalb von {% data variables.product.prodname_dotcom %} abläuft. Weitere Informationen finden Sie unter "[Erstellen eines Repository-Dispatchereignisses](/v3/repos/#create-a-repository-dispatch-event)."
|
||||
|
||||
Soll das benutzerdefinierte Webhook-Ereignis `repository_dispatch` ausgelöst werden, senden Sie eine `POST`-Anfrage an einen {% data variables.product.product_name %}-API-Endpunkt, und geben Sie den Namen für einen `event_type` als Beschreibung für den Aktivitätstyp an. Soll ein Workflow-Lauf ausgelöst werden, konfigurieren Sie außerdem den Workflow für die Verwendung des Ereignisses `repository_dispatch`.
|
||||
|
||||
##### Beispiel
|
||||
|
||||
Standardmäßig lösen alle `event_types` einen Workflow aus. Du kannst Deinen Workflow darauf beschränken, zu laufen, wenn ein bestimmter Wert als `event_type` in der Webhoo-Nutzlast des `repository_dispatch` gesendet wird. Du definierst die Ereignistypen, die in der Nutzlast des `repository_dispatch` gesendet werden, wenn Du das Repositorydispatch-Ereignis erstellst.
|
||||
|
||||
```yaml
|
||||
on:
|
||||
repository_dispatch:
|
||||
types: [opened, deleted]
|
||||
```
|
||||
|
||||
### Webhook-Ereignisse
|
||||
|
||||
Du kannst Deinen Workflow so konfigurieren, dass er ausgeführt wird, sobald Webhook-Ereignisse in GitHub erstellt werden. Einige Ereignisse werden von mehreren Aktivitätstypen ausgelöst. Wird ein Ereignis von mehreren Aktivitätstypen ausgelöst, können Sie die Aktivitätstypen angeben, die die Ausführung des Workflows auslösen sollen.
|
||||
Du kannst Deinen Workflow so konfigurieren, dass er ausgeführt wird, sobald Webhook-Ereignisse in GitHub erstellt werden. Einige Ereignisse werden von mehreren Aktivitätstypen ausgelöst. Wird ein Ereignis von mehreren Aktivitätstypen ausgelöst, können Sie die Aktivitätstypen angeben, die die Ausführung des Workflows auslösen sollen. For more information, see "[Webhooks](/webhooks)."
|
||||
|
||||
#### `check_run`
|
||||
|
||||
@@ -121,7 +232,7 @@ on:
|
||||
|
||||
#### `deployment`
|
||||
|
||||
Führt den Workflow aus, wenn ein Benutzer eine Bereitstellung erstellt, wodurch das Ereignis `deployment` ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "[Deployments](/v3/repos/deployments/)."
|
||||
Führt den Workflow aus, wenn ein Benutzer eine Bereitstellung erstellt, wodurch das Ereignis `deployment` ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "[Deployments](/rest/reference/repos#deployments)."
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------------- | --------------- | ------------------------- | ---------------------------------------------------- |
|
||||
@@ -136,7 +247,7 @@ on:
|
||||
|
||||
#### `deployment_status`
|
||||
|
||||
Führt den Workflow aus, wenn ein Dritter einen Bereitstellungsstatus angibt, wodurch das Ereignis `deployment_status` ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "[Create a deployment status](/v3/repos/deployments/#create-a-deployment-status)."
|
||||
Führt den Workflow aus, wenn ein Dritter einen Bereitstellungsstatus angibt, wodurch das Ereignis `deployment_status` ausgelöst wird. Bereitstellungen, die mit einer Commit-SHA erstellt wurden, umfassen ggf. keinen Git-Ref. For information about the REST API, see "[Create a deployment status](/rest/reference/repos#create-a-deployment-status)."
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ------------------------------------------------------------------ | --------------- | ------------------------- | ---------------------------------------------------- |
|
||||
@@ -185,13 +296,13 @@ on:
|
||||
|
||||
#### `issue_comment`
|
||||
|
||||
Führt den Workflow aus, wenn das Ereignis `issue_comment` eintritt. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issue comments](/v3/issues/comments/)."
|
||||
Führt den Workflow aus, wenn das Ereignis `issue_comment` eintritt. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Issue comments](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment)."
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------- | --------------- |
|
||||
| [`issue_comment`](/v3/activity/event_types/#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Letzter Commit im Standard-Branch | Standard-Branch |
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| --------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------- | --------------- |
|
||||
| [`issue_comment`](/rest/reference/activity#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Letzter Commit im Standard-Branch | Standard-Branch |
|
||||
|
||||
{% data reusables.developer-site.limit_workflow_to_activity_types %}
|
||||
|
||||
@@ -265,7 +376,7 @@ on:
|
||||
|
||||
#### `page_build`
|
||||
|
||||
Führt den Workflow aus, wenn ein Benutzer einen Push an einen {% data variables.product.product_name %}-Pages-fähigen Branch vornimmt, wodurch das Ereignis `page_build` ausgelöst wird. For information about the REST API, see "[Pages](/v3/repos/pages/)."
|
||||
Führt den Workflow aus, wenn ein Benutzer einen Push an einen {% data variables.product.product_name %}-Pages-fähigen Branch vornimmt, wodurch das Ereignis `page_build` ausgelöst wird. For information about the REST API, see "[Pages](/rest/reference/repos#pages)."
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
@@ -489,9 +600,9 @@ on:
|
||||
|
||||
Führt den Workflow aus, wenn das Ereignis `release` eintritt. {% data reusables.developer-site.multiple_activity_types %} For information about the REST API, see "[Releases](/v3/repos/releases/)."
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | --------------------- |
|
||||
| [`Release`](/webhooks/event-payloads/#release) | - `published`{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.18" %} <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released`{% endif %} | Letzter Commit in der Tag-Veröffentlichung | Veröffentlichungs-Tag |
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | --------------------- |
|
||||
| [`Release`](/webhooks/event-payloads/#release) | - `published` <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released` | Letzter Commit in der Tag-Veröffentlichung | Veröffentlichungs-Tag |
|
||||
|
||||
{% data reusables.developer-site.limit_workflow_to_activity_types %}
|
||||
|
||||
@@ -558,85 +669,6 @@ on:
|
||||
- requested
|
||||
```
|
||||
|
||||
### Geplante Ereignisse
|
||||
|
||||
The `schedule` event allows you to trigger a workflow at a scheduled time.
|
||||
|
||||
#### `Zeitplan`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| -------------------------------- | --------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| – | – | Letzter Commit im Standard-Branch | Standardbranch | Zeitpunkt, zu dem der geplante Workflow ausgeführt werden soll. Für einen geplanten Workflow gilt die [POSIX-Cron-Syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). Weitere Informationen finden Sie unter „[Einen Workflow mit Ereignissen auslösen](/articles/configuring-a-workflow/#triggering-a-workflow-with-events)“. |
|
||||
|
||||
{% data reusables.repositories.actions-scheduled-workflow-example %}
|
||||
|
||||
Die Cron-Syntax umfasst fünf durch Leerzeichen getrennte Felder, die jeweils eine Zeiteinheit darstellen.
|
||||
|
||||
```
|
||||
┌───────────── Minute (0–59)
|
||||
│ ┌───────────── Stunde (0–23)
|
||||
│ │ ┌───────────── Tag (1–31)
|
||||
│ │ │ ┌───────────── Monat (1–12 oder JAN–DEZ)
|
||||
│ │ │ │ ┌───────────── Wochentag (0–6 oder SON–SAM)
|
||||
│ │ │ │ │
|
||||
│ │ │ │ │
|
||||
│ │ │ │ │
|
||||
* * * * *
|
||||
```
|
||||
|
||||
In den fünf Feldern stehen die folgenden Operatoren zur Auswahl:
|
||||
|
||||
| Operator | Beschreibung | Beispiel |
|
||||
| -------- | -------------------------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| * | Beliebiger Wert | `* * * * *` wird jeden Tag jede Minute ausgeführt. |
|
||||
| , | Trennzeichen in Werteliste | `2,10 4,5 * * *` wird jeden Tag bei Minute 2 und 10 der 4. und 5. Stunde ausgeführt. |
|
||||
| - | Wertebereich | `0 4-6 * * *` wird bei Minute 0 der 4., 5. und 6. Stunde ausgeführt. |
|
||||
| / | Schrittwerte | `20/15 * * * *` wird alle 15 Minuten ausgeführt, von Minute 20 bis Minute 59 (also bei Minute 20, 35 und 50). |
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** {% data variables.product.prodname_actions %} bietet keine Unterstützung für die nicht standardmäßige Syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly` und `@reboot`.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Mit [crontab guru](https://crontab.guru/) können Sie die Cron-Syntax erzeugen und den Ausführungszeitpunkt bestätigen. Als Einstiegshilfe steht eine Liste mit [crontab-guru-Beispielen](https://crontab.guru/examples.html) bereit.
|
||||
|
||||
### Manual events
|
||||
|
||||
You can manually trigger workflow runs. To trigger specific workflows in a repository, use the `workflow_dispatch` event. To trigger more than one workflow in a repository and create custom events and event types, use the `repository_dispatch` event.
|
||||
|
||||
#### `workflow_dispatch`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ---------------------------------------------------------------- | --------------- | ------------------------------------- | -------------------------------------- |
|
||||
| [workflow_dispatch](/webhooks/event-payloads/#workflow_dispatch) | – | Letzter Commit im Branch `GITHUB_REF` | Branch, der den Dispatch empfangen hat |
|
||||
|
||||
You can manually trigger a workflow run using the {% data variables.product.prodname_dotcom %} API and from {% data variables.product.prodname_dotcom %}. To trigger the custom `workflow_dispatch` webhook event using the REST API, you must send a `POST` request to a {% data variables.product.prodname_dotcom %} API endpoint and provide the `ref` and any required `inputs`. For more information, see the "[Create a workflow dispatch event](/rest/reference/actions/#create-a-workflow-dispatch-event)" REST API endpoint.
|
||||
|
||||
When you trigger the event on {% data variables.product.prodname_dotcom %}, you can provide the `ref` and any `inputs` directly on {% data variables.product.prodname_dotcom %}. Weitere Informationen findest Du unter „[Einen Workflow konfigurieren](/actions/configuring-and-managing-workflows/configuring-a-workflow#manually-running-a-workflow)“.
|
||||
|
||||
#### `repository_dispatch`
|
||||
|
||||
| Nutzlast des Webhook-Ereignisses | Aktivitätstypen | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| -------------------------------------------------------------------- | --------------- | ------------------------------------- | -------------------------------------- |
|
||||
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | – | Letzter Commit im Branch `GITHUB_REF` | Branch, der den Dispatch empfangen hat |
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
Mit der {% data variables.product.product_name %}-API können Sie das Webhook-Ereignis [`repository_dispatch`](/webhooks/event-payloads/#repository_dispatch) auslösen, wenn ein Workflow für eine Aktivität ausgelöst werden soll, die außerhalb von {% data variables.product.prodname_dotcom %} abläuft. Weitere Informationen finden Sie unter "[Erstellen eines Repository-Dispatchereignisses](/v3/repos/#create-a-repository-dispatch-event)."
|
||||
|
||||
Soll das benutzerdefinierte Webhook-Ereignis `repository_dispatch` ausgelöst werden, senden Sie eine `POST`-Anfrage an einen {% data variables.product.product_name %}-API-Endpunkt, und geben Sie den Namen für einen `event_type` als Beschreibung für den Aktivitätstyp an. Soll ein Workflow-Lauf ausgelöst werden, konfigurieren Sie außerdem den Workflow für die Verwendung des Ereignisses `repository_dispatch`.
|
||||
|
||||
##### Beispiel
|
||||
|
||||
Standardmäßig lösen alle `event_types` einen Workflow aus. Du kannst Deinen Workflow darauf beschränken, zu laufen, wenn ein bestimmter Wert als `event_type` in der Webhoo-Nutzlast des `repository_dispatch` gesendet wird. Du definierst die Ereignistypen, die in der Nutzlast des `repository_dispatch` gesendet werden, wenn Du das Repositorydispatch-Ereignis erstellst.
|
||||
|
||||
```yaml
|
||||
on:
|
||||
repository_dispatch:
|
||||
types: [opened, deleted]
|
||||
```
|
||||
|
||||
### Neue Workflows mit einem persönlichen Zugangs-Token auslösen
|
||||
|
||||
{% data reusables.github-actions.actions-do-not-trigger-workflows %} weitere Informationen findest Du unter „[Authentifizierung mit dem GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)“.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Referenz
|
||||
intro: 'Referenzdokumentation zum Bauen von Aktionen, zum Erstellen von Workflows und zu anderen Tools sowie weitere Informationen zu {% data variables.product.prodname_actions %}.'
|
||||
intro: 'Reference documentation for creating workflows, using GitHub-hosted runners, and authentication.'
|
||||
redirect_from:
|
||||
- /actions/configuring-and-managing-workflows/using-variables-and-secrets-in-a-workflow
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
@@ -9,9 +11,39 @@ versions:
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Syntax für Workflows
|
||||
|
||||
The workflow file is written in YAML. In the YAML workflow file, you can use expression syntax to evaluate contextual information, literals, operators, and functions. Contextual information includes workflow, environment variables, secrets, and the events that triggered the workflow. When you use [`run`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun) in a workflow step to run shell commands, you can use specific workflow command syntax to set environment variables, set output parameters for subsequent steps, and set error or debug messages.
|
||||
|
||||
{% link_in_list /workflow-syntax-for-github-actions %}
|
||||
{% link_in_list /events-that-trigger-workflows %}
|
||||
{% link_in_list /context-and-expression-syntax-for-github-actions %}
|
||||
{% link_in_list /workflow-commands-for-github-actions %}
|
||||
{% link_in_list /virtual-environments-for-github-hosted-runners %}
|
||||
{% link_in_list /software-installed-on-github-hosted-runners %}
|
||||
|
||||
### Ereignisse
|
||||
|
||||
You can configure workflows to run when specific GitHub events occur, at a scheduled time, manually, or when events outside of GitHub occur.
|
||||
|
||||
{% link_in_list /events-that-trigger-workflows %}
|
||||
|
||||
### Authentication and secrets
|
||||
|
||||
{% data variables.product.prodname_dotcom %} stellt ein Token zur Verfügung, mit dem Du Dich im Namen von {% data variables.product.prodname_actions %} authentifizieren kannst. You can also store sensitive information as a secret in your organization or repository. {% data variables.product.prodname_dotcom %} encrypts all secrets.
|
||||
|
||||
{% link_in_list /authentication-in-a-workflow %}
|
||||
{% link_in_list /encrypted-secrets %}
|
||||
|
||||
### {% data variables.product.prodname_dotcom %}-gehostete Runner
|
||||
|
||||
GitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment with tools, packages, and environment variables for GitHub Actions to use.
|
||||
|
||||
{% link_in_list /environment-variables %}
|
||||
{% link_in_list /specifications-for-github-hosted-runners %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
### Administration
|
||||
|
||||
When you run workflows on {% data variables.product.prodname_dotcom %}-hosted runners, there are usage limits and potential usage charges. You can also disable or restrict the usage of {% data variables.product.prodname_actions %} in a repository and organization.
|
||||
|
||||
{% link_in_list /usage-limits-billing-and-administration %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: Specifications for GitHub-hosted runners
|
||||
intro: '{% data variables.product.prodname_dotcom %} bietet gehostete virtuelle Maschinen, um Workflows auszuführen. Die virtuelle Maschine umfasst eine Umgebung mit Tools, Paketen und Einstellungen für {% data variables.product.prodname_actions %}.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/virtual-environments-for-github-actions
|
||||
- /github/automating-your-workflow-with-github-actions/virtual-environments-for-github-actions
|
||||
- /github/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners
|
||||
- /actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners
|
||||
- /actions/reference/virtual-environments-for-github-hosted-runners
|
||||
- /actions/reference/software-installed-on-github-hosted-runners
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zu {% data variables.product.prodname_dotcom %}-gehosteten Runnern
|
||||
|
||||
Ein {% data variables.product.prodname_dotcom %}-gehosteter Runner ist eine virtuelle Maschine, die von {% data variables.product.prodname_dotcom %} gehostet wird und auf der die Runner-Anwendung der {% data variables.product.prodname_actions %} installiert ist. {% data variables.product.prodname_dotcom %} bietet Runner mit den Betriebssystemen Linux, Windows und MacOS.
|
||||
|
||||
Wenn Du einen {% data variables.product.prodname_dotcom %}-gehosteten Runner verwendest, werden Wartung und Upgrade der Maschine für Dich erledigt. Sie können Workflows direkt auf der virtuellen Maschine oder in einem Docker-Container ausführen.
|
||||
|
||||
Du kannst in einem Workflow für jeden Job die Art des Runners festlegen. Jeder Job in einem Workflow wird in einer neuen Instanz der virtuellen Maschine ausgeführt. Alle Schritte des Jobs werden in derselben Instanz der virtuellen Maschine ausgeführt, sodass die Aktionen in diesem Job über das Dateisystem Informationen austauschen können.
|
||||
|
||||
{% data reusables.github-actions.runner-app-open-source %}
|
||||
|
||||
#### Cloud-Hosts für {% data variables.product.prodname_dotcom %}-gehostete Runner
|
||||
|
||||
{% data variables.product.prodname_dotcom %} betreibt Linux- und Windows-Runner auf den virtuellen Maschinen nach Standard_DS2_v2 in Microsoft Azure, auf denen die Runner-Anwendung der {% data variables.product.prodname_actions %} installiert ist. Die Runner-Anwendung auf {% data variables.product.prodname_dotcom %}-gehosteten Runnern ist eine Fork-Kopie des Azure-Pipelines-Agenten. Bei Azure werden eingehende ICMP-Pakete werden für alle virtuellen Maschinen blockiert, so dass die Befehle ping und traceroute möglicherweise nicht funktionieren. Weitere Informationen zu den Ressourcen der Standard_DS2_v2-Maschinen findest Du unter „[Serien Dv2 und DSv2](https://docs.microsoft.com/en-us/azure/virtual-machines/dv2-dsv2-series#dsv2-series)“ in der Dokumentation zu Microsoft Azure.
|
||||
|
||||
{% data variables.product.prodname_dotcom %} verwendet [MacStadium](https://www.macstadium.com/), um die virtuellen macOS-Runner zu betreiben.
|
||||
|
||||
#### Administrative Rechte von {% data variables.product.prodname_dotcom %}-gehosteten Runnern
|
||||
|
||||
Die virtuellen Maschinen unter Linux und macOS werden beide mit dem passwortlosen Befehl `sudo` ausgeführt. Wenn Sie Befehle ausführen oder Tools installieren müssen, die höhere Berechtigungen als der aktuelle Benutzer erfordern, können Sie `sudo` verwenden, ohne ein Passwort angeben zu müssen. Weitere Informationen findest Du im „[Sudo-Handbuch](https://www.sudo.ws/man/1.8.27/sudo.man.html)“.
|
||||
|
||||
Die virtuellen Windows-Maschinen sind so konfiguriert, dass sie als Administratoren laufen, wobei die Benutzerkonten-Steuerung (UAC) deaktiviert ist. Weitere Informationen findest Du unter „[Funktionsweise der Benutzerkonten-Steuerung](https://docs.microsoft.com/de-de/windows/security/identity-protection/user-account-control/how-user-account-control-works)“ in der Dokumentation zu Windows.
|
||||
|
||||
### Unterstützte Runner und Hardwareressourcen
|
||||
|
||||
Für jede virtuelle Maschine stehen die gleichen Hardware-Ressourcen zur Verfügung.
|
||||
|
||||
- CPU mit 2 Kernen
|
||||
- 7 GB RAM-Speicher
|
||||
- 14 GB SSD-Festplattenspeicher
|
||||
|
||||
{% data reusables.github-actions.supported-github-runners %}
|
||||
|
||||
{% data reusables.github-actions.ubuntu-runner-preview %}
|
||||
|
||||
Workflow logs list the runner used to run a job. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
|
||||
|
||||
### Supported software
|
||||
|
||||
The software tools included in {% data variables.product.prodname_dotcom %}-hosted runners are updated weekly. Die neueste Liste der mitgelieferten Werkzeuge für jedes Runner-Betriebssystem findest Du unter den folgenden Links:
|
||||
|
||||
* [Ubuntu 20.04 LTS](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md)
|
||||
* [Ubuntu 18.04 LTS](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu1804-README.md)
|
||||
* [Ubuntu 16.04 LTS](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu1604-README.md)
|
||||
* [Windows Server 2019](https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md)
|
||||
* [Windows Server 2016](https://github.com/actions/virtual-environments/blob/main/images/win/Windows2016-Readme.md)
|
||||
* [MacOS 10.15](https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md)
|
||||
|
||||
{% data reusables.github-actions.ubuntu-runner-preview %}
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-gehostete Runner enthalten zusätzlich zu den oben aufgeführten Paketen die standardmäßig integrierten Tools des Betriebssystems. Zum Beispiel beinhalten Ubuntu und macOS Läufer `grep`, `find`, und `which` neben anderen Standard-Tools.
|
||||
|
||||
Workflow logs include a link to the preinstalled tools on the runner. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
|
||||
|
||||
Wenn Sie ein bestimmtes Tool anfordern möchten, öffnen Sie bitte einen Issue unter [actions/virtual-environments](https://github.com/actions/virtual-environments).
|
||||
|
||||
### IP addresses
|
||||
|
||||
{% note %}
|
||||
|
||||
**Notiz:** Wenn Du eine Liste mit erlaubten IP-Adressen für Dein Organisations- oder Unternehmenskonto auf {% data variables.product.prodname_dotcom %} verwendest, kannst Du keine {% data variables.product.prodname_dotcom %}-gehosteten Runner verwenden, sondern benötigst stattdessen selbst-gehostete Runner. Weitere Informationen findest Du unter „[Informationen zu selbst-gehosteten Runnern](/actions/hosting-your-own-runners/about-self-hosted-runners)“.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Windows- und Ubuntu-Runner werden in Azure gehostet und haben die gleichen IP-Adressbereiche wie Azure-Rechenzentren. Derzeit befinden sich alle {% data variables.product.prodname_dotcom %}-gehosteten Windows- und Ubuntu-Runner in den folgenden Azure-Regionen:
|
||||
|
||||
- Ost-USA (`eastus`)
|
||||
- Ost-USA 2 (`eastus`)
|
||||
- West-US 2 (`westus2`)
|
||||
- Zentral-USA (`centralus`)
|
||||
- Süd-Zentral-USA (`southcentralus`)
|
||||
|
||||
Microsoft aktualisiert die Azure-IP-Adressbereiche wöchentlich in einer JSON-Datei. Diese können Sie auf der Website [Azure IP Ranges and Service Tags - Public Cloud](https://www.microsoft.com/en-us/download/details.aspx?id=56519) herunterladen. Sie können diesen IP-Adressbereich verwenden, falls Sie eine Positivliste vorschreiben, um den nicht autorisierten Zugriff auf Ihre internen Ressourcen zu verhindern.
|
||||
|
||||
Die JSON-Datei enthält einen Array mit der Bezeichnung `values`. Innerhalb dieses Arrays findest Du die unterstützten IP-Adressen in einem Objekt mit `name` und `id` der Azure-Region, z.B. `"AzureCloud.eastus2"`.
|
||||
|
||||
Die unterstützten IP-Adressbereiche befinden sich im Objekt `"addressPrefixes"`. Dies ist ein komprimiertes Beispiel der JSON-Datei.
|
||||
|
||||
```json
|
||||
{
|
||||
"changeNumber": 84,
|
||||
"cloud": "Public",
|
||||
"values": [
|
||||
{
|
||||
"name": "AzureCloud.eastus2",
|
||||
"id": "AzureCloud.eastus2",
|
||||
"properties": {
|
||||
"changeNumber": 33,
|
||||
"region": "eastus2",
|
||||
"platform": "Azure",
|
||||
"systemService": "",
|
||||
"addressPrefixes": [
|
||||
"13.68.0.0/17",
|
||||
"13.77.64.0/18",
|
||||
"13.104.147.0/25",
|
||||
...
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### File systems
|
||||
|
||||
{% data variables.product.prodname_dotcom %} führt Aktionen und Shell-Befehle in bestimmten Verzeichnissen auf der virtuellen Maschine aus. Die Dateipfade auf virtuellen Maschinen sind nicht statisch. Verwende die von {% data variables.product.prodname_dotcom %} bereitgestellten Umgebungsvariablen zum Erstellen von Dateipfaden für die Verzeichnisse `home`, `workspace`und `workflow`.
|
||||
|
||||
| Verzeichnis | Umgebungsvariable | Beschreibung |
|
||||
| --------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `home` | `HOME` | Enthält benutzerbezogene Daten. In diesem Verzeichnis können sich beispielsweise die Anmeldeinformation aus einem Anmeldeversuch befinden. |
|
||||
| `workspace` | `GITHUB_WORKSPACE` | Aktionen und Shell-Befehle werden in diesem Verzeichnis ausgeführt. Eine Aktion kann den Inhalt dieses Verzeichnisses ändern, auf den dann nachfolgende Aktionen zugreifen können. |
|
||||
| `workflow/event.json` | `GITHUB_EVENT_PATH` | Die `POST`-Nutzlast des Webhook-Ereignisses, das den Workflow ausgelöst hat. {% data variables.product.prodname_dotcom %} schreibt dies bei jeder ausgeführten Aktion neu, sodass der Dateiinhalt zwischen den Aktionen isoliert wird. |
|
||||
|
||||
Eine Liste der von {% data variables.product.prodname_dotcom %} für jeden Workflow erstellten Umgebungsvariablen findest Du unter „[Umgebungsvariablen verwenden](/github/automating-your-workflow-with-github-actions/using-environment-variables)“.
|
||||
|
||||
#### Docker-Container-Dateisystem
|
||||
|
||||
Für Aktionen, die in Docker-Containern ausgeführt werden, befinden sich statische Verzeichnisse im Pfad `/github`. Wir empfehlen jedoch dringend, die Standard-Umgebungsvariablen zu verwenden, um Dateipfade in Docker-Containern zu erstellen.
|
||||
|
||||
In {% data variables.product.prodname_dotcom %} wird das Pfadpräfix `/github` reserviert, und es werden drei Verzeichnisse für Aktionen erstellt.
|
||||
|
||||
- `/github/home`
|
||||
- `/github/workspace` - {% data reusables.repositories.action-root-user-required %}
|
||||
- `/github/workflow`
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
### Weiterführende Informationen
|
||||
- „[Abrechnung für {{ site.data.variables.product.prodname_actions }} verwalten](/github/setting-up-and-managing-billing-and-payments-on-github/managing-billing-for-github-actions)“
|
||||
|
||||
{% endif %}
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: 'Usage limits, billing, and administration'
|
||||
intro: 'There are usage limits for {% data variables.product.prodname_actions %} workflows. Usage charges apply to repositories that go beyond the amount of free minutes and storage for a repository.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /actions/getting-started-with-github-actions/usage-and-billing-information-for-github-actions
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### Informationen zur Abrechnung für {% data variables.product.prodname_actions %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
{% data reusables.github-actions.actions-billing %} Weitere Informationen findest Du unter „[Informationen zur Abrechnung für {% data variables.product.prodname_actions %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)“.
|
||||
{% else %}
|
||||
GitHub Actions usage is free for
|
||||
{% data variables.product.prodname_ghe_server %} that use self-hosted runners.
|
||||
{% endif %}
|
||||
|
||||
### Nutzungseinschränkungen
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
There are some limits on
|
||||
{% data variables.product.prodname_actions %} usage when using {% data variables.product.prodname_dotcom %}-hosted runners. Die Einschränkungen können sich jederzeit ändern.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** For self-hosted runners, different usage limits apply. Weitere Informationen findest Du unter „[Informationen zu selbst-gehosteten Runnern](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)“.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
- **Job execution time** (Auftrags-Ausführungszeit) - Jeder Job in einem Workflow kann bis zu 6 Stunden Ausführungszeit laufen. Wenn ein Auftrag dieses Limit erreicht, wird der Auftrag beendet und kann nicht abgeschlossen werden.
|
||||
{% data reusables.github-actions.usage-workflow-run-time %}
|
||||
{% data reusables.github-actions.usage-api-requests %}
|
||||
- **Concurrent Jobs** (parallele Aufträge) - Die Anzahl paralleler Aufträge, die Du in Ihrem Konto ausführen kannst, hängt von Deinem GitHub-Plan ab, wie in der folgenden Tabelle ersichtlich. Bei Überschreitung werden alle zusätzlichen Aufträge in die Warteschlange gestellt.
|
||||
|
||||
| GitHub Plan | Total parallele Aufträge | Maximal parallele macOS-Aufträge |
|
||||
| ----------- | ------------------------ | -------------------------------- |
|
||||
| Kostenlos | 20 | 5 |
|
||||
| Pro | 40 | 5 |
|
||||
| Team | 60 | 5 |
|
||||
| Enterprise | 180 | 50 |
|
||||
- **Auftrags-Matrix** - {% data reusables.github-actions.usage-matrix-limits %}
|
||||
{% else %}
|
||||
Usage limits apply to self-hosted runners. Weitere Informationen findest Du unter „[Informationen zu selbst-gehosteten Runnern](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)“.
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
### Nutzungsrichtlinien
|
||||
In addition to the usage limits, you must ensure that you use
|
||||
|
||||
{% data variables.product.prodname_actions %} within the [GitHub Terms of Service](/articles/github-terms-of-service/). Weitere Informationen zu {% data variables.product.prodname_actions %}-spezifischen Bedingungen findest Du unter [Zusätzliche Produktbedingungen für GitHub](/github/site-policy/github-additional-product-terms#a-actions-usage).
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
### Artifact and log retention policy
|
||||
|
||||
You can configure the artifact and log retention period for your repository, organization, or enterprise account.
|
||||
|
||||
{% data reusables.actions.about-artifact-log-retention %}
|
||||
|
||||
Weitere Informationen findest Du unter:
|
||||
|
||||
- [Configuring the retention period for {% data variables.product.prodname_actions %} for artifacts and logs in your repository](/github/administering-a-repository/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)
|
||||
- [Configuring the retention period for {% data variables.product.prodname_actions %} for artifacts and logs in your organization](/github/setting-up-and-managing-organizations-and-teams/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization)
|
||||
- [Configuring the retention period for {% data variables.product.prodname_actions %} for artifacts and logs in your enterprise](/github/setting-up-and-managing-your-enterprise-account/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-enterprise-account)
|
||||
{% endif %}
|
||||
|
||||
### {% data variables.product.prodname_actions %} für Dein Repository oder Deine Organisation deaktivieren oder beschränken
|
||||
|
||||
{% data reusables.github-actions.disabling-github-actions %}
|
||||
|
||||
Weitere Informationen findest Du unter:
|
||||
- "[Disabling or limiting {% data variables.product.prodname_actions %} for a repository](/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository)"
|
||||
- "[Disabling or limiting {% data variables.product.prodname_actions %} for your organization](/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization)"{% if currentVersion == "free-pro-team@latest" %}
|
||||
- "[Enforcing {% data variables.product.prodname_actions %} policies in your enterprise account](/github/setting-up-and-managing-your-enterprise-account/enforcing-github-actions-policies-in-your-enterprise-account)" for {% data variables.product.prodname_ghe_cloud %}{% endif %}
|
||||
|
||||
### Disabling and enabling workflows
|
||||
|
||||
You can enable and disable individual workflows in your repository on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
{% data reusables.actions.scheduled-workflows-disabled %}
|
||||
|
||||
For more information, see "[Disabling and enabling a workflow](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow)."
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Workflow-Befehle für GitHub-Aktionen
|
||||
shortTitle: Workflow-Befehle
|
||||
intro: 'Du kannst Workflow-Befehle verwenden, wenn Du Shell-Befehle in einem Workflow oder im Code einer Aktion ausführst.'
|
||||
intro: Du kannst Workflow-Befehle verwenden, wenn Du Shell-Befehle in einem Workflow oder im Code einer Aktion ausführst.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/development-tools-for-github-actions
|
||||
@@ -21,7 +21,11 @@ versions:
|
||||
|
||||
Aktionen können mit dem Runner-Rechner kommunizieren, um Umgebungsvariablen zu setzen, Werte zur Verwendung in anderen Aktionen auszugeben, Debug-Meldungen zu den Ausgabeprotokollen zuzufügen und für andere Zwecke.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
Most workflow commands use the `echo` command in a specific format, while others are invoked by writing to a file. For more information, see ["Environment files".](#environment-files)
|
||||
{% else %}
|
||||
Workflow-Befehle verwenden den Befehl `echo` in einem bestimmten Format.
|
||||
{% endif %}
|
||||
|
||||
``` bash
|
||||
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
|
||||
@@ -41,40 +45,46 @@ echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
|
||||
|
||||
### Workflow-Befehle verwenden, um auf Funktionen des Toolkits zuzugreifen
|
||||
|
||||
Das [actions/toolkit](https://github.com/actions/toolkit) enthält eine Reihe von Funktionen, die als Workflow-Befehle ausgeführt werden können. Verwende die Syntax `::`, um die Workflow-Befehle in Deiner YAML-Datei auszuführen. Diese Befehle werden dann über `stdout` an den Runner gesandt. Anstatt beispielsweise zum Setzen einer Umgebungsvariablen Code folgendermaßen zu verwenden:
|
||||
Das [actions/toolkit](https://github.com/actions/toolkit) enthält eine Reihe von Funktionen, die als Workflow-Befehle ausgeführt werden können. Verwende die Syntax `::`, um die Workflow-Befehle in Deiner YAML-Datei auszuführen. Diese Befehle werden dann über `stdout` an den Runner gesandt. For example, instead of using code to set an output, as below:
|
||||
|
||||
```javascript
|
||||
core.exportVariable('SELECTED_COLOR', 'green');
|
||||
core.setOutput('SELECTED_COLOR', 'green');
|
||||
```
|
||||
|
||||
kannst Du den Befehl `set-env` in Deinem Workflow verwenden, um den gleichen Wert zu setzen:
|
||||
You can use the `set-output` command in your workflow to set the same value:
|
||||
|
||||
``` yaml
|
||||
- name: Set selected color
|
||||
run: echo '::set-env name=SELECTED_COLOR::green'
|
||||
run: echo '::set-output name=SELECTED_COLOR::green'
|
||||
id: random-color-generator
|
||||
- name: Get color
|
||||
run: echo 'The selected color is' $SELECTED_COLOR
|
||||
run: echo 'The selected color is' ${steps.random-color-generator.outputs.SELECTED_COLOR}
|
||||
```
|
||||
|
||||
Die folgende Tabelle zeigt, welche Toolkit-Funktionen innerhalb eines Workflows verfügbar sind:
|
||||
|
||||
| Toolkit-Funktion | Äquivalenter Workflow-Befehl |
|
||||
| --------------------- | ------------------------------------------------------- |
|
||||
| `core.addPath` | `add-path` |
|
||||
| `core.debug` | `debug` |
|
||||
| `core.error` | `error` |
|
||||
| `core.endGroup` | `endgroup` |
|
||||
| `core.exportVariable` | `set-env` |
|
||||
| `core.getInput` | Zugänglich durch Umgebungsvariable `INPUT_{NAME}` |
|
||||
| `core.getState` | Zugänglich durch Umgebungsvariable `STATE_{NAME}` |
|
||||
| `core.isDebug` | Zugänglich durch Umgebungsvariable `RUNNER_DEBUG` |
|
||||
| `core.saveState` | `save-state` |
|
||||
| `core.setFailed` | Wird als Abkürzung für `::error` und `exit 1` verwendet |
|
||||
| `core.setOutput` | `set-output` |
|
||||
| `core.setSecret` | `add-mask` |
|
||||
| `core.startGroup` | `Gruppe` |
|
||||
| `core.warning` | `warning file` |
|
||||
| Toolkit-Funktion | Äquivalenter Workflow-Befehl |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| `core.addPath` | |
|
||||
| {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}Accessible using environment file `GITHUB_PATH`{% else %} `add-path` {% endif %} | |
|
||||
| | |
|
||||
| `core.debug` | `debug` |
|
||||
| `core.error` | `error` |
|
||||
| `core.endGroup` | `endgroup` |
|
||||
| `core.exportVariable` | |
|
||||
| {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}Accessible using environment file `GITHUB_ENV`{% else %} `set-env` {% endif %} | |
|
||||
| | |
|
||||
| `core.getInput` | Zugänglich durch Umgebungsvariable `INPUT_{NAME}` |
|
||||
| `core.getState` | Zugänglich durch Umgebungsvariable `STATE_{NAME}` |
|
||||
| `core.isDebug` | Zugänglich durch Umgebungsvariable `RUNNER_DEBUG` |
|
||||
| `core.saveState` | `save-state` |
|
||||
| `core.setFailed` | Wird als Abkürzung für `::error` und `exit 1` verwendet |
|
||||
| `core.setOutput` | `set-output` |
|
||||
| `core.setSecret` | `add-mask` |
|
||||
| `core.startGroup` | `Gruppe` |
|
||||
| `core.warning` | `warning file` |
|
||||
|
||||
{% if currentVersion ver_lt "enterprise-server@2.23" %}
|
||||
### Setting an environment variable
|
||||
|
||||
`::set-env name={name}::{value}`
|
||||
@@ -86,6 +96,7 @@ Erstellt oder aktualisiert eine Umgebungsvariable für alle Aktionen, die als n
|
||||
``` bash
|
||||
echo "::set-env name=action_state::yellow"
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
### Setting an output parameter
|
||||
|
||||
@@ -101,6 +112,7 @@ Optional kannst Du auch Ausgabeparameter in der Metadaten-Datei einer Aktion dek
|
||||
echo "::set-output name=action_fruit::strawberry"
|
||||
```
|
||||
|
||||
{% if currentVersion ver_lt "enterprise-server@2.23" %}
|
||||
### Adding a system path
|
||||
|
||||
`::add-path::{path}`
|
||||
@@ -112,12 +124,13 @@ Fügt für alle nachfolgenden Aktionen im aktuellen Auftrag vor der Systemvariab
|
||||
``` bash
|
||||
echo "::add-path::/path/to/dir"
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
### Setting a debug message
|
||||
|
||||
`::debug::{message}`
|
||||
|
||||
Gibt eine Debugging-Meldung im Protokoll aus. Sie müssen ein Geheimnis mit dem Namen `ACTIONS_STEP_DEBUG` und dem Wert `true` erstellen, um die durch diesen Befehl festgelegten Debugging-Meldungen im Protokoll zu sehen. Weitere Informationen findest Du unter „[Eine Workflow-Ausführung verwalten](/actions/configuring-and-managing-workflows/managing-a-workflow-run#enabling-debug-logging)“.
|
||||
Gibt eine Debugging-Meldung im Protokoll aus. Sie müssen ein Geheimnis mit dem Namen `ACTIONS_STEP_DEBUG` und dem Wert `true` erstellen, um die durch diesen Befehl festgelegten Debugging-Meldungen im Protokoll zu sehen. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)."
|
||||
|
||||
#### Beispiel
|
||||
|
||||
@@ -213,3 +226,67 @@ Die Variable `STATE_processID` ist dann exklusiv für das Bereinigungsskript ver
|
||||
``` javascript
|
||||
console.log("The running PID from the main action is: " + process.env.STATE_processID);
|
||||
```
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
## Environment Files
|
||||
|
||||
During the execution of a workflow, the runner generates temporary files that can be used to perform certain actions. The path to these files are exposed via environment variables. You will need to use UTF-8 encoding when writing to these files to ensure proper processing of the commands. Multiple commands can be written to the same file, separated by newlines.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** Powershell does not use UTF-8 by default. Make sure you write files using the correct encoding. For example, you need to set UTF-8 encoding when you set the path:
|
||||
|
||||
```
|
||||
steps:
|
||||
- run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
|
||||
```
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Setting an environment variable
|
||||
|
||||
`echo "{name}={value}" >> $GITHUB_ENV`
|
||||
|
||||
Erstellt oder aktualisiert eine Umgebungsvariable für alle Aktionen, die als nächstes in einem Auftrag ausgeführt werden. Die Aktion, die die Umgebungsvariable erstellt oder aktualisiert, kann nicht auf den neuen Wert zugreifen; alle nachfolgenden Aktionen in einem Auftrag haben dagegen Zugriff auf den neuen Wert. Bei Umgebungsvariablen wird die Groß- und Kleinschreibung berücksichtigt. Sie können auch Satzzeichen enthalten.
|
||||
|
||||
#### Beispiel
|
||||
|
||||
```bash
|
||||
echo "action_state=yellow" >> $GITHUB_ENV
|
||||
```
|
||||
|
||||
Running `$action_state` in a future step will now return `yellow`
|
||||
|
||||
#### Multline strings
|
||||
For multiline strings, you may use a delimiter with the following syntax.
|
||||
|
||||
```
|
||||
{name}<<{delimiter}
|
||||
{value}
|
||||
{delimiter}
|
||||
```
|
||||
|
||||
#### Beispiel
|
||||
In this example, we use `EOF` as a delimiter and set the `JSON_RESPONSE` environment variable to the value of the curl response.
|
||||
```
|
||||
steps:
|
||||
- name: Set the value
|
||||
id: step_one
|
||||
run: |
|
||||
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
|
||||
curl https://httpbin.org/json >> $GITHUB_ENV
|
||||
echo 'EOF' >> $GITHUB_ENV
|
||||
```
|
||||
|
||||
### Adding a system path
|
||||
|
||||
`echo "{path}" >> $GITHUB_PATH`
|
||||
|
||||
Fügt für alle nachfolgenden Aktionen im aktuellen Auftrag vor der Systemvariablen `PATH` ein Verzeichnis hinzu. Die gerade ausgeführte Aktion kann nicht auf die neue Pfadvariable zugreifen.
|
||||
|
||||
#### Beispiel
|
||||
|
||||
``` bash
|
||||
echo "/path/to/dir" >> $GITHUB_PATH
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Workflow-Syntax für GitHub Actions
|
||||
shortTitle: Syntax für Workflows
|
||||
intro: 'Ein Workflow ist ein konfigurierbarer automatisierter Prozess, der aus einem oder mehreren Jobs besteht. Du musst eine YAML-Datei erstellen, um Deine Workflow-Konfiguration zu definieren.'
|
||||
intro: Ein Workflow ist ein konfigurierbarer automatisierter Prozess, der aus einem oder mehreren Jobs besteht. Du musst eine YAML-Datei erstellen, um Deine Workflow-Konfiguration zu definieren.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /articles/workflow-syntax-for-github-actions
|
||||
@@ -21,10 +21,6 @@ Workflow-Dateien verwenden die YAML-Syntax und müssen die Dateierweiterung `.ym
|
||||
|
||||
Workflow-Dateien müssen im Verzeichnis `.github/workflows` im Repository gespeichert werden.
|
||||
|
||||
### Nutzungseinschränkungen
|
||||
|
||||
{% data reusables.github-actions.github-actions-usage-limits %}
|
||||
|
||||
### **`name`**
|
||||
|
||||
Name des Workflows. {% data variables.product.prodname_dotcom %} zeigt die Namen der Workflows auf der Repository-Seite der Aktionen an. Wenn Du `name`weglässt, setzt {% data variables.product.prodname_dotcom %} den Pfad der Workflow-Datei relativ zum Stammverzeichnis des Repositorys.
|
||||
@@ -62,18 +58,18 @@ Die in `branches` und `tags` definierten Muster werden anhand des Namens des Git
|
||||
```yaml
|
||||
on:
|
||||
push:
|
||||
# Folge von Mustern zum Abgleich mit refs/heads
|
||||
# Sequence of patterns matched against refs/heads
|
||||
branches:
|
||||
# Push-Ereignisse auf den Master-Branch
|
||||
- master
|
||||
# Push-Ereignisse auf Branches, die zu refs/heads/mona/octocat passen
|
||||
# Push events on main branch
|
||||
- main
|
||||
# Push events to branches matching refs/heads/mona/octocat
|
||||
- 'mona/octocat'
|
||||
# Push-Ereignisse auf Branches, die zu refs/heads/releases/10 passen
|
||||
# Push events to branches matching refs/heads/releases/10
|
||||
- 'releases/**'
|
||||
# Folge von Mustern zum Abgleich mit refs/tags
|
||||
# Sequence of patterns matched against refs/tags
|
||||
tags:
|
||||
- v1 # Push-Ereignisse auf den Tag v1
|
||||
- v1.* # Push-Ereignisse auf die Tags v1.0, v1.1 und v1.9
|
||||
- v1 # Push events to v1 tag
|
||||
- v1.* # Push events to v1.0, v1.1, and v1.9 tags
|
||||
```
|
||||
|
||||
#### Beispiel zum Ignorieren von Branches und Tags
|
||||
@@ -229,7 +225,7 @@ Ein Workflow-Lauf besteht aus mindestens einem Auftrag. Die Aufträge werden sta
|
||||
|
||||
Jeder Job läuft in einer Umgebung, die mit `runs-on` angegeben wird.
|
||||
|
||||
Innerhalb der Nutzungsbeschränkungen des Workflows kannst Du unbegrenzt viele Jobs ausführen. Weitere Informationen finden Sie unter „[Nutzungseinschränkungen](#usage-limits)“.
|
||||
Innerhalb der Nutzungsbeschränkungen des Workflows kannst Du unbegrenzt viele Jobs ausführen. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
|
||||
|
||||
Wenn Du den eindeutigen Bezeichner eines Jobs finden musst, der in einem Workflowlauf ausgeführt wird, kannst Du die API von {% data variables.product.prodname_dotcom %} verwenden. For more information, see "[Workflow Jobs](/v3/actions/workflow-jobs)."
|
||||
|
||||
@@ -310,7 +306,7 @@ runs-on: [self-hosted, linux]
|
||||
|
||||
Weitere Informationen findest Du unter „[Informationen zu selbst-gehosteten Runnern](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)“ und „[Selbst-gehostete Runner in einem Workflow verwenden](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)“.
|
||||
|
||||
### **`jobs.<jobs_id>.outputs`**
|
||||
### **`jobs.<job_id>.outputs`**
|
||||
|
||||
Eine `map` der Ausgaben eines Jobs. Ausgaben eines Jobs stehen allen nachgelagerten Jobs zur Verfügung, die von diesem Job abhängen. Weitere Informationen zur Definition von Abhängigkeiten zwischen Jobs findest Du unter [`Jobs.<job_id>.needs`](#jobsjob_idneeds).
|
||||
|
||||
@@ -393,7 +389,7 @@ Mit der `if`-Bedingung geben Sie an, dass ein Auftrag nur dann ausgeführt werde
|
||||
|
||||
Ein Auftrag enthält eine Sequenz von Aufgaben, sogenannten `steps`. Mit Schritten können Befehle oder Einrichtungsaufgaben ausgeführt werden, und außerdem Aktionen, die sich in Ihrem Repository oder in einem öffentlichen Repository befinden oder in einer Docker Registry veröffentlicht sind. Nicht alle Schritte führen eine Aktion aus, doch alle Aktionen werden als Schritt ausgeführt. Jeder Schritt wird in einem eigenen Prozess in der Runner-Umgebung ausgeführt. Er hat Zugriff auf den Arbeitsbereich und das Dateisystem. Da die Schritte jeweils in einem eigenen Prozess ausgeführt werden, werden Änderungen an den Umgebungsvariablen nicht von Schritt zu Schritt beibehalten. {% data variables.product.prodname_dotcom %} umfasst integrierte Schritte zum Einrichten und Ausführen eines Auftrags.
|
||||
|
||||
Innerhalb der Nutzungseinschränkungen des Workflows können Sie unbegrenzt viele Schritte ausführen. Weitere Informationen finden Sie unter „[Nutzungseinschränkungen](#usage-limits)“.
|
||||
Innerhalb der Nutzungseinschränkungen des Workflows können Sie unbegrenzt viele Schritte ausführen. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
|
||||
|
||||
#### Beispiel
|
||||
|
||||
@@ -421,7 +417,7 @@ jobs:
|
||||
|
||||
#### **`jobs.<job_id>.steps.id`**
|
||||
|
||||
Eindeutige Kennung für den Schritt. Anhand der `id` können Sie in Kontexten auf den Schritt verweisen. Weitere Informationen findest Du unter "[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
Eindeutige Kennung für den Schritt. Anhand der `id` können Sie in Kontexten auf den Schritt verweisen. Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
#### **`jobs.<job_id>.steps.if`**
|
||||
|
||||
@@ -447,7 +443,7 @@ steps:
|
||||
```yaml
|
||||
steps:
|
||||
- name: My first step
|
||||
uses: monacorp/action-name@master
|
||||
uses: monacorp/action-name@main
|
||||
- name: My backup step
|
||||
if: {% raw %}${{ failure() }}{% endraw %}
|
||||
uses: actions/heroku@master
|
||||
@@ -464,7 +460,7 @@ Wählt eine Aktion aus, die als Teil eines Schritts im Auftrag ausgeführt wird.
|
||||
Es wird dringend empfohlen, die verwendete Version der Aktion zu nennen (Git-Ref, SHA oder Docker-Tag-Nummer angeben). Wenn Sie keine Version angeben, könnten damit die Workflows gestört werden, oder es wird ein unerwartetes Verhalten hervorgerufen, wenn der Inhaber der Aktion eine Aktualisierung veröffentlicht.
|
||||
- Am besten in Hinblick auf Stabilität und Sicherheit ist es, die Commit-SHA einer freigegebenen Version einer Aktion zu verwenden.
|
||||
- Wenn Du Dich auf die Hauptversion der Aktion beziehst, kannst Du kritische Fehlerbehebungen und Sicherheits-Patches erhalten und gleichzeitig die Kompatibilität wahren. Außerdem ist damit sichergestellt, dass der Workflow weiterhin problemlos arbeiteten sollte.
|
||||
- Die Verwendung des `master`-Branches einer Aktion ist zwar auf den ersten Blick komfortabel, doch wenn eine neue Hauptversion mit einer bahnbrechenden Änderung veröffentlicht wird, könnte damit Dein Workflow gestört werden.
|
||||
- Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.
|
||||
|
||||
Für einige Aktionen sind Eingaben erforderlich, die Sie mit dem Stichwort [`with`](#jobsjob_idstepswith) festlegen müssen. Die erforderlichen Eingaben finden Sie in der README-Datei der Aktion.
|
||||
|
||||
@@ -474,14 +470,14 @@ Aktionen sind entweder JavaScript-Dateien oder Docker-Container. Bei Docker-Cont
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
# Verweis auf einen bestimmten Commit
|
||||
# Reference a specific commit
|
||||
- uses: actions/setup-node@74bc508
|
||||
# Verweis auf die Hauptversion eines Release
|
||||
# Reference the major version of a release
|
||||
- uses: actions/setup-node@v1
|
||||
#Verweis auf eine Unterversion eines Release
|
||||
# Reference a minor version of a release
|
||||
- uses: actions/setup-node@v1.2
|
||||
# Verweis auf einen Branch
|
||||
- uses: actions/setup-node@master
|
||||
# Reference a branch
|
||||
- uses: actions/setup-node@main
|
||||
```
|
||||
|
||||
##### Beispiel mit einer öffentlichen Aktion
|
||||
@@ -495,10 +491,10 @@ jobs:
|
||||
my_first_job:
|
||||
steps:
|
||||
- name: My first step
|
||||
# Verwendet den Master-Branch eines oeffentlichen Repositorys
|
||||
# Uses the default branch of a public repository
|
||||
uses: actions/heroku@master
|
||||
- name: My second step
|
||||
# Verwendet eine bestimmte Versionsbezeichnung eines oeffentlichen Repositorys
|
||||
# Uses a specific version tag of a public repository
|
||||
uses: actions/aws@v2.0.1
|
||||
```
|
||||
|
||||
@@ -513,7 +509,7 @@ jobs:
|
||||
my_first_job:
|
||||
steps:
|
||||
- name: My first step
|
||||
uses: actions/aws/ec2@master
|
||||
uses: actions/aws/ec2@main
|
||||
```
|
||||
|
||||
##### Beispiel mit einer Aktion im selben Repository wie der Workflow
|
||||
@@ -599,11 +595,11 @@ Du kannst die Einstellungen zur Standard-Shell im Betriebssystem des Läufers mi
|
||||
| Unterstützte Plattform | Parameter `shell` | Beschreibung | Intern ausgeführter Befehl |
|
||||
| ---------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
|
||||
| Alle | `bash` | Die standardmäßige Shell für alle Plattformen außer Windows mit einem Fallback zu `sh`. Wenn eine Bash-Shell für Windows angegeben wird, wird die in Git für Windows enthaltene Bash-Shell verwendet. | `bash --noprofile --norc -eo pipefail {0}` |
|
||||
| Alle | `pwsh` | Der PowerShell Core. {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.ps1` an den Skriptnamen an. | `pwsh -command "& '{0}'"` |
|
||||
| Alle | `pwsh` | Der PowerShell Core. {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.ps1` an Deinen Skriptnamen an. | `pwsh -command ". '{0}'"` |
|
||||
| Alle | `python` | Führt den Befehl Python aus. | `python {0}` |
|
||||
| Linux / macOS | `sh` | Das Fallback-Verhalten für alle Betriebssystem-Plattformen außer Windows, falls keine Shell angegeben ist und `bash` nicht im Pfad gefunden wird. | `sh -e {0}` |
|
||||
| Windows | `cmd` | {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.cmd` an Deinen Skriptnamen an und ersetzt `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. |
|
||||
| Windows | `powershell` | Dies ist die standardmäßig für Windows verwendete Shell. Die Desktop PowerShell. {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.ps1` an den Skriptnamen an. | `powershell -command "& '{0}'"`. |
|
||||
| Windows | `cmd` | {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.cmd` an Deinen Skriptnamen an und ersetzt `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. |
|
||||
| Windows | `powershell` | Dies ist die standardmäßig für Windows verwendete Shell. Die Desktop PowerShell. {% data variables.product.prodname_dotcom %} hängt die Erweiterung `.ps1` an Deinen Skriptnamen an. | `powershell -command ". '{0}'"`. |
|
||||
|
||||
##### Beispiel zur Ausführung eines Skripts mittels Bash
|
||||
|
||||
@@ -678,7 +674,7 @@ jobs:
|
||||
my_first_job:
|
||||
steps:
|
||||
- name: My first step
|
||||
uses: actions/hello_world@master
|
||||
uses: actions/hello_world@main
|
||||
with:
|
||||
first_name: Mona
|
||||
middle_name: The
|
||||
@@ -695,7 +691,7 @@ Ein `string`, der die Eingaben für einen Docker-Container definiert. Beim Start
|
||||
```yaml
|
||||
steps:
|
||||
- name: Explain why this job ran
|
||||
uses: monacorp/action-name@master
|
||||
uses: monacorp/action-name@main
|
||||
with:
|
||||
entrypoint: /bin/echo
|
||||
args: The ${{ github.event_name }} event triggered this step.
|
||||
@@ -708,7 +704,6 @@ Die `args`-Anweisungen werden anstelle der `CMD`-Anweisung in einem `Dockerfile`
|
||||
1. Verwenden Sie Standardwerte, die die Verwendung der Aktion ohne Angabe von `args` erlauben.
|
||||
1. Wenn die Aktion einen Schalter `--help` oder Ähnliches anbietet, verwende diesen als Standard, um eine selbstständige Dokumentation der Aktion herbeizuführen.
|
||||
|
||||
|
||||
#### **`jobs.<job_id>.steps.with.entrypoint`**
|
||||
|
||||
Überschreibt den Docker-`ENTRYPOINT` im `Dockerfile` oder legt ihn fest, sofern er noch nicht angegeben wurde. Im Gegensatz zur Docker `ENTRYPOINT`-Anweisung, die eine Shell- und eine ausführbare Form aufweist, akzeptiert das Stichwort `entrypoint` nur einen einzigen Schritt, der die entsprechende ausführbare Datei definiert.
|
||||
@@ -718,7 +713,7 @@ Die `args`-Anweisungen werden anstelle der `CMD`-Anweisung in einem `Dockerfile`
|
||||
```yaml
|
||||
steps:
|
||||
- name: Run a custom command
|
||||
uses: monacorp/action-name@master
|
||||
uses: monacorp/action-name@main
|
||||
with:
|
||||
entrypoint: /a/different/executable
|
||||
```
|
||||
@@ -766,9 +761,9 @@ Mit einer Strategie wird eine Build-Matrix für die Aufträge erstellt. Sie kön
|
||||
|
||||
Du kannst eine Matrix aus verschiedenen Job-Konfigurationen definieren. Mit einer Matrix kannst Du mehrere Jobs erstellen, indem Du in einer einzigen Jobdefinition Variablen substituierst. Zum Beispiel kannst Du eine Matrix verwenden, um Jobs für mehrere unterstützte Versionen einer Programmiersprache, eines Betriebssystems oder eines Tools zu erstellen. Eine Matrix verwendet die Job-Konfiguration mehrfach und erstellt einen Job für jeden Eintrag in der Matrix, die Du konfigurierst.
|
||||
|
||||
{% data reusables.github-actions.matrix-limits %}
|
||||
{% data reusables.github-actions.usage-matrix-limits %}
|
||||
|
||||
Jede Option, die Du in der `Matrix` definierst, hat einen Schlüssel und einen Wert. Die Schlüssel, die Du definierst, werden zu Eigenschaften im Kontext `Matrix` und Du kannst diese Eigenschaften in anderen Bereichen Ihrer Workflow-Datei referenzieren. Wenn Du zum Beispiel den Schlüssel `os` definierst, der ein Array von Betriebssystemen enthält, kannst Du die Eigenschaft `matrix.os` als Wert für das Schlüsselwort `runs-on` verwenden, um einen Job für jedes Betriebssystem zu erstellen. Weitere Informationen findest Du unter "[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
Jede Option, die Du in der `Matrix` definierst, hat einen Schlüssel und einen Wert. Die Schlüssel, die Du definierst, werden zu Eigenschaften im Kontext `Matrix` und Du kannst diese Eigenschaften in anderen Bereichen Ihrer Workflow-Datei referenzieren. Wenn Du zum Beispiel den Schlüssel `os` definierst, der ein Array von Betriebssystemen enthält, kannst Du die Eigenschaft `matrix.os` als Wert für das Schlüsselwort `runs-on` verwenden, um einen Job für jedes Betriebssystem zu erstellen. Weitere Informationen findest Du unter „[Kontext- und Ausdrucks-Syntax für {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)“.
|
||||
|
||||
Die Reihenfolge, in der Du eine `Matrix` definierst, ist wichtig. Die erste Option, die Du definierst, ist der erste Job, der im Workflow ausgeführt wird.
|
||||
|
||||
@@ -843,7 +838,6 @@ strategy:
|
||||
|
||||
Du kannst `include` verwenden, um neue Jobs zu einer Build-Matrix hinzuzufügen. Alle Include-Konfigurationen, die nicht passen, werden zur Matrix hinzugefügt. Wenn Du beispielsweise `node` Version 12 verwenden willst, um auf mehreren Betriebssystemen zu bauen, aber Du willst einen zusätzlichen experimentellen Job mit Node Version 13 auf Ubuntu, kannst Du `include` verwenden, um diesen zusätzlichen Job anzugeben.
|
||||
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
runs-on: ${{ matrix.os }}
|
||||
@@ -952,7 +946,25 @@ jobs:
|
||||
|
||||
#### **`jobs.<job_id>.container.image`**
|
||||
|
||||
Docker-Image, das beim Ausführen der Aktion als Container herangezogen wird. Als Wert kann der Name des Docker Hub-Images oder einer öffentlichen Docker Registry angegeben werden.
|
||||
Docker-Image, das beim Ausführen der Aktion als Container herangezogen wird. The value can be the Docker Hub image name or a {% if currentVersion != "free-pro-team@latest" and currentVersion ver_lt "enterprise-server@2.23" %}public{% endif %} registry name.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
#### **`jobs.<job_id>.container.credentials`**
|
||||
|
||||
{% data reusables.actions.registry-credentials %}
|
||||
|
||||
##### Beispiel
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
container:
|
||||
image: ghcr.io/owner/image
|
||||
credentials:
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.ghcr_token }}
|
||||
```
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
|
||||
#### **`jobs.<job_id>.container.env`**
|
||||
|
||||
@@ -997,7 +1009,7 @@ Wenn Du den Job so konfigurierst, dass er direkt auf der Runner-Maschine läuft
|
||||
|
||||
Weitere Informationen über die Unterschiede zwischen Netzwerk-Servicecontainern finden Sie unter „[Informationen zu Servicecontainern](/actions/automating-your-workflow-with-github-actions/about-service-containers)“.
|
||||
|
||||
#### Beispiel für die Verwendung von localhost
|
||||
#### Beispiel für die Verwendung von „localhost“
|
||||
|
||||
Dieses Beispiel erzeugt zwei Dienste: nginx und redis. Wenn Du den Port des Docker-Hosts angibst, aber nicht den des Containers, dann wird der Container-Port zufällig einem freien Port zugewiesen. {% data variables.product.prodname_dotcom %} setzt den zugewiesenen Containerport im Kontext {% raw %}`${{job.services.<service_name>.ports}}`{% endraw %} . In diesem Beispiel kannst Du über die Kontexte {% raw %}`${{ job.services.nginx.ports['8080'] }}`{% endraw %} und {% raw %}`${{ job.services.redis.ports['6379'] }}`{% endraw %} auf die Ports des Servicecontainers zugreifen.
|
||||
|
||||
@@ -1015,19 +1027,43 @@ services:
|
||||
- 6379/tcp
|
||||
```
|
||||
|
||||
#### **`jobs.<job_id>.services.image`**
|
||||
#### **`jobs.<job_id>.services.<service_id>.image`**
|
||||
|
||||
Docker-Image, das beim Ausführen der Aktion als Dienstcontainer herangezogen wird. Als Wert kann der Name des Docker-Basis-Images, eines öffentlichen Docker Hub oder einer öffentlichen Docker Registry angegeben werden.
|
||||
Docker-Image, das beim Ausführen der Aktion als Dienstcontainer herangezogen wird. The value can be the Docker Hub image name or a {% if currentVersion != "free-pro-team@latest" and currentVersion ver_lt "enterprise-server@2.23" %}public{% endif %} registry name.
|
||||
|
||||
#### **`jobs.<job_id>.services.env`**
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
#### **`jobs.<job_id>.services.<service_id>.credentials`**
|
||||
|
||||
{% data reusables.actions.registry-credentials %}
|
||||
|
||||
##### Beispiel
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
services:
|
||||
myservice1:
|
||||
image: ghcr.io/owner/myservice1
|
||||
credentials:
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.ghcr_token }}
|
||||
myservice2:
|
||||
image: dockerhub_org/myservice2
|
||||
credentials:
|
||||
username: ${{ secrets.DOCKER_USER }}
|
||||
password: ${{ secrets.DOCKER_PASSWORD }}
|
||||
```
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
|
||||
#### **`jobs.<job_id>.services.<service_id>.env`**
|
||||
|
||||
Legt eine `map` mit Umgebungsvariablen im Servicecontainer fest.
|
||||
|
||||
#### **`jobs.<job_id>.services.ports`**
|
||||
#### **`jobs.<job_id>.services.<service_id>.ports`**
|
||||
|
||||
Legt ein `array` mit Ports fest, die im Dienstcontainer offengelegt werden.
|
||||
|
||||
#### **`jobs.<job_id>.services.volumes`**
|
||||
#### **`jobs.<job_id>.services.<service_id>.volumes`**
|
||||
|
||||
Legt ein `array` mit Volumes für den Dienstcontainer fest. Mithilfe von Volumes können Sie Daten zwischen Diensten oder anderen Schritten in einem Auftrag austauschen. Sie können benannte Docker-Volumes, anonyme Docker-Volumes oder Bind-Mounts auf dem Host angegeben.
|
||||
|
||||
@@ -1046,11 +1082,11 @@ volumes:
|
||||
- /source/directory:/destination/directory
|
||||
```
|
||||
|
||||
#### **`jobs.<job_id>.services.options`**
|
||||
#### **`jobs.<job_id>.services.<service_id>.options`**
|
||||
|
||||
Zusätzliche Optionen für die Docker-Containerressource. Eine Liste der Optionen finden Sie unter „[Optionen für `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options)“.
|
||||
|
||||
### Spickzettel zu Filtermustern
|
||||
### Merkzettel zu Filtermustern
|
||||
|
||||
Die Pfad-, Branch- und Tag-Filter können bestimmte Sonderzeichen umfassen.
|
||||
|
||||
@@ -1076,16 +1112,16 @@ Weitere Informationen zur Syntax für Branch-, Tag- und Pfadfilter finden Sie un
|
||||
|
||||
#### Muster für den Abgleich von Branches und Tags
|
||||
|
||||
| Muster | Beschreibung | Beispiele für Übereinstimmungen |
|
||||
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
|
||||
| `feature/*` | Das Platzhalterzeichen `*` steht für ein beliebiges Zeichen, nicht jedoch für den Schrägstrich (`/`). | -`feature/my-branch`<br/>-`feature/your-branch` |
|
||||
| `feature/**` | Das Platzhalterzeichen `**` steht für ein beliebiges Zeichen, also auch für den Schrägstrich (`/`), in Branch- und Tag-Namen. | -`feature/beta-a/my-branch`<br/>-`feature/your-branch`<br/>-`feature/mona/the/octocat` |
|
||||
| -`master`<br/>-`releases/mona-the-octcat` | Abgleich mit dem exakten Branch- oder Tag-Namen. | -`master`<br/>-`releases/mona-the-octocat` |
|
||||
| `'*'` | Abgleich mit allen Branch- und Tag-Namen, die keinen Schrägstrich (`/`) enthalten. Das Zeichen `*` ist ein Sonderzeichen in YAML. Wenn ein Muster mit `*` beginnen soll, sind Anführungszeichen erforderlich. | -`master`<br/>-`releases` |
|
||||
| `'**'` | Abgleich mit allen Branch- und Tag-Namen. Dies ist das Standardverhalten, wenn Sie keinen `branches`- oder `tags`-Filter angeben. | -`all/the/branches`<br/>-`every/tag` |
|
||||
| `'*feature'` | Das Zeichen `*` ist ein Sonderzeichen in YAML. Wenn ein Muster mit `*` beginnen soll, sind Anführungszeichen erforderlich. | -`mona-feature`<br/>-`feature`<br/>-`ver-10-feature` |
|
||||
| `v2*` | Abgleich mit Branch- und Tag-Namen, die mit `v2` beginnen. | -`v2`<br/>-`v2.0`<br/>-`v2.9` |
|
||||
| `v[12].[0-9]+.[0-9]+` | Abgleich mit allen semantischen Versions-Tags mit der Hauptversion 1 oder 2. | -`v1.10.1`<br/>-`v2.0.0` |
|
||||
| Muster | Beschreibung | Beispiele für Übereinstimmungen |
|
||||
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
|
||||
| `feature/*` | Das Platzhalterzeichen `*` steht für ein beliebiges Zeichen, nicht jedoch für den Schrägstrich (`/`). | -`feature/my-branch`<br/>-`feature/your-branch` |
|
||||
| `feature/**` | Das Platzhalterzeichen `**` steht für ein beliebiges Zeichen, also auch für den Schrägstrich (`/`), in Branch- und Tag-Namen. | -`feature/beta-a/my-branch`<br/>-`feature/your-branch`<br/>-`feature/mona/the/octocat` |
|
||||
| -`main`<br/>-`releases/mona-the-octcat` | Abgleich mit dem exakten Branch- oder Tag-Namen. | -`main`<br/>-`releases/mona-the-octocat` |
|
||||
| `'*'` | Abgleich mit allen Branch- und Tag-Namen, die keinen Schrägstrich (`/`) enthalten. Das Zeichen `*` ist ein Sonderzeichen in YAML. Wenn ein Muster mit `*` beginnen soll, sind Anführungszeichen erforderlich. | -`main`<br/>-`releases` |
|
||||
| `'**'` | Abgleich mit allen Branch- und Tag-Namen. Dies ist das Standardverhalten, wenn Sie keinen `branches`- oder `tags`-Filter angeben. | -`all/the/branches`<br/>-`every/tag` |
|
||||
| `'*feature'` | Das Zeichen `*` ist ein Sonderzeichen in YAML. Wenn ein Muster mit `*` beginnen soll, sind Anführungszeichen erforderlich. | -`mona-feature`<br/>-`feature`<br/>-`ver-10-feature` |
|
||||
| `v2*` | Abgleich mit Branch- und Tag-Namen, die mit `v2` beginnen. | -`v2`<br/>-`v2.0`<br/>-`v2.9` |
|
||||
| `v[12].[0-9]+.[0-9]+` | Abgleich mit allen semantischen Versions-Tags mit der Hauptversion 1 oder 2. | -`v1.10.1`<br/>-`v2.0.0` |
|
||||
|
||||
#### Muster für den Abgleich von Dateinamen
|
||||
|
||||
|
||||
@@ -45,6 +45,6 @@ Wenn ein Benutzer die Einladung akzeptiert, kann er sich anstatt über den IdP m
|
||||
|
||||
### Weiterführende Informationen
|
||||
|
||||
- „[LDAP verwenden](/enterprise/{{ currentVersion }}/admin/guides/user-management/using-ldap)“
|
||||
- „[LDAP verwenden](/enterprise/{{ page.version }}/admin/guides/user-management/using-ldap)“
|
||||
- „[SAML verwenden](/enterprise/{{ currentVersion }}/admin/guides/user-management/using-saml)“
|
||||
- „[CAS verwenden](/enterprise/{{ currentVersion }}/admin/guides/user-management/using-cas)“
|
||||
|
||||
@@ -5,7 +5,7 @@ redirect_from:
|
||||
- /enterprise/admin/articles/about-cas-authentication/
|
||||
- /enterprise/admin/user-management/using-cas
|
||||
- /enterprise/admin/authentication/using-cas
|
||||
intro: 'CAS ist ein Single Sign-On-Protokoll (SSO) für mehrere Webanwendungen. Ein CAS-Benutzerkonto übernimmt eine(n) {% if currentVersion ver_gt "enterprise-server@2.16" %}Benutzerlizenz{% else %}Benutzer{% endif %} erst nach Anmeldung des Benutzers.'
|
||||
intro: 'CAS ist ein Single Sign-On-Protokoll (SSO) für mehrere Webanwendungen. A CAS user account does not take up a {% if currentVersion ver_gt "enterprise-server@2.16" %}user license{% else %}seat{% endif %} until the user signs in.'
|
||||
versions:
|
||||
enterprise-server: '*'
|
||||
---
|
||||
@@ -25,8 +25,8 @@ versions:
|
||||
|
||||
Die folgenden Attribute sind verfügbar.
|
||||
|
||||
| Attributname | Typ | Beschreibung |
|
||||
| -------------- | ------------ | ------------------------------------------------------------------------- |
|
||||
| Attributname | Typ | Beschreibung |
|
||||
| -------------- | ------------ | -------------------------------------------------------------------- |
|
||||
| `Benutzername` | Erforderlich | Der {% data variables.product.prodname_ghe_server %}-Benutzername. |
|
||||
|
||||
### CAS konfigurieren
|
||||
|
||||
@@ -59,19 +59,19 @@ Verwenden Sie die folgenden Attribute, um die Konfiguration von LDAP für {% dat
|
||||
|
||||
| Attributname | Typ | Beschreibung |
|
||||
| ------------------------------------------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Host` | Erforderlich | Der LDAP-Host, z. B. `ldap.example.com` oder `10.0.0.30`. Wenn der Hostnamen nur in Ihrem internen Netzwerk verfügbar ist, müssen Sie möglicherweise zunächst den DNS von {% data variables.product.product_location_enterprise %} konfigurieren, damit der Hostname mithilfe Ihrer internen Nameserver aufgelöst werden kann. |
|
||||
| `Host` | Erforderlich | Der LDAP-Host, z. B. `ldap.example.com` oder `10.0.0.30`. Wenn der Hostnamen nur in Ihrem internen Netzwerk verfügbar ist, müssen Sie möglicherweise zunächst den DNS von {% data variables.product.product_location_enterprise %} konfigurieren, damit der Hostname mithilfe Ihrer internen Nameserver aufgelöst werden kann. |
|
||||
| `Port` | Erforderlich | Der Port, der von den LDAP-Diensten des Hosts überwacht wird. Beispiele: 389 und 636 (für LDAPS). |
|
||||
| `Encryption` | Erforderlich | Die Verschlüsselungsmethode, die verwendet wird, um Kommunikationen zum LDAP-Server zu schützen. Dazu zählen beispielsweise Nur-Text (keine Verschlüsselung), SSL/LDAPS (von Anfang an verschlüsselt) und StartTLS (Upgrade auf verschlüsselte Kommunikation nach dem Herstellen der Verbindung). |
|
||||
| `Domain search user` | Optional | Der LDAP-Benutzer, der Benutzernachschlagevorgänge durchführt, um andere Benutzer bei ihrer Anmeldung zu authentifizieren. In der Regel handelt es sich dabei um ein Dienstkonto, das speziell für Drittanbieterintegrationen erstellt wird. Verwenden Sie einen vollqualifizierten Namen, beispielsweise `cn=Administrator,cn=Users,dc=Example,dc=com`. Mit Active Directory können Sie zudem die Syntax `[DOMAIN]\[USERNAME]` (z. B. `WINDOWS\Administrator`) für den Benutzer der Domain-Suche mit Active Directory verwenden. |
|
||||
| `Domain search password` | Optional | Das Passwort für den Benutzer der Domain-Suche. |
|
||||
| `Administrators group` | Optional | Benutzer in dieser Gruppe werden auf Websiteadministratoren hochgestuft, wenn sie sich bei Ihrer Appliance anmelden. Wenn Sie keine Gruppe für LDAP-Administratoren konfigurieren, wird das erste LDAP-Benutzerkonto, das sich bei Ihrer Appliance anmeldet, automatisch auf einen Websiteadministrator hochgestuft. |
|
||||
| `Domain base` | Erforderlich | Der vollqualifizierte `Distinguished Name` (DN) einer LDAP-Unterstruktur, die auf Benutzer und Gruppen durchsucht werden soll. Sie können beliebig viele hinzufügen. Jede Gruppe muss jedoch in derselben Domain-Basis definiert sein wie die zugehörigen Benutzer. Wenn Sie eingeschränkte Benutzergruppen angeben, befinden sich nur die diesen Gruppen zugehörigen Benutzer im Geltungsbereich. Zum Steuern des Zugriffs sollten Sie die oberste Ebene Ihrer LDAP-Verzeichnisstruktur als Ihre Domain-Basis angeben und eingeschränkte Benutzergruppen verwenden. |
|
||||
| `Restricted user groups` | Optional | Wenn diese Option angegeben ist, können sich nur die Benutzer dieser Gruppen anmelden. Sie müssen nur die allgemeinen Namen (Common Names, CNs) der Gruppen angeben. Zudem können Sie beliebig viele Gruppen hinzufügen. Sind keine Gruppen angegeben, können sich *alle* Benutzer im Geltungsbereich der angegebenen Domain-Basis bei Ihrer {% data variables.product.prodname_ghe_server %}-Instanz anmelden. |
|
||||
| `User ID` | Erforderlich | Das LDAP-Attribut, das den LDAP-Benutzer identifiziert, der versucht, sich zu authentifizieren. Nach dem Herstellen einer Zuordnung können Benutzer ihre {% data variables.product.prodname_ghe_server %}-Benutzernamen ändern. Dieses Feld sollte für die meisten Active Directory-Installationen `sAMAccountName` lauten. Für andere LDAP-Lösungen wie OpenLDAP lautet es ggf. `uid`. Der Standardwert lautet `uid`. |
|
||||
| `Profilname` | Optional | Der Name, der auf der {% data variables.product.prodname_ghe_server %}-Profilseite des Benutzers angezeigt wird. Sofern die LDAP-Synchronisierung nicht aktiviert ist, können Benutzer ihre Profilnamen ändern. |
|
||||
| `Emails` | Optional | Die E-Mail-Adressen für das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers. |
|
||||
| `SSH keys` | Optional | Die öffentlichen SSH-Schlüssel, die an das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers angehängt sind. Die Schlüssel müssen im OpenSSH-Format vorliegen. |
|
||||
| `GPG keys` | Optional | Die GPG-Schlüssel, die an das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers angehängt sind. |
|
||||
| `Restricted user groups` | Optional | Wenn diese Option angegeben ist, können sich nur die Benutzer dieser Gruppen anmelden. Sie müssen nur die allgemeinen Namen (Common Names, CNs) der Gruppen angeben. Zudem können Sie beliebig viele Gruppen hinzufügen. Sind keine Gruppen angegeben, können sich *alle* Benutzer im Geltungsbereich der angegebenen Domain-Basis bei Ihrer {% data variables.product.prodname_ghe_server %}-Instanz anmelden. |
|
||||
| `User ID` | Erforderlich | Das LDAP-Attribut, das den LDAP-Benutzer identifiziert, der versucht, sich zu authentifizieren. Nach dem Herstellen einer Zuordnung können Benutzer ihre {% data variables.product.prodname_ghe_server %}-Benutzernamen ändern. Dieses Feld sollte für die meisten Active Directory-Installationen `sAMAccountName` lauten. Für andere LDAP-Lösungen wie OpenLDAP lautet es ggf. `uid`. Der Standardwert lautet `uid`. |
|
||||
| `Profilname` | Optional | Der Name, der auf der {% data variables.product.prodname_ghe_server %}-Profilseite des Benutzers angezeigt wird. Sofern die LDAP-Synchronisierung nicht aktiviert ist, können Benutzer ihre Profilnamen ändern. |
|
||||
| `Emails` | Optional | Die E-Mail-Adressen für das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers. |
|
||||
| `SSH keys` | Optional | Die öffentlichen SSH-Schlüssel, die an das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers angehängt sind. Die Schlüssel müssen im OpenSSH-Format vorliegen. |
|
||||
| `GPG keys` | Optional | Die GPG-Schlüssel, die an das {% data variables.product.prodname_ghe_server %}-Konto eines Benutzers angehängt sind. |
|
||||
| `Disable LDAP authentication for Git operations` | Optional | Wenn diese Option ausgewählt ist, wird die Möglichkeit der Benutzer [deaktiviert](#disabling-password-authentication-for-git-operations), LDAP-Passwörter zur Authentifizierung von Git-Vorgängen zu verwenden. |
|
||||
| `Enable LDAP certificate verification` | Optional | Wenn diese Option ausgewählt ist, wird die LDAP-Zertifikatsverifizierung [aktiviert](#enabling-ldap-certificate-verification). |
|
||||
| `Synchronization` | Optional | Wenn diese Option ausgewählt ist, wird die LDAP-Synchronisierung [aktiviert](#enabling-ldap-sync). |
|
||||
@@ -97,6 +97,12 @@ Wenn diese Option ausgewählt ist, wird das Zertifikat validiert, um Folgendes s
|
||||
|
||||
#### LDAP-Synchronisierung aktivieren
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Teams using LDAP Sync are limited to a maximum 1499 members.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Mithilfe der LDAP-Synchronisierung können Sie {% data variables.product.prodname_ghe_server %}-Benutzer und die -Teammitgliedschaft mit Ihren festgelegten LDAP-Gruppen synchronisieren. Dadurch können Sie eine rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) für Benutzer von Ihrem LDAP-Server aus einrichten, anstatt manuell innerhalb von {% data variables.product.prodname_ghe_server %}. Weitere Informationen finden Sie unter „[Teams erstellen](/enterprise/{{ currentVersion }}/admin/guides/user-management/creating-teams#creating-teams-with-ldap-sync-enabled)“.
|
||||
|
||||
Wählen Sie **Synchronize Emails** (E-Mails synchronisieren), **Synchronize SSH Keys** (SSH-Schlüssel synchronisieren) oder **Synchronize GPG Keys** (GPG-Schlüssel synchronisieren) aus, um die LDAP-Synchronisierung zu aktivieren.
|
||||
|
||||
@@ -54,15 +54,15 @@ Wenn Sie Ihren Identity Provider manuell konfigurieren möchten, lautet die Asse
|
||||
|
||||
Die folgenden Attribute sind verfügbar. Mit Ausnahme der `administrator`-Attribute können Sie die Attributnamen in der [Managementkonsole](/enterprise/{{ currentVersion }}/admin/guides/installation/accessing-the-management-console/) ändern.
|
||||
|
||||
| Standardmäßiger Attributname | Typ | Beschreibung |
|
||||
| ---------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Standardmäßiger Attributname | Typ | Beschreibung |
|
||||
| ---------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `NameID` | Erforderlich | Ein persistenter Benutzerkennzeichner. Es kann ein beliebiges Format für persistente Namenskennzeichner verwendet werden. Das Element `NameID` wird für einen {% data variables.product.prodname_ghe_server %}-Benutzernamen verwendet, sofern keine der alternativen Assertions bereitgestellt wird. |
|
||||
| `Administrator` | Optional | Wenn der Wert „true“ lautet, wird der Benutzer automatisch zu einem Administrator hochgestuft. Bei anderen oder nicht vorhandenen Werten wird der Benutzer auf ein normales Benutzerkonto zurückgestuft. |
|
||||
| `Administrator` | Optional | Wenn der Wert „true“ lautet, wird der Benutzer automatisch zu einem Administrator hochgestuft. Bei anderen oder nicht vorhandenen Werten wird der Benutzer auf ein normales Benutzerkonto zurückgestuft. |
|
||||
| `Benutzername` | Optional | Der {% data variables.product.prodname_ghe_server %}-Benutzername. |
|
||||
| `full_name` | Optional | Der Name des Benutzers, der auf seiner Profilseite angezeigt wird. Nach der Bereitstellung können Benutzer ihre Namen ändern. |
|
||||
| `emails` | Optional | Die E-Mail-Adressen für den Benutzer. Es können mehrere angegeben werden. |
|
||||
| `public_keys` | Optional | Die öffentlichen SSH-Schlüssel für den Benutzer. Es können mehrere angegeben werden. |
|
||||
| `gpg_keys` | Optional | Die GPG-Schlüssel für den Benutzer. Es können mehrere angegeben werden. |
|
||||
| `full_name` | Optional | Der Name des Benutzers, der auf seiner Profilseite angezeigt wird. Nach der Bereitstellung können Benutzer ihre Namen ändern. |
|
||||
| `emails` | Optional | Die E-Mail-Adressen für den Benutzer. Es können mehrere angegeben werden. |
|
||||
| `public_keys` | Optional | Die öffentlichen SSH-Schlüssel für den Benutzer. Es können mehrere angegeben werden. |
|
||||
| `gpg_keys` | Optional | Die GPG-Schlüssel für den Benutzer. Es können mehrere angegeben werden. |
|
||||
|
||||
### SAML-Einstellungen konfigurieren
|
||||
|
||||
@@ -88,7 +88,7 @@ Die folgenden Attribute sind verfügbar. Mit Ausnahme der `administrator`-Attrib
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
|
||||
### Zugriff auf {% data variables.product.product_location_enterprise %} widerrufen
|
||||
### Zugriff auf {{ site.data.variables.product.product_location_enterprise }} widerrufen
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
2. Wählen Sie **SAML** aus. 
|
||||
|
||||
@@ -20,7 +20,8 @@ Sie können diese Befehle überall in der VM ausführen, nachdem Sie sich als ei
|
||||
Dieses Dienstprogramm liegt im oberen Bereich jeder {% data variables.product.prodname_enterprise %}-Seite einen Banner fest. Diesen können Sie verwenden, um Ihren Benutzer eine Mitteilung zu übermitteln.
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
You can also set an announcement banner using the enterprise settings on {% data variables.product.product_name %}. Weitere Informationen finden Sie unter „[Benutzermeldungen auf Ihrer Instanz anpassen](/enterprise/admin/user-management/customizing-user-messages-on-your-instance#creating-a-global-announcement-banner)“.
|
||||
You can also set an announcement banner using the enterprise settings on
|
||||
{% data variables.product.product_name %}. Weitere Informationen finden Sie unter „[Benutzermeldungen auf Ihrer Instanz anpassen](/enterprise/admin/user-management/customizing-user-messages-on-your-instance#creating-a-global-announcement-banner)“.
|
||||
{% endif %}
|
||||
|
||||
```shell
|
||||
@@ -80,7 +81,7 @@ Dadurch können Sie den UUID Ihres Knotens in `cluster.conf` ermitteln.
|
||||
```
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
Allows you to exempt a list of users from API rate limits. For more information, see "[Rate Limiting](/enterprise/{{ currentVersion }}/v3/#rate-limiting)."
|
||||
Allows you to exempt a list of users from API rate limits. For more information, see "[Rate Limiting](/enterprise/{{ page.version }}/v3/#rate-limiting)."
|
||||
|
||||
``` shell
|
||||
$ ghe-config app.github.rate_limiting_exempt_users "<em>hubot</em> <em>github-actions</em>"
|
||||
@@ -181,7 +182,6 @@ Mit diesem Dienstprogramm können Sie den Wartungsmoduszustand der Installation
|
||||
ghe-maintenance -h
|
||||
```
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.17" %}
|
||||
#### ghe-motd
|
||||
|
||||
Dieses Dienstprogramm zeigt die Meldung des Tages (MOTD) an, die Administratoren sehen, wenn sie über die administrative Shell auf die Instanz zugreifen. Die Ausgabe enthält einen Überblick über den Status der Instanz.
|
||||
@@ -189,7 +189,6 @@ Dieses Dienstprogramm zeigt die Meldung des Tages (MOTD) an, die Administratoren
|
||||
```shell
|
||||
ghe-motd
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
#### ghe-nwo
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hostname konfigurieren
|
||||
intro: 'Es wird empfohlen, dass Sie einen Hostnamen für Ihre Appliance festlegen, anstatt eine hartcodierte IP-Adresse zu verwenden.'
|
||||
intro: Es wird empfohlen, dass Sie einen Hostnamen für Ihre Appliance festlegen, anstatt eine hartcodierte IP-Adresse zu verwenden.
|
||||
redirect_from:
|
||||
- /enterprise/admin/guides/installation/configuring-hostnames/
|
||||
- /enterprise/admin/installation/configuring-a-hostname
|
||||
|
||||
@@ -15,5 +15,7 @@ Sie können auswählen, wie lange {% data variables.product.product_location_ent
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
3. Klicke in der linken Seitenleiste auf **Applications** (Anwendungen). 
|
||||
4. Geben Sie unter „Avatar image cache time (seconds)“ (Avatarbild-Cache-Zeit (Sekunden)) ein, wie viele Sekunden {% data variables.product.product_location_enterprise %} Avatarbilder zwischenspeichern soll. 
|
||||
4. Under "Avatar image cache time (seconds)", type the number of seconds that you would like
|
||||
{% data variables.product.product_location_enterprise %} to cache avatar images.
|
||||
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
@@ -52,7 +52,7 @@ Die UWF-Firewall öffnet zudem verschiedene Ports, die für die ordnungsgemäße
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** Before you add custom firewall rules, back up your current rules in case you need to reset to a known working state. Falls Ihr Server für Sie gesperrt ist, kontaktieren Sie {% data variables.contact.contact_ent_support %}, um die ursprünglichen Firewallregeln neu zu konfigurieren. Die Wiederherstellung der ursprünglichen Firewallregeln führt zu Ausfallzeiten für Ihren Server.
|
||||
**Warnung:** Bevor Sie benutzerdefinierte Firewallregeln hinzufügen, sollten Sie Ihre aktuellen Regeln sichern, falls Sie in einen bekannten Betriebszustand zurückkehren müssen. Falls Ihr Server für Sie gesperrt ist, kontaktieren Sie {% data variables.contact.contact_ent_support %}, um die ursprünglichen Firewallregeln neu zu konfigurieren. Die Wiederherstellung der ursprünglichen Firewallregeln führt zu Ausfallzeiten für Ihren Server.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
@@ -74,7 +74,7 @@ Wenn nach dem Ändern der Firewallregeln ein Fehler auftritt, können Sie die Re
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** If you didn't back up the original rules before making changes to the firewall, contact {% data variables.contact.contact_ent_support %} for further assistance.
|
||||
**Warnung:** Falls Sie die ursprünglichen Regeln nicht gesichert haben, bevor Sie Änderungen an der Firewall vorgenommen haben, kontaktieren Sie {% data variables.contact.contact_ent_support %}, um weitere Unterstützung zu erhalten.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
|
||||
@@ -37,7 +37,9 @@ If you can't see **{% data variables.product.prodname_advanced_security %}** in
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
{% data reusables.enterprise_management_console.advanced-security-tab %}
|
||||
1. Under "{% data variables.product.prodname_advanced_security %}," click **{% data variables.product.prodname_code_scanning_capc %}**. 
|
||||
1. Under "
|
||||
{% data variables.product.prodname_advanced_security %}," click **{% data variables.product.prodname_code_scanning_capc %}**.
|
||||
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
|
||||
@@ -47,6 +49,8 @@ If you can't see **{% data variables.product.prodname_advanced_security %}** in
|
||||
|
||||
If you are enrolled in the {% data variables.product.prodname_actions %} beta, then {% data variables.product.prodname_ghe_server %} can run {% data variables.product.prodname_code_scanning %} using a {% data variables.product.prodname_actions %} workflow. First, you need to provision one or more self-hosted {% data variables.product.prodname_actions %} runners in your environment. You can provision self-hosted runners at the repository, organization, or enterprise account level. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."
|
||||
|
||||
You must ensure that Git is in the PATH variable on any self-hosted runners you use to run {% data variables.product.prodname_codeql %} actions.
|
||||
|
||||
#### Provisioning the action
|
||||
To run {% data variables.product.prodname_code_scanning %} on {% data variables.product.prodname_ghe_server %} with {% data variables.product.prodname_actions %}, the appropriate action must be available locally. You can make the action available in three ways.
|
||||
|
||||
@@ -67,7 +71,7 @@ After you configure a self-hosted runner, users can enable {% data variables.pro
|
||||
### Running {% data variables.product.prodname_code_scanning %} using the {% data variables.product.prodname_codeql_runner %}
|
||||
If your organization isn't taking part in the beta for {% data variables.product.prodname_actions %}, or if you don't want to use {% data variables.product.prodname_actions %}, you can run {% data variables.product.prodname_code_scanning %} using the {% data variables.product.prodname_codeql_runner %}.
|
||||
|
||||
The {% data variables.product.prodname_codeql_runner %} is a command-line tool that you can add to your third-party CI/CD system. The tool runs {% data variables.product.prodname_codeql %} analysis on a checkout of a {% data variables.product.prodname_dotcom %} repository. For more information, see "[Running {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)."
|
||||
The {% data variables.product.prodname_codeql_runner %} is a command-line tool that you can add to your third-party CI/CD system. The tool runs {% data variables.product.prodname_codeql %} analysis on a checkout of a {% data variables.product.prodname_dotcom %} repository. For more information, see "[Running {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-codeql-code-scanning-in-your-ci-system)."
|
||||
|
||||
### Disabling {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
@@ -76,5 +80,7 @@ The {% data variables.product.prodname_codeql_runner %} is a command-line tool t
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
{% data reusables.enterprise_management_console.advanced-security-tab %}
|
||||
1. Under "{% data variables.product.prodname_advanced_security %}", unselect **{% data variables.product.prodname_code_scanning_capc %}**. 
|
||||
1. Under "
|
||||
{% data variables.product.prodname_advanced_security %}", unselect **{% data variables.product.prodname_code_scanning_capc %}**.
|
||||
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
@@ -10,7 +10,7 @@ versions:
|
||||
|
||||
### Begrenzungen für {% data variables.product.prodname_enterprise_api %} aktivieren
|
||||
|
||||
Die Aktivierung von Begrenzungen auf {% data variables.product.prodname_enterprise_api %} kann verhindern, dass einzelne oder nicht authentifizierte Benutzer Ressourcen übermäßig verwenden. For more information, see "[Rate Limiting](/enterprise/{{ currentVersion }}/v3/#rate-limiting)."
|
||||
Die Aktivierung von Begrenzungen auf {% data variables.product.prodname_enterprise_api %} kann verhindern, dass einzelne oder nicht authentifizierte Benutzer Ressourcen übermäßig verwenden. For more information, see "[Rate Limiting](/enterprise/{{ page.version }}/v3/#rate-limiting)."
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
You can exempt a list of users from API rate limits using the `ghe-config` utility in the administrative shell. For more information, see "[Command-line utilities](/enterprise/admin/configuration/command-line-utilities#ghe-config)."
|
||||
|
||||
@@ -8,7 +8,15 @@ versions:
|
||||
enterprise-server: '*'
|
||||
---
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** We do not support adding additional network adapters to {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.enterprise_installation.open-vm-console-start %}
|
||||
3. Wählen Sie aus, dass `IPv4`- oder `IPv6`-Protokoll zu konfigurieren. 
|
||||
4. Konfigurieren Sie die Optionen für das gewünschte Protokoll. 
|
||||
{% data reusables.enterprise_installation.vm-console-done %}
|
||||
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ Um TLS in der Produktion zu verwenden, müssen Sie über ein Zertifikat verfüge
|
||||
|
||||
Darüber hinaus schreibt Ihr Zertifikat Subject Alternative Names vor, die für die in „[Subdomain-Isolation aktivieren](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-subdomain-isolation#about-subdomain-isolation)“ aufgelisteten Subdomains konfiguriert sind, und es muss die gesamte Zertifikatskette enthalten, wenn es von einer zwischengeschalteten Zertifizierungsstelle signiert wurde. Weitere Informationen finden Sie unter „[Subject Alternative Name](http://en.wikipedia.org/wiki/SubjectAltName)“ auf Wikipedia.
|
||||
|
||||
Du kannst mit dem Befehl `ghe-ssl-generate-csr` eine Anfrage zur Signierung des Zertifikats (CSR) für Deine Instanz erzeugen. Weitere Informationen findest Du unter „[Befehlszeilen-Hilfsprogramme](/enterprise/{{ currentVersion }}/admin/guides/installation/command-line-utilities/#ghe-ssl-generate-csr)“.
|
||||
Du kannst mit dem Befehl `ghe-ssl-generate-csr` eine Anfrage zur Signierung des Zertifikats (CSR) für Deine Instanz erzeugen. Weitere Informationen finden Sie unter „[Befehlszeilenprogramme](/enterprise/{{ currentVersion }}/admin/guides/installation/command-line-utilities/#ghe-ssl-generate-csr)“.
|
||||
|
||||
### Benutzerdefiniertes TLS-Zertifikat hochladen
|
||||
|
||||
|
||||
@@ -37,12 +37,12 @@ Wenn Du {% data variables.product.prodname_github_connect %} aktivierst, wird zu
|
||||
|
||||
Wenn {% data variables.product.prodname_github_connect %} aktiviert wird, können {% data variables.product.prodname_dotcom_the_website %}-Benutzer keine Änderungen an {% data variables.product.prodname_ghe_server %} vornehmen.
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.18" %}
|
||||
For more information about managing enterprise accounts using the GraphQL API, see "[Enterprise accounts](/v4/guides/managing-enterprise-accounts)."
|
||||
{% endif %}
|
||||
### {% data variables.product.prodname_github_connect %} aktivieren
|
||||
|
||||
1. Melden Sie sich bei {% data variables.product.product_location_enterprise %} und {% data variables.product.prodname_dotcom_the_website %} an.
|
||||
1. Sign in to
|
||||
|
||||
{% data variables.product.product_location_enterprise %} and {% data variables.product.prodname_dotcom_the_website %}.
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.business %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
|
||||
@@ -5,7 +5,6 @@ redirect_from:
|
||||
- /enterprise/admin/installation/enabling-security-alerts-for-vulnerable-dependencies-on-github-enterprise-server
|
||||
- /enterprise/admin/configuration/enabling-security-alerts-for-vulnerable-dependencies-on-github-enterprise-server
|
||||
- /enterprise/admin/configuration/enabling-alerts-for-vulnerable-dependencies-on-github-enterprise-server
|
||||
- /enterprise/admin/configuration/enabling-alerts-for-vulnerable-dependencies-on-github-enterprise-server
|
||||
permissions: 'Site administrators for {% data variables.product.prodname_ghe_server %} who are also owners of the connected {% data variables.product.prodname_ghe_cloud %} organization or enterprise account can enable {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts for vulnerable dependencies on {% data variables.product.prodname_ghe_server %}.'
|
||||
versions:
|
||||
enterprise-server: '*'
|
||||
@@ -17,23 +16,23 @@ versions:
|
||||
|
||||
You can connect {% data variables.product.product_location_enterprise %} to {% data variables.product.prodname_dotcom_the_website %}, then sync vulnerability data to your instance and generate {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts in repositories with a vulnerable dependency.
|
||||
|
||||
After connecting {% data variables.product.product_location_enterprise %} to {% data variables.product.prodname_dotcom_the_website %} and enabling {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts for vulnerable dependencies, vulnerability data is synced from {% data variables.product.prodname_dotcom_the_website %} to your instance once every hour. You can also choose to manually sync vulnerability data at any time. No code or information about code from {% data variables.product.product_location_enterprise %} is uploaded to {% data variables.product.prodname_dotcom_the_website %}.
|
||||
After connecting {% data variables.product.product_location_enterprise %} to {% data variables.product.prodname_dotcom_the_website %} and enabling {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts for vulnerable dependencies, vulnerability data is synced from {% data variables.product.prodname_dotcom_the_website %} to your instance once every hour. Sie können die Schwachstellendaten auch jederzeit manuell synchronisieren. Es werden weder Code noch Informationen zu Code von {% data variables.product.product_location_enterprise %} auf {% data variables.product.prodname_dotcom_the_website %} hochgeladen.
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}When {% data variables.product.product_location_enterprise %} receives information about a vulnerability, it will identify repositories in your instance that use the affected version of the dependency and send {% data variables.product.prodname_dependabot_short %} alerts to owners and people with admin access in those repositories. They can customize how they receive {% data variables.product.prodname_dependabot_short %} alerts. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies/#configuring-notifications-for-github-dependabot-alerts)."
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}When {% data variables.product.product_location_enterprise %} receives information about a vulnerability, it will identify repositories in your instance that use the affected version of the dependency and send {% data variables.product.prodname_dependabot_short %} alerts to owners and people with admin access in those repositories. They can customize how they receive {% data variables.product.prodname_dependabot_short %} alerts. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies/#configuring-notifications-for-github-dependabot-alerts)." |
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion ver_lt "enterprise-server@2.21" or currentVersion == "enterprise-server@2.21" %}When {% data variables.product.product_location_enterprise %} receives information about a vulnerability, it will identify repositories in your instance that use the affected version of the dependency and send security alerts to owners and people with admin access in those repositories. They can customize how they receive security alerts. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies/#configuring-notifications-for-security-alerts)."
|
||||
{% if currentVersion ver_lt "enterprise-server@2.21" or currentVersion == "enterprise-server@2.21" %}When {% data variables.product.product_location_enterprise %} receives information about a vulnerability, it will identify repositories in your instance that use the affected version of the dependency and send security alerts to owners and people with admin access in those repositories. Sie können anpassen, wie sie Sicherheitsmeldungen empfangen möchten. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies/#configuring-notifications-for-security-alerts)." |
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
### Enabling {% data variables.product.prodname_dependabot_short %} alerts for vulnerable dependencies on {% data variables.product.prodname_ghe_server %}
|
||||
{% else %}
|
||||
### Enabling security alerts for vulnerable dependencies on {% data variables.product.prodname_ghe_server %}
|
||||
### Sicherheitsmeldungen für angreifbare Abhängigkeiten auf {% data variables.product.prodname_ghe_server %} aktivieren
|
||||
{% endif %}
|
||||
|
||||
Before enabling {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts for vulnerable dependencies on {% data variables.product.product_location_enterprise %}, you must connect {% data variables.product.product_location_enterprise %} to {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[Connecting {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_ghe_cloud %}](/enterprise/{{ currentVersion }}/admin/guides/installation/connecting-github-enterprise-server-to-github-enterprise-cloud)."
|
||||
Before enabling {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot_short %}{% else %}security{% endif %} alerts for vulnerable dependencies on {% data variables.product.product_location_enterprise %}, you must connect {% data variables.product.product_location_enterprise %} to {% data variables.product.prodname_dotcom_the_website %}. Weitere Informationen finden Sie unter „[{% data variables.product.prodname_ghe_server %} mit {% data variables.product.prodname_ghe_cloud %} verbinden](/enterprise/{{ currentVersion }}/admin/guides/installation/connecting-github-enterprise-server-to-github-enterprise-cloud)“.
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.20" %}
|
||||
{% if currentVersion ver_gt "enterprise-server@2.20" %}
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}We recommend configuring {% data variables.product.prodname_dependabot_short %} alerts without notifications for the first few days to avoid an overload of emails. After a few days, you can enable notifications to receive {% data variables.product.prodname_dependabot_short %} alerts as usual.{% endif %}
|
||||
|
||||
@@ -46,22 +45,21 @@ Before enabling {% if currentVersion ver_gt "enterprise-server@2.21" %}{% data v
|
||||
``` shell
|
||||
$ ghe-dep-graph-enable
|
||||
```
|
||||
3. Return to {% data variables.product.prodname_ghe_server %}.
|
||||
3. Return to
|
||||
{% data variables.product.prodname_ghe_server %}.
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.business %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.github-connect-tab %}{% if currentVersion ver_gt "enterprise-server@2.20" %}
|
||||
5. Under "Repositories can be scanned for vulnerabilities", use the drop-down menu and select **Enabled without notifications**. Optionally, to enable alerts with notifications, select **Enabled with notifications**.{% else %}
|
||||
5. Under "Repositories can be scanned for vulnerabilities", use the drop-down menu and select **Enabled**.
|
||||
5. Verwenden Sie unter „Repositories can be scanned for vulnerabilities“ (Repositorys können auf Schwachstellen überprüft werden) das Dropdownmenü, und wählen Sie **Enabled** (Aktiviert) aus.
|
||||
{% endif %}
|
||||
|
||||
|
||||
|
||||
### Viewing vulnerable dependencies on {% data variables.product.prodname_ghe_server %}
|
||||
### Angreifbare Abhängigkeiten auf {% data variables.product.prodname_ghe_server %} anzeigen
|
||||
|
||||
You can view all vulnerabilities in {% data variables.product.product_location_enterprise %} and manually sync vulnerability data from {% data variables.product.prodname_dotcom_the_website %} to update the list.
|
||||
Sie können alle Schwachstellen in {% data variables.product.product_location_enterprise %} anzeigen und Schwachstellendaten von {% data variables.product.prodname_dotcom_the_website %} manuell synchronisieren, um die Liste zu aktualisieren.
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
2. In the left sidebar, click **Vulnerabilities**.
|
||||
|
||||
3. To sync vulnerability data, click **Sync Vulnerabilities now**.
|
||||
|
||||
2. Klicken Sie auf der linken Seitenleiste auf **Vulnerabilities** (Schwachstellen). 
|
||||
3. Klicken Sie zum Synchronisieren von Schwachstellendaten auf **Sync Vulnerabilities now** (Schwachstellen jetzt synchronisieren). 
|
||||
|
||||
@@ -16,28 +16,29 @@ Die Subdomain-Isolation mindert Cross-Site-Scripting und andere verwandte Schwac
|
||||
Bei aktivierter Subdomain-Isolation ersetzt {% data variables.product.prodname_ghe_server %} verschiedene Pfade durch Subdomains.
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
To use Docker with {% data variables.product.prodname_registry %}, you must also enable subdomain isolation. For more information, see "[Configuring Docker for use with {% data variables.product.prodname_registry %}](/enterprise/{{ currentVersion }}/user/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages)."
|
||||
To use Docker with
|
||||
{% data variables.product.prodname_registry %}, you must also enable subdomain isolation. For more information, see "[Configuring Docker for use with {% data variables.product.prodname_registry %}](/enterprise/{{ currentVersion }}/user/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages)."
|
||||
|
||||
{% data reusables.package_registry.packages-ghes-release-stage %}
|
||||
|
|
||||
{% endif %}
|
||||
| Pfad ohne Subdomain-Isolation | Pfad mit Subdomain-Isolation |
|
||||
| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
| `http(s)://HOSTNAME/assets/` | `http(s)://assets.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/avatars/` | `http(s)://avatars.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/codeload/` | `http(s)://codeload.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/gist/` | `http(s)://gist.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/media/` | `http(s)://media.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/pages/` | `http(s)://pages.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/raw/` | `http(s)://raw.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/render/` | `http(s)://render.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/reply/` | `http(s)://reply.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/uploads/` | `http(s)://uploads.HOSTNAME/` |{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
| N/A, Docker with {% data variables.product.prodname_registry %} will not work with subdomain isolation disabled. | `http(s)://uploads.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/npm/` | `https://npm.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/rubygems/` | `https://rubygems.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/maven/` | `https://maven.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/nuget/` | `https://nuget.HOSTNAME/`{% endif %}
|
||||
| Pfad ohne Subdomain-Isolation | Pfad mit Subdomain-Isolation |
|
||||
| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| `http(s)://HOSTNAME/assets/` | `http(s)://assets.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/avatars/` | `http(s)://avatars.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/codeload/` | `http(s)://codeload.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/gist/` | `http(s)://gist.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/media/` | `http(s)://media.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/pages/` | `http(s)://pages.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/raw/` | `http(s)://raw.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/render/` | `http(s)://render.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/reply/` | `http(s)://reply.HOSTNAME/` |
|
||||
| `http(s)://HOSTNAME/uploads/` | `http(s)://uploads.HOSTNAME/` |{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
| N/A, Docker with {% data variables.product.prodname_registry %} will not work with subdomain isolation disabled. | `http(s)://uploads.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/npm/` | `https://npm.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/rubygems/` | `https://rubygems.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/maven/` | `https://maven.HOSTNAME/` |
|
||||
| `https://HOSTNAME/_registry/nuget/` | `https://nuget.HOSTNAME/`{% endif %}
|
||||
|
||||
### Vorrausetzungen
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ versions:
|
||||
{% topic_link_in_list /managing-connections-between-github-enterprise-server-and-github-enterprise-cloud %}
|
||||
{% link_in_list /connecting-github-enterprise-server-to-github-enterprise-cloud %}
|
||||
{% link_in_list /enabling-unified-search-between-github-enterprise-server-and-githubcom %}
|
||||
{% link_in_list /enabling-unified-contributions-between-github-enterprise-server-and-githubcom %}
|
||||
{% link_in_list /enabling-unified-contributions-between-github-enterprise-server-and-githubcom %}
|
||||
<!-- if currentVersion ver_gt "enterprise-server@2.16" -->
|
||||
{% link_in_list /enabling-security-alerts-for-vulnerable-dependencies-on-github-enterprise-server %}
|
||||
{% link_in_list /enabling-automatic-user-license-sync-between-github-enterprise-server-and-github-enterprise-cloud %}
|
||||
@@ -49,3 +49,11 @@ versions:
|
||||
{% topic_link_in_list /configuring-advanced-security-features %}
|
||||
{% link_in_list /configuring-code-scanning-for-your-appliance %}
|
||||
<!-- endif -->
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
{% note %}
|
||||
|
||||
**Note:** To configure {% data variables.product.prodname_actions %} or {% data variables.product.prodname_registry %} for your enterprise, see "[Managing GitHub Actions for your enterprise](/admin/github-actions)" or "[Managing GitHub Packages for your enterprise](/admin/packages)."
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
@@ -16,25 +16,25 @@ versions:
|
||||
|
||||
Einige Verwaltungsports sind zum Konfigurieren von {% data variables.product.product_location_enterprise %} und zum Ausführen bestimmter Features erforderlich. Verwaltungsports sind für die einfache Verwendung von Anwendungen durch Endbenutzer nicht erforderlich.
|
||||
|
||||
| Port | Dienst | Beschreibung |
|
||||
| -------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Port | Dienst | Beschreibung |
|
||||
| -------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 8443 | HTTPS | Sichere webbasierte {% data variables.enterprise.management_console %}. Für die grundlegende Installation und Konfiguration erforderlich. |
|
||||
| 8080 | HTTP | Webbasierte {% data variables.enterprise.management_console %} im Nur-Text-Format. Nur erforderlich, wenn SSL manuell deaktiviert wird. |
|
||||
| 122 | SSH | Shellzugriff für {% data variables.product.product_location_enterprise %}. Muss für eingehende Verbindungen von allen anderen Knoten in einer Hochverfügbarkeitskonfiguration geöffnet sein. Der standardmäßige SSH-Port (22) ist für den Git- und SSH-Netzwerk-Traffic der Anwendung vorgesehen. |
|
||||
| 1194/UDP | VPN | Sicherer Replikationsnetzwerktunnel in einer hochverfügbaren Konfiguration. Muss für alle anderen Knoten in der Konfiguration geöffnet sein. |
|
||||
| 123/UDP | NTP | Für Zeitprotokollvorgänge erforderlich. |
|
||||
| 161/UDP | SNMP | Für Netzwerküberwachungs-Protokollvorgänge erforderlich. |
|
||||
| 1194/UDP | VPN | Sicherer Replikationsnetzwerktunnel in einer hochverfügbaren Konfiguration. Muss für alle anderen Knoten in der Konfiguration geöffnet sein. |
|
||||
| 123/UDP | NTP | Für Zeitprotokollvorgänge erforderlich. |
|
||||
| 161/UDP | SNMP | Für Netzwerküberwachungs-Protokollvorgänge erforderlich. |
|
||||
|
||||
### Anwendungsports für Endbenutzer
|
||||
|
||||
Mit Anwendungsports können Endbenutzer auf Webanwendungen und Git zugreifen.
|
||||
|
||||
| Port | Dienst | Beschreibung |
|
||||
| ---- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 443 | HTTPS | Zugriff auf die Webanwendung und Git über HTTPS. |
|
||||
| 80 | HTTP | Webanwendungszugriff. Alle Anforderungen werden an den HTTPS-Port weitergeleitet, wenn SSL aktiviert ist. |
|
||||
| 22 | SSH | Zugriff auf Git über SSH. Unterstützt das Klonen, Abrufen und Übertragen von Vorgängen an öffentliche/private Repositorys. |
|
||||
| 9418 | Git | Der Git-Protokollport unterstützt das Klonen und Abrufen von Vorgängen für öffentliche Repositorys mit unverschlüsselter Netzwerkkommunikation. |
|
||||
| Port | Dienst | Beschreibung |
|
||||
| ---- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 443 | HTTPS | Zugriff auf die Webanwendung und Git über HTTPS. |
|
||||
| 80 | HTTP | Webanwendungszugriff. Alle Anforderungen werden an den HTTPS-Port weitergeleitet, wenn SSL aktiviert ist. |
|
||||
| 22 | SSH | Zugriff auf Git über SSH. Unterstützt das Klonen, Abrufen und Übertragen von Vorgängen an öffentliche/private Repositorys. |
|
||||
| 9418 | Git | Der Git-Protokollport unterstützt das Klonen und Abrufen von Vorgängen für öffentliche Repositorys mit unverschlüsselter Netzwerkkommunikation. {% data reusables.enterprise_installation.when-9418-necessary %}
|
||||
|
||||
{% data reusables.enterprise_installation.terminating-tls %}
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ Klicken Sie in der oberen rechten Ecke einer beliebigen Seite auf {% octicon "ro
|
||||
|
||||
### Suche
|
||||
|
||||
Hier können Sie die {% data variables.enterprise.management_console %} starten, um die Einstellungen der virtuellen Appliance zu verwalten, also beispielsweise die Domain, die Authentifizierung und SSL.
|
||||
Hier können Sie die {{ site.data.variables.enterprise.management_console }} starten, um die Einstellungen der virtuellen Appliance zu verwalten, also beispielsweise die Domain, die Authentifizierung und SSL.
|
||||
|
||||
{% else %}
|
||||
|
||||
@@ -162,7 +162,7 @@ Dadurch wird gesteuert, wie der [Issues][]-Index repariert wird. Sie können
|
||||
|
||||
### Alle Benutzer
|
||||
|
||||
Hier können Sie alle Benutzer anzeigen, die auf {% data variables.product.product_location_enterprise %} gesperrt wurden, und [eine SSH-Schlüsselüberwachung initiieren](/enterprise/{{ currentVersion }}/admin/guides/user-management/auditing-ssh-keys).
|
||||
Hier können Sie alle Benutzer anzeigen, die auf {{ site.data.variables.product.product_location_enterprise }} gesperrt wurden, und [eine SSH-Schlüsselüberwachung initiieren](/enterprise/{{ page.version }}/admin/guides/user-management/auditing-ssh-keys).
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Damit die Geo-Replikation ordnungsgemäß funktioniert, ist Geo DNS, beispielswe
|
||||
|
||||
### Einschränkungen
|
||||
|
||||
Zum Senden von Anforderungen an das Replikat müssen die Daten an die primäre Instanz und an alle Replikate gesendet werden. Folglich ist die Leistung sämtlicher Schreibvorgänge auf das langsamste Replikat begrenzt{% if currentVersion ver_gt "enterprise-server@2.17" %}, wobei neue Geo-Replikate ein Seeding für den Großteil ihrer Daten von bestehenden Geo-Replikaten mit gleichem Speicherort aus anstatt von der primären Instanz aus ausführen können{% endif %}. Von der Geo-Replikation werden einer {% data variables.product.prodname_ghe_server %}-Instanz weder Kapazitäten hinzugefügt noch werden Leistungsprobleme in Bezug auf unzureichende CPU- oder Arbeitsspeicherressourcen behoben. Wenn die primäre Appliance offline ist, können aktive Replikate keine Lese- oder Schreibanforderungen verarbeiten.
|
||||
Zum Senden von Anforderungen an das Replikat müssen die Daten an die primäre Instanz und an alle Replikate gesendet werden. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Von der Geo-Replikation werden einer {% data variables.product.prodname_ghe_server %}-Instanz weder Kapazitäten hinzugefügt noch werden Leistungsprobleme in Bezug auf unzureichende CPU- oder Arbeitsspeicherressourcen behoben. Wenn die primäre Appliance offline ist, können aktive Replikate keine Lese- oder Schreibanforderungen verarbeiten.
|
||||
|
||||
### Geo-Replikationskonfiguration überwachen
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ Verwenden Sie zum Verwalten der Replikation auf {% data variables.product.prodna
|
||||
|
||||
Der Befehl `ghe-repl-setup` versetzt eine {% data variables.product.prodname_ghe_server %}-Appliance in den Replikat-Standbymodus.
|
||||
|
||||
- Ein verschlüsselter {% if currentVersion ver_gt "enterprise-server@2.17" %}WireGuard-VPN{% else %}Open-VPN{% endif %}-Tunnel ist für die Kommunikation zwischen den beiden Appliances konfiguriert.
|
||||
- An encrypted WireGuard VPN tunnel is configured for communication between the two appliances.
|
||||
- Datenbankdienste werden für die Replikation konfiguriert und gestartet.
|
||||
- Anwendungsdienste werden deaktiviert. Wenn versucht wird, über HTTP, Git oder über andere unterstützte Protokolle auf die Replikat-Appliance zuzugreifen, wird die Wartungsseite „appliance in replica mode“ (Appliance im Replikatmodus) oder eine Fehlermeldung angezeigt.
|
||||
|
||||
@@ -71,8 +71,7 @@ Run `ghe-repl-start' to start replicating against the newly configured primary.
|
||||
Der Befehl `ghe-repl-start` aktiviert die aktive Replikation sämtlicher Datenspeicher.
|
||||
|
||||
```shell
|
||||
admin@169-254-1-2:~$ ghe-repl-start{% if currentVersion ver_lt "enterprise-server@2.18" %}
|
||||
Starting OpenVPN tunnel ... {% endif %}
|
||||
admin@169-254-1-2:~$ ghe-repl-start
|
||||
Starting MySQL replication ...
|
||||
Starting Redis replication ...
|
||||
Starting Elasticsearch replication ...
|
||||
@@ -144,8 +143,7 @@ Stopping Pages replication ...
|
||||
Stopping Git replication ...
|
||||
Stopping MySQL replication ...
|
||||
Stopping Redis replication ...
|
||||
Stopping Elasticsearch replication ...{% if currentVersion ver_lt "enterprise-server@2.18" %}
|
||||
Stopping OpenVPN tunnel ...{% endif %}
|
||||
Stopping Elasticsearch replication ...
|
||||
Success: replication was stopped for all services.
|
||||
```
|
||||
|
||||
@@ -163,8 +161,7 @@ Stopping replication ...
|
||||
| Stopping Git replication ...
|
||||
| Stopping MySQL replication ...
|
||||
| Stopping Redis replication ...
|
||||
| Stopping Elasticsearch replication ...{% if currentVersion ver_lt "enterprise-server@2.18" %}
|
||||
| Stopping OpenVPN tunnel ...{% endif %}
|
||||
| Stopping Elasticsearch replication ...
|
||||
| Success: replication was stopped for all services.
|
||||
Switching out of replica mode ...
|
||||
| Success: Replication configuration has been removed.
|
||||
|
||||
@@ -24,10 +24,10 @@ versions:
|
||||
|
||||
Mit dem Überwachungs-Dashboard können Sie in Bezug auf den Ressourcenzustand Ihrer Appliance auf dem Laufenden bleiben und Entscheidungen treffen, wie Sie Probleme hinsichtlich hoher Nutzungen beheben können.
|
||||
|
||||
| Problem | Mögliche Ursache(n) | Empfehlungen |
|
||||
| ----------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Hohe CPU-Auslastung | VM-Konflikte von anderen auf demselben Host ausgeführten Diensten oder Programmen | Konfigurieren Sie nach Möglichkeit andere Dienste oder Programme so neu, dass sie weniger CPU-Ressourcen beanspruchen. Informationen zum Erhöhen der CPU-Gesamtressourcen für die VM finden Sie unter „[CPU- und Arbeitsspeicherressourcen erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-cpu-or-memory-resources/)“. |
|
||||
| Hohe Arbeitsspeicherauslastung | VM-Konflikte von anderen auf demselben Host ausgeführten Diensten oder Programmen | Konfigurieren Sie nach Möglichkeit andere Dienste oder Programme so, dass sie weniger Arbeitsspeicher beanspruchen. Informationen zum Erhöhen des insgesamt auf der VM verfügbaren Arbeitsspeichers finden Sie unter „[CPU- und Arbeitsspeicherressourcen erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-cpu-or-memory-resources/)“. |
|
||||
| Niedrige Festplattenspeicherverfügbarkeit | Große Binärdateien oder Protokolldateien, die Festplattenspeicher nutzen | Hosten Sie große Binärdateien nach Möglichkeit auf einem separaten Server, und komprimieren oder archivieren Sie Protokolldateien. Erhöhen Sie ggf. den Festplattenspeicher auf der VM. Befolgen Sie dazu die unter „[Speicherkapazität erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-storage-capacity/)“ für Ihre Plattform angegebenen Schritte. |
|
||||
| Ungewöhnlich hohe Antwortzeiten | Wird oft durch einen der obigen Issues verursacht | Identifizieren und beheben Sie die zugrunde liegenden Issues. Kontaktieren Sie {% data variables.contact.contact_ent_support %}, falls die Antwortzeiten hoch bleiben. |
|
||||
| Problem | Mögliche Ursache(n) | Empfehlungen |
|
||||
| ----------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Hohe CPU-Auslastung | VM-Konflikte von anderen auf demselben Host ausgeführten Diensten oder Programmen | Konfigurieren Sie nach Möglichkeit andere Dienste oder Programme so neu, dass sie weniger CPU-Ressourcen beanspruchen. Informationen zum Erhöhen der CPU-Gesamtressourcen für die VM finden Sie unter „[CPU- und Arbeitsspeicherressourcen erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-cpu-or-memory-resources/)“. |
|
||||
| Hohe Arbeitsspeicherauslastung | VM-Konflikte von anderen auf demselben Host ausgeführten Diensten oder Programmen | Konfigurieren Sie nach Möglichkeit andere Dienste oder Programme so, dass sie weniger Arbeitsspeicher beanspruchen. Informationen zum Erhöhen des insgesamt auf der VM verfügbaren Arbeitsspeichers finden Sie unter „[CPU- und Arbeitsspeicherressourcen erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-cpu-or-memory-resources/)“. |
|
||||
| Niedrige Festplattenspeicherverfügbarkeit | Große Binärdateien oder Protokolldateien, die Festplattenspeicher nutzen | Hosten Sie große Binärdateien nach Möglichkeit auf einem separaten Server, und komprimieren oder archivieren Sie Protokolldateien. Erhöhen Sie ggf. den Festplattenspeicher auf der VM. Befolgen Sie dazu die unter „[Speicherkapazität erhöhen](/enterprise/{{ currentVersion }}/admin/guides/installation/increasing-storage-capacity/)“ für Ihre Plattform angegebenen Schritte. |
|
||||
| Ungewöhnlich hohe Antwortzeiten | Wird oft durch einen der obigen Issues verursacht | Identifizieren und beheben Sie die zugrunde liegenden Issues. Kontaktieren Sie {% data variables.contact.contact_ent_support %}, falls die Antwortzeiten hoch bleiben. |
|
||||
| Erhöhte Fehlerraten | Software-Issues | Kontaktieren Sie {% data variables.contact.contact_ent_support %}, und fügen Sie Ihr Support-Bundle hinzu. Weitere Informationen finden Sie unter „[Daten für den {% data variables.product.prodname_enterprise %}-Support bereitstellen](/enterprise/{{ currentVersion}}/admin/guides/enterprise-support/providing-data-to-github-support#creating-and-sharing-support-bundles)“. |
|
||||
|
||||
@@ -71,7 +71,6 @@ Wenn sich zwischen Knoten eine Firewall auf Netzwerkebene befindet, müssen dies
|
||||
| 8302/UDP | Consul |
|
||||
| 25827/UDP | Collectd |
|
||||
|
||||
|
||||
### Load-Balancer konfigurieren
|
||||
|
||||
Sie sollten einen externen TCP-basierten Load-Balancer verwenden, der das PROXY-Protokoll unterstützt, um den Traffic auf die Knoten zu verteilen. Beachten Sie die folgenden Load-Balancer-Konfigurationen:
|
||||
|
||||
@@ -49,7 +49,7 @@ Diese Beispielkonfiguration verwendet eine primäre Instanz und zwei Replikate,
|
||||
(replica2)$ ghe-repl-setup --add <em>PRIMARY IP</em>
|
||||
(replica2)$ ghe-repl-start
|
||||
```
|
||||
3. Standardmäßig sind Replikate für das gleiche Rechenzentrum konfiguriert{% if currentVersion ver_gt "enterprise-server@2.17" %} und versuchen nun, ein Seeding von einem vorhandenen Knoten im gleichen Rechenzentrum aus auszuführen{% endif %}. Konfigurieren Sie die Replikate für unterschiedliche Rechenzentren, indem Sie für die Rechenzentrumsoption einen anderen Wert festlegen. Die entsprechenden Werte sind beliebig, sie müssen sich nur voneinander unterscheiden. Führen Sie den Befehl `ghe-repl-node` auf jedem Knoten aus, und geben Sie das Rechenzentrum an.
|
||||
3. By default, replicas are configured to the same datacenter, and will now attempt to seed from an existing node in the same datacenter. Konfigurieren Sie die Replikate für unterschiedliche Rechenzentren, indem Sie für die Rechenzentrumsoption einen anderen Wert festlegen. Die entsprechenden Werte sind beliebig, sie müssen sich nur voneinander unterscheiden. Führen Sie den Befehl `ghe-repl-node` auf jedem Knoten aus, und geben Sie das Rechenzentrum an.
|
||||
|
||||
Auf der primären Instanz:
|
||||
```shell
|
||||
|
||||
@@ -8,7 +8,7 @@ versions:
|
||||
---
|
||||
|
||||
|
||||
### Table of Contents
|
||||
### Inhaltsverzeichnis
|
||||
|
||||
{% topic_link_in_list /monitoring-your-appliance %}
|
||||
{% link_in_list /accessing-the-monitor-dashboard %}
|
||||
@@ -16,8 +16,7 @@ versions:
|
||||
{% link_in_list /setting-up-external-monitoring %}
|
||||
{% link_in_list /configuring-collectd %}
|
||||
{% link_in_list /log-forwarding %}
|
||||
{% link_in_list /monitoring-using-snmp %}{% if currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
{% link_in_list /monitoring-using-analytics %}{% endif %}
|
||||
{% link_in_list /monitoring-using-snmp %}
|
||||
{% topic_link_in_list /updating-the-virtual-machine-and-physical-resources %}
|
||||
{% link_in_list /upgrade-requirements %}
|
||||
{% link_in_list /upgrading-github-enterprise-server %}
|
||||
|
||||
@@ -1,15 +1,16 @@
|
||||
---
|
||||
title: Monitoring cluster nodes
|
||||
intro: 'A {% data variables.product.prodname_ghe_server %} cluster is comprised of redundant services that are distributed across two or more nodes. If an individual service or an entire node were to fail, it should not be immediately apparent to users of the cluster. However since performance and redundancy are affected, it is important to monitor the health of a {% data variables.product.prodname_ghe_server %} cluster.'
|
||||
title: Clusterknoten überwachen
|
||||
intro: 'Ein {% data variables.product.prodname_ghe_server %}-Cluster besteht aus redundanten Diensten, die auf mindestens zwei Knoten verteilt sind. Wenn ein einzelner Dienst oder ein gesamter Knoten fehlschlägt, sollte dies den Benutzern des Clusters sofort auffallen. Da jedoch Leistung und Redundanz betroffen sind, ist es wichtig, den Zustand eines {% data variables.product.prodname_ghe_server %}-Clusters zu überwachen.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/clustering/monitoring-cluster-nodes
|
||||
- /enterprise/admin/enterprise-management/monitoring-cluster-nodes
|
||||
versions:
|
||||
enterprise-server: '*'
|
||||
---
|
||||
### Manually checking cluster status
|
||||
|
||||
{% data variables.product.prodname_ghe_server %} has a built-in command line utility for monitoring the health of the cluster. From the administrative shell, running the `ghe-cluster-status` command executes a series of health checks on each node including verification of connectivity and service status. The output shows all test results including the text `ok` or `error`. For example, to only display failing tests, run:
|
||||
### Clusterstatus manuell überprüfen
|
||||
|
||||
{% data variables.product.prodname_ghe_server %} besitzt ein integriertes Befehlszeilendienstprogramm zum Überwachen des Clusterzustands. Wenn in der Verwaltungsshell der Befehl `ghe-cluster-status` ausgeführt wird, werden einige Zustandsprüfungen auf jedem Knoten ausgeführt, darunter die Verifizierung der Konnektivität und des Dienststatus. Die Ausgabe enthält alle Testergebnisse, darunter der Text `ok` oder `error`. Führen Sie beispielsweise Folgendes aus, um nur fehlgeschlagene Tests anzuzeigen:
|
||||
|
||||
```shell
|
||||
admin@ghe-data-node-0:~$ <em>ghe-cluster-status | grep error</em>
|
||||
@@ -18,20 +19,20 @@ admin@ghe-data-node-0:~$ <em>ghe-cluster-status | grep error</em>
|
||||
```
|
||||
{% note %}
|
||||
|
||||
**Note:** If there are no failing tests, this command produces no output. This indicates the cluster is healthy.
|
||||
**Hinweis:** Wenn keine fehlgeschlagenen Tests vorliegen, gibt dieser Befehl nichts aus. Dies gibt an, dass der Cluster fehlerfrei ist.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Monitoring cluster status with Nagios
|
||||
### Clusterstatus mit Nagios überwachen
|
||||
|
||||
You can configure [Nagios](https://www.nagios.org/) to monitor {% data variables.product.prodname_ghe_server %}. In addition to monitoring basic connectivity to each of the cluster nodes, you can check the cluster status by configuring Nagios to use the `ghe-cluster-status -n` command. This returns output in a format that Nagios understands.
|
||||
Sie können [Nagios](https://www.nagios.org/) für die Überwachung von {% data variables.product.prodname_ghe_server %} konfigurieren. Zusätzlich zur Überwachung der grundlegenden Konnektivität jedes Clusterknotens können Sie den Clusterstatus überprüfen, indem Sie Nagios für die Verwendung des Befehls `ghe-cluster-status -n` konfigurieren. Dadurch wird eine für Nagios verständliche Ausgabe zurückgegeben.
|
||||
|
||||
#### Prerequisites
|
||||
* Linux host running Nagios.
|
||||
* Network access to the {% data variables.product.prodname_ghe_server %} cluster.
|
||||
#### Vorrausetzungen
|
||||
* Linux-Host, auf dem Nagios ausgeführt wird.
|
||||
* Netzwerkzugriff auf den {% data variables.product.prodname_ghe_server %}-Cluster.
|
||||
|
||||
#### Configuring the Nagios host
|
||||
1. Generate an SSH key with a blank passphrase. Nagios uses this to authenticate to the {% data variables.product.prodname_ghe_server %} cluster.
|
||||
#### Nagios-Host konfigurieren
|
||||
1. Generieren Sie einen SSH-Schlüssel mit einer leeren Passphrase. Nagios verwendet diese, um sich beim {% data variables.product.prodname_ghe_server %}-Cluster zu authentifizieren.
|
||||
```shell
|
||||
nagiosuser@nagios:~$ <em>ssh-keygen -t rsa -b 4096</em>
|
||||
> Generating public/private rsa key pair.
|
||||
@@ -43,18 +44,18 @@ You can configure [Nagios](https://www.nagios.org/) to monitor {% data variables
|
||||
```
|
||||
{% danger %}
|
||||
|
||||
**Security Warning:** An SSH key without a passphrase can pose a security risk if authorized for full access to a host. Limit this key's authorization to a single read-only command.
|
||||
**Sicherheitswarnung:** Ein SSH-Schlüssel ohne eine Passphrase kann ein Sicherheitsrisiko darstellen, wenn er für den vollen Zugriff auf einen Host berechtigt ist. Begrenzen Sie die Autorisierung dieses Schlüssels auf einen einzelnen schreibgeschützten Befehl.
|
||||
|
||||
{% enddanger %}
|
||||
2. Copy the private key (`id_rsa`) to the `nagios` home folder and set the appropriate ownership.
|
||||
2. Kopieren Sie den privaten Schlüssel (`id_rsa`) in den Startordner `nagios`, und legen Sie die entsprechende Inhaberschaft fest.
|
||||
```shell
|
||||
nagiosuser@nagios:~$ <em>sudo cp .ssh/id_rsa /var/lib/nagios/.ssh/</em>
|
||||
nagiosuser@nagios:~$ <em>sudo chown nagios:nagios /var/lib/nagios/.ssh/id_rsa</em>
|
||||
```
|
||||
|
||||
3. To authorize the public key to run *only* the `ghe-cluster-status -n` command, use a `command=` prefix in the `/data/user/common/authorized_keys` file. From the administrative shell on any node, modify this file to add the public key generated in step 1. For example: `command="/usr/local/bin/ghe-cluster-status -n" ssh-rsa AAAA....`
|
||||
3. Verwenden Sie das Präfix `command=` in der Datei `/data/user/common/authorized_keys`, um den öffentlichen Schlüssel *nur* für den Befehl `ghe-cluster-status -n` zu autorisieren. Ändern Sie in der Verwaltungsshell oder auf einem beliebigen Knoten diese Datei, um den in Schritt 1 generierten öffentlichen Schlüssel hinzuzufügen. Zum Beispiel: `command="/usr/local/bin/ghe-cluster-status -n" ssh-rsa AAAA....`
|
||||
|
||||
4. Validate and copy the configuration to each node in the cluster by running `ghe-cluster-config-apply` on the node where you modified the `/data/user/common/authorized_keys` file.
|
||||
4. Validieren und kopieren Sie die Konfiguration auf jeden Knoten im Cluster. Führen Sie dazu `ghe-cluster-config-apply` auf dem Knoten aus, auf dem Sie die Datei `/data/user/common/authorized_keys` geändert haben.
|
||||
|
||||
```shell
|
||||
admin@ghe-data-node-0:~$ <em>ghe-cluster-config-apply</em>
|
||||
@@ -63,14 +64,15 @@ You can configure [Nagios](https://www.nagios.org/) to monitor {% data variables
|
||||
> Finished cluster configuration
|
||||
```
|
||||
|
||||
5. To test that the Nagios plugin can successfully execute the command, run it interactively from Nagios host.
|
||||
5. Um zu testen, ob das Nagios-Plug-in den Befehl erfolgreich ausführen kann, führen Sie es auf dem Nagios-Host interaktiv aus.
|
||||
```shell
|
||||
nagiosuser@nagios:~$ /usr/lib/nagios/plugins/check_by_ssh -l admin -p 122 -H <em>hostname</em> -C "ghe-cluster-status -n" -t 30
|
||||
> OK - No errors detected
|
||||
```
|
||||
|
||||
6. Create a command definition in your Nagios configuration.
|
||||
###### Example definition
|
||||
6. Erstellen Sie eine Befehlsdefinition in Ihrer Nagios-Konfiguration.
|
||||
|
||||
###### Beispieldefinition
|
||||
|
||||
```
|
||||
define command {
|
||||
@@ -78,9 +80,10 @@ You can configure [Nagios](https://www.nagios.org/) to monitor {% data variables
|
||||
command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "ghe-cluster-status -n" -l admin -p 122 -t 30
|
||||
}
|
||||
```
|
||||
7. Add this command to a service definition for a node in the {% data variables.product.prodname_ghe_server %} cluster.
|
||||
7. Fügen Sie diesen Befehl zu einer Dienstdefinition für einen Knoten im {% data variables.product.prodname_ghe_server %}-Cluster hinzu.
|
||||
|
||||
###### Example definition
|
||||
|
||||
###### Beispieldefinition
|
||||
|
||||
```
|
||||
define host{
|
||||
@@ -98,6 +101,6 @@ You can configure [Nagios](https://www.nagios.org/) to monitor {% data variables
|
||||
}
|
||||
```
|
||||
|
||||
Once you add the definition to Nagios, the service check executes according to your configuration. You should be able to see the newly configured service in the Nagios web interface.
|
||||
Nachdem Sie Nagios die Definition hinzugefügt haben, wird die Dienstüberprüfung entsprechend Ihrer Konfiguration ausgeführt. Sie sollten den neu konfigurierten Dienst auf der Nagios-Weboberfläche anzeigen können.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ Verwenden Sie ein Upgrade-Paket, um ein Upgrade eines {% data variables.product.
|
||||
#### Clusterknoten upgraden
|
||||
|
||||
1. Aktivieren Sie den Wartungsmodus entsprechend Ihrem geplanten Fenster. Verbinden Sie sich dazu mit der Verwaltungsshell auf einem beliebigen Clusterknoten, und führen Sie `ghe-cluster-maintenance -s` aus.
|
||||
2. **With the exception of the primary MySQL node**, connect to the administrative shell of each of the {% data variables.product.prodname_ghe_server %} nodes. Führen Sie den Befehl `ghe-upgrade` aus, und geben Sie den Namen der Paketdatei an, die Sie in Schritt 4 [Upgrade vorbereiten](#preparing-to-upgrade) heruntergeladen haben:
|
||||
2. Stellen Sie **mit Ausnahme des primären MySQL-Knotens** eine Verbindung zur Verwaltungsshell der jeweiligen {% data variables.product.prodname_ghe_server %}-Knoten her. Führen Sie den Befehl `ghe-upgrade` aus, und geben Sie den Namen der Paketdatei an, die Sie in Schritt 4 [Upgrade vorbereiten](#preparing-to-upgrade) heruntergeladen haben:
|
||||
```shell
|
||||
$ ghe-upgrade <em>PACKAGE-FILENAME</em>.pkg
|
||||
> *** verifying upgrade package signature...
|
||||
|
||||
@@ -29,7 +29,7 @@ Zusätzlich zu den Vorteilen des {% data variables.contact.enterprise_support %}
|
||||
- Geplante Zustandsprüfungen
|
||||
- Verwaltete Dienste
|
||||
|
||||
Weitere Informationen finden Sie unter „[Informationen zum {% data variables.contact.premium_support %} für {% data variables.product.prodname_ghe_server %}](/enterprise/admin/guides/enterprise-support/about-github-premium-support-for-github-enterprise-server)“.
|
||||
Weitere Informationen finden Sie unter „[Informationen zum {{ site.data.variables.contact.premium_support }} für {% data variables.product.prodname_ghe_server %}](/enterprise/admin/guides/enterprise-support/about-github-premium-support-for-github-enterprise-server)“.
|
||||
|
||||
{% data reusables.support.scope-of-support %}
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ Sie müssen die mindestens unterstützte Version von {% data variables.product.p
|
||||
|
||||
### Einem Support-Ticket eine Priorität zuweisen
|
||||
|
||||
Wenn Du den {% data variables.contact.premium_support %} kontaktierst, kannst Du eine von vier Prioritäten für das Ticket auswählen: „{% data variables.product.support_ticket_priority_urgent %}“ (dringend), „{% data variables.product.support_ticket_priority_high %}“ (hoch), „{% data variables.product.support_ticket_priority_normal %}“ (normal) oder „{% data variables.product.support_ticket_priority_low %}“ (niedrig).
|
||||
Wenn Du {% data variables.contact.premium_support %}kontaktierst, kannst Du eine von vier Prioritäten für das Ticket auswählen: {% data variables.product.support_ticket_priority_urgent %}, {% data variables.product.support_ticket_priority_high %}, {% data variables.product.support_ticket_priority_normal %} oder {% data variables.product.support_ticket_priority_low %}.
|
||||
|
||||
{% data reusables.support.github-can-modify-ticket-priority %}
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ Sie müssen die mindestens unterstützte Version von {% data variables.product.p
|
||||
|
||||
### Einem Support-Ticket eine Priorität zuweisen
|
||||
|
||||
Wenn Du den {% data variables.contact.premium_support %} kontaktierst, kannst Du eine von vier Prioritäten für das Ticket auswählen: „{% data variables.product.support_ticket_priority_urgent %}“ (dringend), „{% data variables.product.support_ticket_priority_high %}“ (hoch), „{% data variables.product.support_ticket_priority_normal %}“ (normal) oder „{% data variables.product.support_ticket_priority_low %}“ (niedrig).
|
||||
Wenn Du {% data variables.contact.premium_support %}kontaktierst, kannst Du eine von vier Prioritäten für das Ticket auswählen: {% data variables.product.support_ticket_priority_urgent %}, {% data variables.product.support_ticket_priority_high %}, {% data variables.product.support_ticket_priority_normal %} oder {% data variables.product.support_ticket_priority_low %}.
|
||||
|
||||
- [Ticket-Prioritäten für {% data variables.product.prodname_ghe_cloud %}](#ticket-priorities-for-github-enterprise-cloud)
|
||||
- [Ticket-Prioritäten für {% data variables.product.prodname_ghe_server %}](#ticket-priorities-for-github-enterprise-server)
|
||||
|
||||
@@ -19,7 +19,7 @@ versions:
|
||||
|
||||
### Supportumfang
|
||||
|
||||
Wenn Deine Supportanfrage außerhalb des Bereichs liegt, in dem unser Team Dir helfen kann, können wir weiter Schritte empfehlen, damit Du Deinen Issue außerhalb von {% data variables.contact.enterprise_support %} beheben kannst. Deine Supportanfrage liegt möglicherweise nicht im Bereich von {% data variables.contact.enterprise_support %}, wenn sie sich primär auf Folgendes bezieht:
|
||||
Wenn Ihre Supportanfrage außerhalb des Geltungsbereichs liegt, bei dem unser Team Ihnen helfen kann, können wir Ihnen die nächsten Schritte empfehlen, damit Sie Ihren Issue außerhalb von {% data variables.contact.enterprise_support %} beheben können. Ihre Supportanfrage liegt möglicherweise nicht im Umfang von {% data variables.contact.enterprise_support %}, wenn sie sich primär auf Folgendes bezieht:
|
||||
- Integration von Drittanbietern
|
||||
- Hardware-Einstellungen
|
||||
- Konfiguration externer Systeme
|
||||
@@ -70,8 +70,8 @@ Wenn Du den {% data variables.contact.enterprise_support %} um Hilfe mit {% data
|
||||
|
||||
{% data reusables.support.github-can-modify-ticket-priority %}
|
||||
|
||||
| Priorität | Beschreibung |
|
||||
|:------------------------------------------------------------------:| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Priorität | Beschreibung |
|
||||
|:-------------------------------------------------------------:| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| {% data variables.product.support_ticket_priority_high %} | {% data variables.product.prodname_advanced_security %} funktioniert nicht oder bricht ab oder ist stark beeinträchtigt, so dass der Endbenutzer die Software nicht vernünftig nutzen kann und es gibt keine Möglichkeit, das Problem zu umgehen. |
|
||||
| {% data variables.product.support_ticket_priority_normal %} | {% data variables.product.prodname_advanced_security %} funktioniert inkonsistent, was die Nutzung und Produktivität für den Endbenutzer beeinträchtigt. |
|
||||
| {% data variables.product.support_ticket_priority_low %} | {% data variables.product.prodname_advanced_security %} funktioniert beständig, aber der Endbenutzer bittet um geringfügige Änderungen in der Software, wie z.B. Dokumentationsaktualisierungen, Behebung kosmetischer Fehler oder Erweiterungen. |
|
||||
|
||||
@@ -37,7 +37,7 @@ Weitere Informationen zu den Weiterbildungsmöglichkeiten, einschließlich indiv
|
||||
|
||||
{% note %}
|
||||
|
||||
**Hinweis:** Schulungen sind im Leistungsumfang des {% data variables.product.premium_plus_support_plan %}s enthalten. Weitere Informationen finden Sie unter „[Informationen zum {% data variables.contact.premium_support %} für {% data variables.product.prodname_ghe_server %}](/enterprise/admin/guides/enterprise-support/about-github-premium-support-for-github-enterprise-server)“.
|
||||
**Hinweis:** Schulungen sind im Leistungsumfang des {% data variables.product.premium_plus_support_plan %}s enthalten. Weitere Informationen finden Sie unter „[Informationen zum {{ site.data.variables.contact.premium_support }} für {% data variables.product.prodname_ghe_server %}](/enterprise/admin/guides/enterprise-support/about-github-premium-support-for-github-enterprise-server)“.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
@@ -3,7 +3,6 @@ title: About using GitHub.com actions on GitHub Enterprise Server
|
||||
intro: '{% data variables.product.prodname_ghe_server %} includes most {% data variables.product.prodname_dotcom %}-authored actions, and has options for enabling access to other actions from {% data variables.product.prodname_dotcom_the_website %} and {% data variables.product.prodname_marketplace %}.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/github-actions/about-using-githubcom-actions-on-github-enterprise-server
|
||||
- /enterprise/admin/github-actions/about-using-githubcom-actions-on-github-enterprise-server
|
||||
versions:
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
@@ -3,7 +3,6 @@ title: Enforcing GitHub Actions policies for your enterprise
|
||||
intro: 'Enterprise administrators can manage access to {% data variables.product.prodname_actions %} in an enterprise.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/github-actions/enforcing-github-actions-policies-for-your-enterprise
|
||||
- /enterprise/admin/github-actions/enforcing-github-actions-policies-for-your-enterprise
|
||||
versions:
|
||||
enterprise-server: '>=2.22'
|
||||
---
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user