Amazon CodeCatalyst ist nicht mehr offen für Neukunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Wie migriert man von CodeCatalyst](migration.md).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Einen Workflow ausführen
Eine *Ausführung* ist eine einzelne Iteration eines Workflows. CodeCatalystFührt während eines Laufs die in der Workflow-Konfigurationsdatei definierten Aktionen aus und gibt die zugehörigen Protokolle, Artefakte und Variablen aus.
Sie können einen Lauf manuell oder automatisch über einen *Workflow-Auslöser* starten. Ein Beispiel für einen Workflow-Trigger könnte ein Softwareentwickler sein, der einen Commit an Ihren Hauptzweig weiterleitet.
Sie können einen Workflow-Lauf während der Bearbeitung auch manuell beenden, wenn Sie ihn versehentlich gestartet haben.
Wenn mehrere Workflow-Ausführungen ungefähr zur gleichen Zeit gestartet werden, können Sie konfigurieren, wie diese Läufe in die Warteschlange gestellt werden sollen. Sie können das standardmäßige Warteschlangenverhalten verwenden, bei dem Läufe nacheinander in der Reihenfolge, in der sie gestartet wurden, in der sie gestartet wurden, in die Warteschlange eingereiht werden, oder Sie können festlegen, dass ein späterer Lauf einen früheren ersetzt (oder „übernimmt“), um Ihren Lauf durchgehend zu beschleunigen. Es ist auch möglich, Ihre Workflow-Läufe so einzurichten, dass sie parallel ablaufen, sodass kein Lauf auf einen anderen wartet.
Nachdem Sie eine Workflow-Ausführung entweder manuell oder automatisch gestartet haben, können Sie den Status der Ausführung und andere Details anzeigen. Sie können beispielsweise sehen, wann er gestartet wurde, von wem er gestartet wurde und ob er noch läuft.
**Topics**
+ [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md)
+ [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md)
+ [Reine manuelle Trigger konfigurieren](workflows-manual-only.md)
+ [Anhalten einer Workflow-Ausführung](workflows-stop.md)
+ [Gating eines Workflow-Laufs](workflows-gates.md)
+ [Genehmigungen für Workflow-Läufe erforderlich](workflows-approval.md)
+ [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md)
+ [Zwischenspeichern von Dateien zwischen Workflow-Läufen](workflows-caching.md)
+ [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md)
# Manuelles Starten einer Workflow-Ausführung
In Amazon CodeCatalyst können Sie einen manuell ausgeführten Workflow von der CodeCatalyst Konsole aus starten.
Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
**Anmerkung**
Sie können eine Workflow-Ausführung auch automatisch starten, indem Sie [einen Trigger konfigurieren](workflows-add-trigger.md).
**Um einen Workflow manuell zu starten, führen Sie ihn manuell aus**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Klicken Sie auf **Ausführen**.
# Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern
Sie können einen CodeCatalyst Amazon-Workflow-Lauf automatisch mit einem Workflow-Trigger starten.
Ein *Workflow-Auslöser* oder einfach ein *Trigger* ermöglicht es Ihnen, eine Workflow-Ausführung automatisch zu starten, wenn bestimmte Ereignisse eintreten, z. B. ein Code-Push. Möglicherweise möchten Sie Trigger so konfigurieren, dass Ihre Softwareentwickler Workflow-Läufe nicht manuell über die CodeCatalyst Konsole starten müssen.
Sie können drei Arten von Triggern verwenden:
+ **Push** — Ein Code-Push-Trigger bewirkt, dass ein Workflow-Lauf immer dann gestartet wird, wenn ein Commit übertragen wird.
+ **Pull-Request** — Ein Pull-Request-Trigger bewirkt, dass ein Workflow-Lauf immer dann gestartet wird, wenn ein Pull-Request entweder erstellt, überarbeitet oder geschlossen wird.
+ **Zeitplan** — Ein Zeitplan-Trigger bewirkt, dass ein Workflow-Lauf nach einem von Ihnen definierten Zeitplan gestartet wird. Erwägen Sie, einen Zeitplan-Trigger zu verwenden, um nächtliche Builds Ihrer Software auszuführen, sodass Ihre Softwareentwickler am nächsten Morgen mit der neuesten Version arbeiten können.
Sie können Push-, Pull-Request- und Schedule-Trigger einzeln oder in Kombination im selben Workflow verwenden.
Trigger sind optional. Wenn Sie keine konfigurieren, können Sie einen Workflow nur manuell starten.
**Tipp**
Um einen Auslöser in Aktion zu sehen, starten Sie ein Projekt mit einem Blueprint. Die meisten Blueprints enthalten einen Workflow mit einem Auslöser. Suchen Sie in der Workflow-Definitionsdatei des Blueprints nach der `Trigger` Eigenschaft. Weitere Informationen über Pläne finden Sie unter [Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template).
**Topics**
+ [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md)
+ [Richtlinien zur Verwendung von Triggern und Branches](workflows-add-trigger-considerations.md)
+ [Hinzufügen von Triggern zu Workflows](workflows-add-trigger-add.md)
# Beispiele: Auslöser in Workflows
Die folgenden Beispiele zeigen, wie verschiedene Arten von Triggern zu einer CodeCatalyst Amazon-Workflow-Definitionsdatei hinzugefügt werden.
Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
**Topics**
+ [Beispiel: Ein einfacher Code-Push-Trigger](#workflows-add-trigger-examples-push-simple)
+ [Beispiel: Ein einfacher „Push to Main“ -Trigger](#workflows-add-trigger-examples-push-main)
+ [Beispiel: Ein einfacher Pull-Request-Trigger](#workflows-add-trigger-examples-pull-simple)
+ [Beispiel: Ein einfacher Zeitplan-Trigger](#workflows-add-trigger-examples-schedule-simple)
+ [Beispiel: Ein Trigger mit einem Zeitplan und Zweigen](#workflows-add-trigger-examples-schedule-branches)
+ [Beispiel: Ein Trigger mit einem Zeitplan, einem Push und Verzweigungen](#workflows-add-trigger-examples-schedule-push-branches)
+ [Beispiel: Ein Trigger mit einem Zug und Verzweigungen](#workflows-add-trigger-examples-pull-branches)
+ [Beispiel: Ein Trigger mit einem Pull-, Branches- und einem 'CLOSED'-Ereignis](#workflows-add-trigger-examples-push-pull-close)
+ [Beispiel: Ein Trigger mit einem Push, Branches und Dateien](#workflows-add-trigger-examples-push-multi)
+ [Beispiel: Ein manueller Trigger](#workflows-add-trigger-examples-manual)
+ [Beispiel: Auslöser in einer Konfiguration mit CI/CD mehreren Workflows](#workflows-add-trigger-usecases)
## Beispiel: Ein einfacher Code-Push-Trigger
Das folgende Beispiel zeigt einen Trigger, der eine Workflow-Ausführung startet, wenn Code in einen *beliebigen* Branch in Ihrem Quell-Repository übertragen wird.
Wenn dieser Trigger aktiviert ist, CodeCatalyst startet eine Workflow-Ausführung mit den Dateien in dem Branch, in *den* Sie pushen (das ist der Ziel-Branch).
Wenn Sie beispielsweise einen Commit per Push ausführen`main`, CodeCatalyst wird ein Workflow-Lauf gestartet, bei dem die Workflow-Definitionsdatei und andere Quelldateien verwendet werden. `main`
Ein weiteres Beispiel: Wenn Sie einen Commit per Push auf übertragen`feature-branch-123`, CodeCatalyst wird ein Workflow-Lauf gestartet, bei dem die Workflow-Definitionsdatei und andere Quelldateien verwendet werden. `feature-branch-123`
```
Triggers:
- Type: PUSH
```
**Anmerkung**
Wenn Sie möchten, dass ein Workflow-Lauf erst gestartet wird, wenn Sie einen Push to ausführen`main`, finden Sie weitere Informationen unter. [Beispiel: Ein einfacher „Push to Main“ -Trigger](#workflows-add-trigger-examples-push-main)
## Beispiel: Ein einfacher „Push to Main“ -Trigger
Das folgende Beispiel zeigt einen Trigger, der immer dann eine Workflow-Ausführung startet, wenn Code an den Branch `main` — und *nur* an den Branch — in Ihrem Quell-Repository übertragen wird. `main`
```
Triggers:
- Type: PUSH
Branches:
- main
```
## Beispiel: Ein einfacher Pull-Request-Trigger
Das folgende Beispiel zeigt einen Trigger, der einen Workflow-Lauf startet, wenn ein Pull-Request in Ihrem Quell-Repository erstellt oder überarbeitet wird.
Wenn dieser Trigger aktiviert ist, CodeCatalyst startet er einen Workflow-Lauf unter Verwendung der Workflow-Definitionsdatei und anderer Quelldateien in dem Branch, *aus dem* Sie abrufen (d. h. dem Quell-Branch).
Wenn Sie beispielsweise eine Pull-Anfrage mit einem Quell-Branch `feature-123` und einem Ziel-Branch mit dem Namen erstellen`main`, wird ein Workflow-Lauf CodeCatalyst gestartet, der die Workflow-Definitionsdatei und andere Quelldateien verwendet. `feature-123`
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## Beispiel: Ein einfacher Zeitplan-Trigger
Das folgende Beispiel zeigt einen Trigger, der jeden Montag bis Freitag um Mitternacht (UTC\$10) eine Workflow-Ausführung startet.
Wenn dieser Trigger aktiviert ist, wird für jeden Branch in Ihrem Quell-Repository, der eine Workflow-Definitionsdatei mit diesem Trigger enthält, eine einzelne Workflow-Ausführung CodeCatalyst gestartet.
Wenn Sie beispielsweise drei Zweige in Ihrem Quell-Repository haben,, `main` `release-v1``feature-123`, und jeder dieser Zweige eine Workflow-Definitionsdatei mit dem folgenden Trigger enthält, werden drei Workflow-Läufe CodeCatalyst gestartet: eine mit den Dateien in`main`, eine weitere mit den Dateien in `release-v1` und eine weitere mit den Dateien in`feature-123`.
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 ? * MON-FRI *"
```
Weitere Beispiele für Cron-Ausdrücke, die Sie in der `Expression` Eigenschaft verwenden können, finden Sie unter[Expression](workflow-reference.md#workflow.triggers.expression).
## Beispiel: Ein Trigger mit einem Zeitplan und Zweigen
Das folgende Beispiel zeigt einen Trigger, der jeden Tag um 18:15 Uhr (UTC\$10) eine Workflow-Ausführung startet.
Wenn dieser Trigger aktiviert ist, CodeCatalyst startet er eine Workflow-Ausführung unter Verwendung der Dateien in der `main` Verzweigung und startet zusätzliche Läufe für jeden Zweig, der mit beginnt. `release-`
Wenn Sie beispielsweise `bugfix-2` in Ihrem Quell-Repository Zweige mit dem Namen `main` `release-v1``bugfix-1`,, und haben, werden zwei Workflow-Ausführungen CodeCatalyst gestartet: eine mit den Dateien in `main` und eine weitere mit den Dateien in`release-v1`. Es werden *keine* Workflow-Läufe für die `bugfix-1` Zweige `bugfix-1` und gestartet.
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
Weitere Beispiele für Cron-Ausdrücke, die Sie in der `Expression` Eigenschaft verwenden können, finden Sie unter[Expression](workflow-reference.md#workflow.triggers.expression).
## Beispiel: Ein Trigger mit einem Zeitplan, einem Push und Verzweigungen
Das folgende Beispiel zeigt einen Trigger, der jeden Tag um Mitternacht (UTC\$10) und immer dann, wenn Code an den Branch gesendet wird, eine Workflow-Ausführung startet. `main`
In diesem Beispiel:
+ Eine Workflow-Ausführung beginnt jeden Tag um Mitternacht. Der Workflow-Lauf verwendet die Workflow-Definitionsdatei und andere Quelldateien im `main` Zweig.
+ Ein Workflow-Lauf wird auch immer dann gestartet, wenn Sie einen Commit an den `main` Branch weiterleiten. Der Workflow-Lauf verwendet die Workflow-Definitionsdatei und andere Quelldateien im Zielzweig (`main`).
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 * * ? *"
Branches:
- main
- Type: PUSH
Branches:
- main
```
Weitere Beispiele für Cron-Ausdrücke, die Sie in der `Expression` Eigenschaft verwenden können, finden Sie unter[Expression](workflow-reference.md#workflow.triggers.expression).
## Beispiel: Ein Trigger mit einem Zug und Verzweigungen
Das folgende Beispiel zeigt einen Trigger, der einen Workflow-Lauf startet, wenn jemand eine Pull-Anfrage öffnet oder ändert, bei der ein Ziel-Branch aufgerufen wird`main`. Der in der `Triggers` Konfiguration angegebene Branch lautet zwar`main`, aber der Workflow-Lauf verwendet die Workflow-Definitionsdatei und andere Quelldateien im *Quell-Branch* (dem Branch, *aus* dem Sie abrufen).
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
## Beispiel: Ein Trigger mit einem Pull-, Branches- und einem 'CLOSED'-Ereignis
Das folgende Beispiel zeigt einen Trigger, der eine Workflow-Ausführung immer dann startet, wenn eine Pull-Anfrage für einen Branch geschlossen wird, der mit beginnt`main`.
In diesem Beispiel:
+ Wenn Sie einen Pull-Request mit einem Ziel-Branch schließen, der mit beginnt`main`, startet automatisch ein Workflow-Lauf mit der Workflow-Definitionsdatei und anderen Quelldateien im (jetzt geschlossenen) Quellzweig.
+ Wenn du dein Quell-Repository so konfiguriert hast, dass Branches automatisch gelöscht werden, nachdem eine Pull-Anfrage zusammengeführt wurde, haben diese Branches nie die Möglichkeit, in den `CLOSED` Status zu wechseln. Das bedeutet, dass zusammengeführte Branches den `CLOSED` Pull-Request-Trigger nicht aktivieren. Die einzige Möglichkeit, den `CLOSED` Trigger in diesem Szenario zu aktivieren, besteht darin, den Pull-Request zu schließen, ohne ihn zusammenzuführen.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- CLOSED
```
## Beispiel: Ein Trigger mit einem Push, Branches und Dateien
Das folgende Beispiel zeigt einen Trigger, der eine Workflow-Ausführung startet, wenn eine Änderung an der `filename.txt` Datei oder einer beliebigen Datei im `src` Verzeichnis im `main` Branch vorgenommen wird.
Wenn dieser Trigger aktiviert ist, wird eine Workflow-Ausführung mit der Workflow-Definitionsdatei und anderen Quelldateien in der `main` Verzweigung CodeCatalyst gestartet.
```
Triggers:
- Type: PUSH
Branches:
- main
FilesChanged:
- filename.txt
- src\/.*
```
## Beispiel: Ein manueller Trigger
Um einen manuellen Trigger zu konfigurieren, lassen Sie den `Triggers` Abschnitt aus der Workflow-Definitionsdatei weg. Ohne diesen Abschnitt sind Benutzer gezwungen, den Workflow manuell zu starten, indem sie in der CodeCatalyst Konsole auf die Schaltfläche **Ausführen** klicken. Weitere Informationen finden Sie unter [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).
## Beispiel: Auslöser in einer Konfiguration mit CI/CD mehreren Workflows
In diesem Beispiel wird beschrieben, wie Trigger eingerichtet werden, wenn Sie separate CodeCatalyst Amazon-Workflows für Continuous Integration (CI) und Continuous Deployment (CD) verwenden möchten.
In diesem Szenario richten Sie zwei Workflows ein:
+ ein **CI-Workflow** — dieser Workflow erstellt und testet Ihre Anwendung, wenn eine Pull-Anfrage erstellt oder überarbeitet wird.
+ ein **CD-Workflow** — dieser Workflow erstellt Ihre Anwendung und stellt sie bereit, wenn eine Pull-Anfrage zusammengeführt wird.
Die Definitionsdatei des **CI-Workflows** würde in etwa so aussehen:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
Actions:
BuildAction:
instructions-for-building-the-app
TestAction:
instructions-for-test-the-app
```
Der `Triggers` Code gibt an, dass ein Workflow-Lauf automatisch gestartet werden soll, wenn ein Softwareentwickler einen Pull-Request erstellt (oder [einen ändert](pull-requests-update.md)), in dem er darum bittet, seinen Feature-Branch mit dem `main` Branch zusammenzuführen. CodeCatalyst startet die Workflow-Ausführung unter Verwendung des Quellcodes im Quellzweig (der Feature-Branch).
Die Definitionsdatei des **CD-Workflows** würde etwa so aussehen:
```
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildAction:
instructions-for-building-the-app
DeployAction:
instructions-for-deploying-the-app
```
Der `Triggers` Code gibt an, dass der Workflow automatisch gestartet werden soll, wenn eine Zusammenführung mit `main` stattfindet. CodeCatalyst startet die Workflow-Ausführung unter Verwendung des Quellcodes in der `main` Verzweigung.
# Richtlinien zur Verwendung von Triggern und Branches
In diesem Abschnitt werden einige der wichtigsten Richtlinien für die Einrichtung von CodeCatalyst Amazon-Triggern beschrieben, die Filialen einbeziehen.
Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ **Richtlinie 1:** Wenn Sie sowohl für Push- als auch für Pull-Request-Trigger einen Branch angeben möchten, müssen Sie den Ziel-Branch (oder den Ziel-Branch) in der Trigger-Konfiguration angeben. Geben Sie niemals den Quellzweig (oder den Absenderzweig) an.
Im folgenden Beispiel `main` aktiviert ein Push aus einem beliebigen Zweig den Workflow.
```
Triggers:
- Type: PUSH
Branches:
- main
```
Im folgenden Beispiel `main` aktiviert eine Pull-Anfrage von einem beliebigen Branch in den Workflow.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
+ **Richtlinie 2:** Bei Push-Triggern wird der Workflow nach der Aktivierung des Workflows mithilfe der Workflow-Definitionsdatei und der Quelldateien im *Zielzweig* ausgeführt.
+ **Richtlinie 3:** Bei Pull-Request-Triggern wird der Workflow nach der Aktivierung des Workflows mit der Workflow-Definitionsdatei und den Quelldateien im *Quellzweig* ausgeführt (obwohl Sie den Zielzweig in der Trigger-Konfiguration angegeben haben).
+ **Richtlinie 4:** Derselbe Trigger in einem Zweig wird möglicherweise nicht in einem anderen Zweig ausgeführt.
Stellen Sie sich den folgenden Push-Trigger vor:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Wenn die Workflow-Definitionsdatei, die diesen Trigger enthält, in existiert `main` und in die geklont wird`test`, wird der Workflow niemals automatisch mit den Dateien in gestartet `test` (obwohl Sie den Workflow auch *manuell* starten könnten, damit er die Dateien in verwendet`test`). Lesen Sie **Richtlinie 2**, um zu verstehen, warum der Workflow niemals automatisch mit den darin enthaltenen `test` Dateien ausgeführt werden kann.
Beachten Sie auch den folgenden Pull-Request-Trigger:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
Wenn die Workflow-Definitionsdatei, die diesen Trigger enthält`main`, existiert, wird der Workflow niemals mit den Dateien in ausgeführt`main`. (Wenn Sie jedoch eine `test` Abzweigung von erstellen`main`, wird der Workflow unter Verwendung der Dateien in ausgeführt`test`.) Lesen Sie sich **Richtlinie 3** durch, um zu verstehen, warum.
# Hinzufügen von Triggern zu Workflows
Verwenden Sie die folgenden Anweisungen, um Ihrem CodeCatalyst Amazon-Workflow einen Push-, Pull- oder Schedule-Trigger hinzuzufügen.
Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
------
#### [ Visual ]
**Um einen Trigger hinzuzufügen (visueller Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Visual**.
1. Wählen Sie im Workflow-Diagramm das Feld **Quelle** und **Auslöser aus**.
1. Wählen Sie im Konfigurationsbereich die Option **Trigger hinzufügen aus**.
1. **Geben Sie im Dialogfeld „Trigger hinzufügen**“ die folgenden Informationen in die Felder ein.
**Typ des Triggers**
Geben Sie den Triggertyp an. Sie können einen der folgenden Werte verwenden:
+ **Push** (visueller Editor) oder `PUSH` (YAML-Editor)
Ein Push-Trigger startet einen Workflow-Lauf, wenn eine Änderung in Ihr Quell-Repository übertragen wird. Bei der Workflow-Ausführung werden die Dateien in dem Branch verwendet, in *den* Sie pushen (das ist der Ziel-Branch).
+ **Pull-Request** (visueller Editor) oder `PULLREQUEST` (YAML-Editor)
Ein Pull-Request-Trigger startet einen Workflow-Lauf, wenn ein Pull-Request in Ihrem Quell-Repository geöffnet, aktualisiert oder geschlossen wird. Bei der Workflow-Ausführung werden die Dateien in dem Branch verwendet, *aus* dem Sie abrufen (das ist der Quell-Branch).
+ **Zeitplan** (visueller Editor) oder `SCHEDULE` (YAML-Editor)
Ein Zeitplan-Trigger startet Workflow-Läufe nach einem Zeitplan, der durch einen von Ihnen angegebenen Cron-Ausdruck definiert ist. Für jeden Branch in Ihrem Quell-Repository wird ein separater Workflow-Lauf gestartet, der die Dateien des Branches verwendet. (Verwenden Sie das Feld Branches (visueller Editor) oder die `Branches` Eigenschaft (YAML-Editor), um die **Branches** einzuschränken, für die der Trigger aktiviert wird.)
Beachten Sie bei der Konfiguration eines Zeitplan-Triggers die folgenden Richtlinien:
+ Verwenden Sie nur einen Zeitplan-Trigger pro Workflow.
+ Wenn Sie in Ihrem CodeCatalyst Bereich mehrere Workflows definiert haben, empfehlen wir, nicht mehr als 10 davon so zu planen, dass sie gleichzeitig starten.
+ Stellen Sie sicher, dass Sie den Cron-Ausdruck des Triggers so konfigurieren, dass genügend Zeit zwischen den Läufen liegt. Weitere Informationen finden Sie unter [Expression](workflow-reference.md#workflow.triggers.expression).
Beispiele finden Sie unter [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
**Ereignisse für Pull-Requests**
Dieses Feld wird nur angezeigt, wenn Sie den Triggertyp **Pull-Request** ausgewählt haben.
Geben Sie den Typ der Pull-Request-Ereignisse an, mit denen eine Workflow-Ausführung gestartet wird. Die folgenden Werte sind gültig:
+ **Eine Pull-Anfrage wird erstellt** (visueller Editor) oder `OPEN` (YAML-Editor)
Der Workflow-Lauf wird gestartet, wenn ein Pull-Request erstellt wird.
+ Die **Pull-Anfrage ist geschlossen** (visueller Editor) oder `CLOSED` (YAML-Editor)
Der Workflow-Lauf wird gestartet, wenn ein Pull-Request geschlossen wird. Das Verhalten des `CLOSED` Ereignisses ist knifflig und lässt sich am besten anhand eines Beispiels verstehen. Weitere Informationen finden Sie unter [Beispiel: Ein Trigger mit einem Pull-, Branches- und einem 'CLOSED'-Ereignis](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close).
+ **Eine neue Version wird für den Pull-Request (visueller Editor) oder `REVISION` (YAML-Editor) erstellt**
Der Workflow-Lauf wird gestartet, wenn eine Revision eines Pull-Requests erstellt wird. Die erste Revision wird erstellt, wenn der Pull-Request erstellt wird. Danach wird jedes Mal, wenn jemand einen neuen Commit an den im Pull Request angegebenen Quell-Branch pusht, eine neue Revision erstellt. Wenn Sie das `REVISION` Ereignis in Ihren Pull-Request-Trigger aufnehmen, können Sie das `OPEN` Ereignis weglassen, da es eine Obermenge von `REVISION` ist. `OPEN`
Sie können mehrere Ereignisse in demselben Pull-Request-Trigger angeben.
Beispiele finden Sie unter [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
**Plan**
Dieses Feld wird nur angezeigt, wenn Sie den Triggertyp „**Zeitplan**“ ausgewählt haben.
Geben Sie den Cron-Ausdruck an, der beschreibt, wann Ihre geplanten Workflow-Ausführungen ausgeführt werden sollen.
In Cron-Ausdrücken wird die folgende Syntax mit sechs Feldern CodeCatalyst verwendet, wobei jedes Feld durch ein Leerzeichen getrennt ist:
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**Beispiele für Cron-Ausdrücke**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
Achten Sie bei der Angabe von Cron-Ausdrücken in darauf CodeCatalyst, dass Sie die folgenden Richtlinien beachten:
+ Geben Sie einen einzelnen Cron-Ausdruck pro `SCHEDULE` Trigger an.
+ Schließen Sie den Cron-Ausdruck im YAML-Editor in doppelte Anführungszeichen (`"`) ein.
+ Geben Sie die Uhrzeit in koordinierter Weltzeit (UTC) an. Andere Zeitzonen werden nicht unterstützt.
+ Konfigurieren Sie mindestens 30 Minuten zwischen den Läufen. Eine schnellere Trittfrequenz wird nicht unterstützt.
+ Geben Sie das *days-of-week* Feld *days-of-month* oder an, aber nicht beide. Wenn Sie in einem der Felder einen Wert oder ein Sternchen (`*`) angeben, müssen Sie in dem anderen Feld ein Fragezeichen (`?`) verwenden. Das Sternchen bedeutet „alle“ und das Fragezeichen bedeutet „beliebig“.
Weitere Beispiele für Cron-Ausdrücke und Informationen zu Platzhaltern wie `?` `*``L`, und finden Sie in der [Referenz zu Cron-Ausdrücken](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) im * EventBridge Amazon-Benutzerhandbuch*. Cron-Ausdrücke in EventBridge und CodeCatalyst funktionieren genauso.
Beispiele für Zeitplan-Trigger finden Sie unter[Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
**Zweige** und **Filialmuster**
(Optional)
Geben Sie die Branches in Ihrem Quell-Repository an, die der Trigger überwacht, um zu wissen, wann ein Workflow-Lauf gestartet werden muss. Sie können Regex-Muster verwenden, um Ihre Branch-Namen zu definieren. Verwenden Sie dies beispielsweise, um alle Zweige `main.*` abzugleichen, die mit beginnen. `main`
Die anzugebenden Zweige unterscheiden sich je nach Triggertyp:
+ Geben Sie für einen Push-Trigger die Zweige an, auf die Sie pushen *möchten*, d. h. die *Zielzweige*. Pro übereinstimmender Verzweigung wird ein Workflow-Lauf gestartet, wobei die Dateien im entsprechenden Zweig verwendet werden.
Beispiele: `main.*`, `mainline`
+ Geben Sie für einen Pull-Request-Trigger die Branches an, in die Sie pushen *möchten*, also die *Ziel-Branches*. Pro zugeordnetem Branch wird ein Workflow-Lauf gestartet, wobei die Workflow-Definitionsdatei und die Quelldateien im **Quellzweig** (*nicht* im passenden Branch) verwendet werden.
Beispiele:`main.*`,`mainline`, `v1\-.*` (entspricht Verzweigungen, die mit beginnen`v1-`)
+ Geben Sie für einen Zeitplan-Trigger die Zweige an, die die Dateien enthalten, die bei Ihrem geplanten Lauf verwendet werden sollen. Pro zugeordnetem Zweig wird ein Workflow-Lauf gestartet, wobei die Workflow-Definitionsdatei und die Quelldateien im entsprechenden Zweig verwendet werden.
Beispiele: `main.*`, `version\-1\.0`
**Anmerkung**
Wenn Sie *keine* Verzweigungen angeben, überwacht der Trigger alle Verzweigungen in Ihrem Quell-Repository und startet eine Workflow-Ausführung mit der Workflow-Definitionsdatei und den Quelldateien in:
Der Branch, auf den Sie *pushen* (für Push-Trigger). Weitere Informationen finden Sie unter [Beispiel: Ein einfacher Code-Push-Trigger](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple).
Der Branch, *aus dem* Sie abrufen (für Pull-Request-Trigger). Weitere Informationen finden Sie unter [Beispiel: Ein einfacher Pull-Request-Trigger](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple).
Alle Branches (für Zeitplan-Trigger). Pro Branch in Ihrem Quell-Repository wird ein Workflow-Lauf gestartet. Weitere Informationen finden Sie unter [Beispiel: Ein einfacher Zeitplan-Trigger](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple).
Weitere Informationen zu Branches und Triggern finden Sie unter[Richtlinien zur Verwendung von Triggern und Branches](workflows-add-trigger-considerations.md).
Weitere Beispiele finden Sie unter [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
**Dateien wurden geändert**
Dieses Feld wird nur angezeigt, wenn Sie den Triggertyp **Push** - oder **Pull-Anfrage** ausgewählt haben.
Geben Sie die Dateien oder Ordner in Ihrem Quell-Repository an, die der Trigger überwacht, damit Sie wissen, wann eine Workflow-Ausführung gestartet werden muss. Sie können reguläre Ausdrücke verwenden, um Dateinamen oder Pfade abzugleichen.
Beispiele finden Sie unter [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
#### [ YAML ]
**Um einen Trigger hinzuzufügen (YAML-Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Fügen Sie anhand des folgenden Beispiels einen `Triggers` Abschnitt und die zugrunde liegenden Eigenschaften hinzu. Weitere Informationen finden Sie unter [Triggers](workflow-reference.md#triggers-reference) im [YAML-Workflow-Definition](workflow-reference.md).
Ein Code-Push-Trigger könnte so aussehen:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Ein Pull-Request-Trigger könnte so aussehen:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- OPEN
- REVISION
- CLOSED
```
Ein Zeitplan-Trigger könnte wie folgt aussehen:
```
Triggers:
- Type: SCHEDULE
Branches:
- main.*
# Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023
Expression: "15 1 ? * FRI 2022-2023"
```
Weitere Beispiele für Cron-Ausdrücke, die Sie in der `Expression` Eigenschaft verwenden können, finden Sie unter[Expression](workflow-reference.md#workflow.triggers.expression).
Weitere Beispiele für Push-, Pull-Request- und Schedule-Trigger finden Sie unter[Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md).
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
# Reine manuelle Trigger konfigurieren
Sie können einen Workflow so einschränken, dass er nur manuell von Ihrem Team gestartet werden kann, indem Sie in der CodeCatalyst Konsole auf die Schaltfläche **Ausführen** klicken. Um diese Funktionalität zu konfigurieren, müssen Sie den `Triggers` Abschnitt in der Workflow-Definitionsdatei entfernen. Der `Triggers` Abschnitt ist standardmäßig enthalten, wenn Sie einen Workflow erstellen, der Abschnitt ist jedoch optional und kann entfernt werden.
Verwenden Sie die folgenden Anweisungen, um den `Triggers` Abschnitt in der Workflow-Definitionsdatei zu entfernen, sodass der Workflow nur manuell gestartet werden kann.
Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
Weitere Informationen zum Ausführen von Workflows finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
------
#### [ Visual ]
**Um den Abschnitt „Trigger“ zu entfernen (visueller Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Visual**.
1. Wählen Sie im Workflow-Diagramm das Feld **Quelle** aus.
1. Wählen Sie unter **Auslöser** das Papierkorbsymbol aus, um den `Triggers` Abschnitt aus dem Workflow zu entfernen.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
#### [ YAML ]
**Um den Abschnitt „Trigger“ zu entfernen (YAML-Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Suchen Sie den `Triggers` Abschnitt und entfernen Sie ihn.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
# Anhalten einer Workflow-Ausführung
Gehen Sie wie folgt vor, um eine Workflow-Ausführung zu beenden, die gerade ausgeführt wird. Möglicherweise möchten Sie einen Lauf beenden, wenn er versehentlich gestartet wurde.
Wenn Sie eine Workflow-Ausführung beenden, CodeCatalyst wartet, bis die laufenden Aktionen abgeschlossen sind, bevor die **Ausführung** in der CodeCatalyst Konsole als Beendet markiert wird. **Alle Aktionen, die nicht gestartet werden konnten, werden nicht gestartet und als „Abgebrochen“ markiert.**
**Anmerkung**
Befindet sich ein Lauf in der Warteschlange (d. h., es gibt keine laufenden Aktionen), wird der Lauf sofort gestoppt.
Weitere Informationen zu Workflow-Ausführungen finden Sie unter. [Einen Workflow ausführen](workflows-working-runs.md)
**So beenden Sie eine Workflow-Ausführung**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie unter **Workflows** die Option **Läufe** aus und wählen Sie die Ausführung, die gerade ausgeführt wird, aus der Liste aus.
1. Wählen Sie **Beenden** aus.
# Gating eines Workflow-Laufs
Ein *Gate* ist eine Workflow-Komponente, mit der Sie verhindern können, dass ein Workflow-Lauf fortgesetzt wird, sofern nicht bestimmte Bedingungen erfüllt sind. Ein Beispiel für ein Gate ist das **Genehmigungstor**, bei dem Benutzer eine Genehmigung in der CodeCatalyst Konsole einreichen müssen, bevor die Workflow-Ausführung fortgesetzt werden kann.
Sie können Gates zwischen Aktionssequenzen in einem Workflow oder vor der ersten Aktion (die unmittelbar nach dem Herunterladen der **Quelldatei** ausgeführt wird) hinzufügen. Sie können Gates auch nach der letzten Aktion hinzufügen, falls Sie dies benötigen.
Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
**Topics**
+ [Gate-Typen](#workflows-gates-types)
+ [Kann ich ein Gate einrichten, das parallel zu einer anderen Aktion läuft?](#workflows-approval-parallel)
+ [Kann ich ein Gate verwenden, um zu verhindern, dass ein Workflow-Lauf gestartet wird?](#workflows-gates-prevent)
+ [Einschränkungen von Gates](#workflows-gate-limitations)
+ [Hinzufügen eines Gates zu einem Workflow](workflows-gates-add.md)
+ [Sequenzierung von Gates und Aktionen](workflows-gates-depends-on.md)
+ [Die Version eines Gates angeben](workflows-gates-version.md)
## Gate-Typen
Derzeit CodeCatalyst unterstützt Amazon eine Art von Gate: das **Approval** Gate. Weitere Informationen finden Sie unter [Genehmigungen für Workflow-Läufe erforderlich](workflows-approval.md).
## Kann ich ein Gate einrichten, das parallel zu einer anderen Aktion läuft?
Nein. Gates können nur vor oder nach einer Aktion laufen. Weitere Informationen finden Sie unter [Sequenzierung von Gates und Aktionen](workflows-gates-depends-on.md).
## Kann ich ein Gate verwenden, um zu verhindern, dass ein Workflow-Lauf gestartet wird?
Ja, mit Qualifikationen.
Sie können verhindern, dass eine *Workflow-Ausführung Aufgaben ausführt*, was sich geringfügig von der Verhinderung des *Starts* unterscheidet.
Um zu verhindern, dass ein Workflow Aufgaben ausführt, fügen Sie vor der allerersten Aktion in einem Workflow ein Tor hinzu. In diesem Szenario wird ein Workflow-Lauf *gestartet, d. h. es werden* Ihre Quell-Repository-Dateien heruntergeladen. Er wird jedoch daran gehindert, Aufgaben auszuführen, bis das Gate entsperrt ist.
**Anmerkung**
Workflows, die starten und dann durch ein Gate blockiert werden, werden trotzdem auf Ihre *maximale Anzahl gleichzeitiger Workflow-Ausführungen pro Speicherkontingent* und anderen Kontingenten angerechnet. Um sicherzustellen, dass Sie die Workflow-Kontingente nicht überschreiten, sollten Sie einen Workflow-Auslöser verwenden, um einen Workflow bedingt zu starten, anstatt ein Gate zu verwenden. Erwägen Sie auch, anstelle eines Gates eine Regel zur Genehmigung von Pull-Requests zu verwenden. Weitere Informationen zu Kontingenten, Triggern und Genehmigungsregeln für Pull-Requests finden Sie unter [Kontingente für Workflows in CodeCatalyst](workflows-quotas.md)[Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md), und[Verwaltung der Anforderungen für das Zusammenführen einer Pull-Anfrage mit Genehmigungsregeln](source-pull-requests-approval-rules.md).
## Einschränkungen von Gates
Für Gates gelten die folgenden Einschränkungen:
+ Gates können nicht in Verbindung mit der Compute-Sharing-Funktion verwendet werden. Weitere Informationen über dieses Feature finden Sie unter [Rechenleistung für mehrere Aktionen gemeinsam nutzen](compute-sharing.md).
+ Gates können nicht innerhalb von Aktionsgruppen verwendet werden. Weitere Informationen zu Aktionsgruppen finden Sie unter[Gruppierung von Aktionen in Aktionsgruppen](workflows-group-actions.md).
# Hinzufügen eines Gates zu einem Workflow
In Amazon können Sie einem Workflow ein Tor hinzufügen CodeCatalyst, um zu verhindern, dass er fortgesetzt wird, sofern nicht bestimmte Bedingungen erfüllt sind. Gehen Sie wie folgt vor, um einem Workflow ein Gate hinzuzufügen.
Weitere Informationen zu Gates finden Sie unter[Gating eines Workflow-Laufs](workflows-gates.md).
**So fügen Sie ein Gate hinzu und konfigurieren es**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Edit** (Bearbeiten) aus.
1. Wählen Sie **Visual**.
1. Wählen Sie auf der linken Seite **Gates** aus.
1. Suchen Sie im Gate-Katalog nach einem Gate und wählen Sie dann das Pluszeichen (**\$1**), um das Gate zu Ihrem Workflow hinzuzufügen.
1. Konfigurieren Sie das Gate. Wählen Sie **Visual**, um den visuellen Editor zu verwenden, oder **YAML**, um den YAML-Editor zu verwenden. Eine ausführliche Anleitung finden Sie unter:
+ [Hinzufügen eines Genehmigungstors](workflows-approval-add.md)
1. (Optional) Wählen Sie **Validieren**, um sicherzustellen, dass der YAML-Code gültig ist.
1. Wählen Sie **Commit**, um Ihre Änderungen zu übernehmen.
# Sequenzierung von Gates und Aktionen
In Amazon können Sie ein Gate einrichten CodeCatalyst, das vor oder nach einer Workflow-Aktion, Aktionsgruppe oder einem Gate ausgeführt wird. Sie können beispielsweise ein `Approval` Gate einrichten, das vor einer `Deploy` Aktion ausgeführt wird. In diesem Fall soll die `Deploy` Aktion vom `Approval` Gate *abhängen*.
Um Abhängigkeiten zwischen Gates und Aktionen einzurichten, konfigurieren Sie das Gate oder die Aktion **Hängt von der Eigenschaft ab**. Detaillierte Anweisungen finden Sie unter [Abhängigkeiten zwischen Aktionen einrichten](workflows-depends-on-set-up.md). Die Anweisungen, auf die verwiesen wird, beziehen sich auf *Workflow-Aktionen*, gelten aber auch für Gates.
Ein Beispiel für die Einrichtung der Eigenschaft **Hängt von ab** mit einem Tor finden Sie unter[Beispiel: Ein Genehmigungstor](workflows-approval-example.md).
Weitere Informationen zu Gates finden Sie unter[Gating eines Workflow-Laufs](workflows-gates.md).
Weitere Informationen zu Workflow-Aktionen finden Sie unter[Workflow-Aktionen konfigurieren](workflows-actions.md).
# Die Version eines Gates angeben
Wenn Sie einem Workflow ein Gate hinzufügen, wird standardmäßig die Vollversion der Workflow-Definitionsdatei im folgenden Format CodeCatalyst hinzugefügt:
`vmajor.minor.patch`
Zum Beispiel:
```
My-Gate:
Identifier: aws/approval@v1
```
Sie können die Version verlängern, sodass der Workflow eine bestimmte Haupt- oder Nebenversion des Gates verwendet. Detaillierte Anweisungen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md). Das referenzierte Thema bezieht sich auf Workflow-Aktionen, gilt aber auch für Gates.
Weitere Informationen zu Gates in CodeCatalyst finden Sie unter[Gating eines Workflow-Laufs](workflows-gates.md).
# Genehmigungen für Workflow-Läufe erforderlich
Sie können eine Workflow-Ausführung so konfigurieren, dass eine Genehmigung erforderlich ist, bevor sie fortgesetzt werden kann. Um dies zu erreichen, müssen Sie dem Workflow ein **[Genehmigungstor](workflows-gates.md)** hinzufügen. Ein *Genehmigungstor* verhindert, dass ein Workflow fortgesetzt wird, bis ein Benutzer oder eine Gruppe von Benutzern eine oder mehrere Genehmigungen in der CodeCatalyst Konsole eingereicht haben. Sobald alle Genehmigungen erteilt wurden, ist das Gate „entsperrt“ und der Workflow-Lauf kann wieder aufgenommen werden.
Verwenden Sie in Ihrem Workflow ein **Genehmigungstor**, um Ihren Entwicklungs-, Betriebs- und Führungsteams die Möglichkeit zu geben, Ihre Änderungen zu überprüfen, bevor sie einem breiteren Publikum zugänglich gemacht werden.
Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
**Topics**
+ [Wie entsperre ich eine Genehmigungsschleuse?](#workflows-approval-conditions)
+ [Wann sollte das Genehmigungstor verwendet werden](#workflows-approval-when)
+ [Wer kann eine Genehmigung ausstellen?](#workflows-approval-who)
+ [Wie informiere ich Benutzer darüber, dass eine Genehmigung erforderlich ist?](#workflows-approval-notify-methods)
+ [Kann ich ein Genehmigungstor verwenden, um zu verhindern, dass eine Workflow-Ausführung gestartet wird?](#workflows-approval-prevent)
+ [Wie funktionieren Workflow-Genehmigungen in den Modi „Warteschlange“, „Ersetzt“ und „parallel Ausführung“?](#workflows-approval-run-mode)
+ [Beispiel: Ein Genehmigungstor](workflows-approval-example.md)
+ [Hinzufügen eines Genehmigungstors](workflows-approval-add.md)
+ [Konfiguration von Genehmigungsbenachrichtigungen](workflows-approval-notify.md)
+ [Einen Workflow-Lauf genehmigen oder ablehnen](workflows-approval-approve.md)
+ [Zulassungsstelle YAML](approval-ref.md)
## Wie entsperre ich eine Genehmigungsschleuse?
Um ein **Genehmigungsgate** zu entsperren, müssen *alle* der folgenden Bedingungen erfüllt sein:
+ **Bedingung 1**: Die erforderliche Anzahl von Genehmigungen muss eingereicht werden. Die erforderliche Anzahl von Genehmigungen ist konfigurierbar, und jeder Benutzer kann eine einzige Genehmigung einreichen.
+ **Bedingung 2**: Alle Genehmigungen müssen vor Ablauf der Frist eingereicht werden. Das Gate läuft 14 Tage nach seiner Aktivierung ab. Dieser Zeitraum ist nicht konfigurierbar.
+ **Bedingung 3**: Niemand darf den Workflow-Lauf ablehnen. Eine einzige Ablehnung führt dazu, dass der Workflow-Lauf fehlschlägt.
+ **Bedingung 4**: (Gilt nur, wenn Sie den abgelösten Ausführungsmodus verwenden.) Der Lauf darf nicht durch einen späteren Lauf ersetzt werden. Weitere Informationen finden Sie unter [Wie funktionieren Workflow-Genehmigungen in den Modi „Warteschlange“, „Ersetzt“ und „parallel Ausführung“?](#workflows-approval-run-mode).
****Wenn eine der Bedingungen nicht erfüllt ist, CodeCatalyst stoppt der Workflow und setzt den Ausführungsstatus auf **Fehlgeschlagen** (im Fall der **Bedingungen 1** bis **3**) oder Ersetzt (im Fall von Bedingung 4).****
## Wann sollte das Genehmigungstor verwendet werden
In der Regel verwenden Sie ein **Genehmigungsgate** in einem Workflow, bei dem Anwendungen und andere Ressourcen auf einem Produktionsserver oder in einer beliebigen Umgebung bereitgestellt werden, in der Qualitätsstandards validiert werden müssen. Indem Sie das Gate vor der Bereitstellung in der Produktion platzieren, geben Sie Prüfern die Möglichkeit, Ihre neue Softwareversion zu validieren, bevor sie der Öffentlichkeit zur Verfügung steht.
## Wer kann eine Genehmigung ausstellen?
Jeder Benutzer, der Mitglied Ihres Projekts ist und die Rolle **Mitwirkender oder** **Projektadministrator innehat**, kann eine Genehmigung erteilen. Benutzer mit der Rolle **Space-Administrator**, die dem Space Ihres Projekts angehören, können ebenfalls eine Genehmigung erteilen.
**Anmerkung**
Benutzer mit der Rolle **Prüfer** können keine Genehmigungen erteilen.
## Wie informiere ich Benutzer darüber, dass eine Genehmigung erforderlich ist?
Um Benutzer darüber zu informieren, dass eine Genehmigung erforderlich ist, müssen Sie:
+ Habe ihnen eine Slack-Benachrichtigung CodeCatalyst geschickt. Weitere Informationen finden Sie unter [Konfiguration von Genehmigungsbenachrichtigungen](workflows-approval-notify.md).
+ Gehen Sie zu der Seite in der CodeCatalyst Konsole, auf der sich die Schaltflächen **Genehmigen** und **Ablehnen** befinden, und fügen Sie die URL dieser Seite in eine E-Mail- oder Messaging-Anwendung ein, die an die Genehmiger adressiert ist. Weitere Informationen darüber, wie Sie zu dieser Seite navigieren, finden Sie unter[Einen Workflow-Lauf genehmigen oder ablehnen](workflows-approval-approve.md).
## Kann ich ein Genehmigungstor verwenden, um zu verhindern, dass eine Workflow-Ausführung gestartet wird?
Ja, mit Qualifikationen. Weitere Informationen finden Sie unter [Kann ich ein Gate verwenden, um zu verhindern, dass ein Workflow-Lauf gestartet wird?](workflows-gates.md#workflows-gates-prevent).
## Wie funktionieren Workflow-Genehmigungen in den Modi „Warteschlange“, „Ersetzt“ und „parallel Ausführung“?
[Wenn Sie den Modus „Warteschlange“, „Ersetzt“ oder „parallel Ausführung“ verwenden, funktioniert das **Genehmigungsgate** ähnlich wie Aktionen.](workflows-actions.md) Wir empfehlen[Informationen zum Ausführungsmodus in der Warteschlange](workflows-configure-runs.md#workflows-configure-runs-queued), die [Über den Parallellaufmodus](workflows-configure-runs.md#workflows-configure-runs-parallel) Abschnitte,, zu lesen[Über den abgelösten Ausführungsmodus](workflows-configure-runs.md#workflows-configure-runs-superseded), um sich mit diesen Ausführungsmodi vertraut zu machen. Sobald Sie ein grundlegendes Verständnis dieser Modi haben, kehren Sie zu diesem Abschnitt zurück, um herauszufinden, wie diese Ausführungsmodi funktionieren, wenn das **Genehmigungstor** vorhanden ist.
Wenn das **Genehmigungsgate** vorhanden ist, werden Läufe wie folgt verarbeitet:
+ Wenn Sie den [Ausführungsmodus in der Warteschlange](workflows-configure-runs.md#workflows-configure-runs-queued) verwenden, werden die Läufe hinter dem Lauf in die Warteschlange gestellt, der derzeit am Gate auf die Genehmigung wartet. Wenn dieses Gate entsperrt ist (d. h., alle Genehmigungen wurden erteilt), wird der nächste Lauf in der Warteschlange zum Gate weitergeleitet und wartet auf Genehmigungen. Dieser Prozess wird fortgesetzt, wobei Läufe in der Warteschlange durch das Gate verarbeitet werden. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)veranschaulicht diesen Prozess.
+ Wenn Sie den [abgelösten Ausführungsmodus](workflows-configure-runs.md#workflows-configure-runs-superseded) verwenden, ist das Verhalten dasselbe wie im Ausführungsmodus in der Warteschlange, mit dem Unterschied, dass sich die Läufe nicht in der Warteschlange am Gate häufen, sondern dass neuere Läufe frühere Läufe ablösen (übernehmen). Es gibt keine Warteschlangen, und jeder Lauf, der derzeit am Gate auf eine Genehmigung wartet, wird storniert und durch einen neueren Lauf ersetzt. [Figure 2](#figure-2-workflow-superseded-run-mode-ma)veranschaulicht diesen Prozess.
+ Wenn Sie den [parallelen Ausführungsmodus](workflows-configure-runs.md#workflows-configure-runs-parallel) verwenden, starten die Läufe parallel und es bilden sich keine Warteschlangen. Jeder Lauf wird sofort vom Gate verarbeitet, da keine Läufe davor liegen. [Figure 3](#figure-3-workflow-parallel-run-mode-ma)veranschaulicht diesen Prozess.
**Abbildung 1****: „Ausführungsmodus in der Warteschlange“ und ein Genehmigungstor**
![\[So funktioniert ein Genehmigungsgate mit dem „Ausführungsmodus in der Warteschlange“\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**Abbildung 2****: „Ersetzter Ausführungsmodus“ und ein Genehmigungsgate**
![\[Wie funktioniert ein „Genehmigungsgate“ mit dem „abgelösten Ausführungsmodus“\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**Abbildung 3****: „Paralleler Ausführungsmodus“ und ein Genehmigungsgate**
![\[So funktioniert ein „Approval“ -Gate mit dem „Parallellaufmodus“\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# Beispiel: Ein Genehmigungstor
Das folgende Beispiel zeigt, wie ein **Genehmigungstor** hinzugefügt wird, das `Approval_01` zwischen zwei aufgerufenen Aktionen aufgerufen wird`Staging`, und`Production`. Die `Staging` Aktion wird zuerst ausgeführt, das `Approval_01` Gate als zweites und die `Production` Aktion zuletzt. Die `Production` Aktion wird nur ausgeführt, wenn das `Approval_01` Tor entriegelt ist. Die `DependsOn` Eigenschaft stellt sicher, dass die `Production` Phasen `Staging``Approval_01`, und in sequentieller Reihenfolge ausgeführt werden.
Weitere Informationen zum **Genehmigungstor** finden Sie unter[Genehmigungen für Workflow-Läufe erforderlich](workflows-approval.md).
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# Hinzufügen eines Genehmigungstors
Um Ihren Workflow so zu konfigurieren, dass er eine Genehmigung erfordert, müssen Sie dem Workflow das **Genehmigungstor** hinzufügen. Verwenden Sie die folgenden Anweisungen, um Ihrem Workflow ein **Genehmigungstor** hinzuzufügen.
Weitere Informationen zu diesem Gate finden Sie unter[Genehmigungen für Workflow-Läufe erforderlich](workflows-approval.md).
------
#### [ Visual ]
**So fügen Sie einem Workflow ein Genehmigungstor hinzu (visueller Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie links oben **Gates** aus.
1. Wählen Sie im **Gates-Katalog** unter **Approval** das Pluszeichen (**\$1**) aus.
1. Wählen Sie **Eingaben** aus, und gehen Sie im Feld **Abhängig von** wie folgt vor.
Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, das erfolgreich ausgeführt werden muss, damit dieses Gate ausgeführt werden kann. Wenn Sie einem Workflow ein Gate hinzufügen, ist das Gate standardmäßig so eingestellt, dass es von der letzten Aktion in Ihrem Workflow abhängt. Wenn Sie diese Eigenschaft entfernen, ist das Gate von nichts abhängig und wird zuerst ausgeführt, bevor andere Aktionen ausgeführt werden.
**Anmerkung**
Ein Gate muss so konfiguriert werden, dass es vor oder nach einer Aktion, Aktionsgruppe oder einem Gate ausgeführt wird. Es kann nicht so eingerichtet werden, dass es parallel zu anderen Aktionen, Aktionsgruppen und Gates läuft.
Weitere Hinweise zur Funktion **Hängt von ab**, finden Sie unter[Sequenzierung von Gates und Aktionen](workflows-gates-depends-on.md).
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Gehen Sie im Feld **Gate-Name** wie folgt vor.
Geben Sie den Namen an, den Sie dem Tor geben möchten. Alle Gate-Namen müssen innerhalb des Workflows eindeutig sein. Gate-Namen sind auf alphanumerische Zeichen (a-z, A-Z, 0-9), Bindestriche (-) und Unterstriche (\$1) beschränkt. Leerzeichen sind nicht erlaubt. Sie können keine Anführungszeichen verwenden, um Sonderzeichen und Leerzeichen in Gate-Namen zuzulassen.
1. (Optional) Gehen Sie im Feld **Anzahl der Genehmigungen** wie folgt vor.
Geben Sie die Mindestanzahl an Genehmigungen an, die erforderlich sind, um das **Genehmigungstor** zu entsperren. Das Minimum ist`1`. Das Maximum ist`2`. Wenn es weggelassen wird, ist die Standardeinstellung`1`.
**Anmerkung**
Wenn Sie die `ApprovalsRequired` Eigenschaft weglassen möchten, entfernen Sie den `Configuration` Abschnitt des Gates aus der Workflow-Definitionsdatei.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
#### [ YAML ]
**Um einem Workflow ein Genehmigungstor hinzuzufügen (YAML-Editor)**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Fügen Sie anhand des folgenden Beispiels einen `Approval` Abschnitt und die zugrunde liegenden Eigenschaften hinzu. Weitere Informationen finden Sie unter [Zulassungsstelle YAML](approval-ref.md) im [YAML-Workflow-Definition](workflow-reference.md).
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
Ein weiteres Beispiel finden Sie unter [Beispiel: Ein Genehmigungstor](workflows-approval-example.md).
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
# Konfiguration von Genehmigungsbenachrichtigungen
Du kannst eine Benachrichtigung CodeCatalyst an einen Slack-Channel senden, um Benutzer darüber zu informieren, dass für einen Workflow-Lauf eine Genehmigung erforderlich ist. Benutzer sehen die Benachrichtigung und klicken auf den darin enthaltenen Link. Über den Link gelangen sie zu einer CodeCatalyst Genehmigungsseite, auf der sie den Workflow entweder genehmigen oder ablehnen können.
Sie können auch Benachrichtigungen konfigurieren, um Benutzer darüber zu informieren, dass ein Workflow genehmigt oder abgelehnt wurde oder dass die Genehmigungsanfrage abgelaufen ist.
Verwende die folgenden Anweisungen, um Slack-Benachrichtigungen einzurichten.
**Bevor Sie beginnen**
Vergewissere dich, dass du deinem Workflow ein **Genehmigungstor** hinzugefügt hast. Weitere Informationen finden Sie unter [Hinzufügen eines Genehmigungstors](workflows-approval-add.md).
**Um Benachrichtigungen zur Workflow-Genehmigung an einen Slack-Kanal zu senden**
1. CodeCatalyst Mit Slack konfigurieren. Weitere Informationen finden Sie unter [Erste Schritte mit Slack-Benachrichtigungen](getting-started-notifications.md).
1. Aktiviere in dem CodeCatalyst Projekt, das den Workflow enthält, für den eine Genehmigung erforderlich ist, Benachrichtigungen, sofern sie nicht bereits aktiviert sind. Um Benachrichtigungen zu aktivieren:
1. Navigieren Sie zu Ihrem Projekt und wählen Sie im Navigationsbereich **Projekteinstellungen** aus.
1. Wählen Sie oben **Benachrichtigungen** aus.
1. Wählen Sie unter **Benachrichtigungsereignisse** die Option **Benachrichtigungen bearbeiten** aus.
1. Aktiviere die Option **Workflow-Genehmigung steht noch** aus und wähle einen Slack-Channel aus, an den die Benachrichtigung gesendet CodeCatalyst werden soll.
1. (Optional) Aktiviere zusätzliche Benachrichtigungen, um Nutzer über genehmigte, abgelehnte und abgelaufene Genehmigungen zu informieren. Sie können die Optionen **Workflow-Ausführung genehmigt**, **Workflow-Ausführung abgelehnt**, **Workflow-Genehmigung ersetzt** und **Workflow-Genehmigung hat Timeout** aktiviert. Wähle neben jeder Benachrichtigung den Slack-Channel aus, an den die Benachrichtigung gesendet CodeCatalyst werden soll.
1. Wählen Sie **Save (Speichern)** aus.
# Einen Workflow-Lauf genehmigen oder ablehnen
Workflow-Läufe, die das **Genehmigungstor** beinhalten, müssen genehmigt oder abgelehnt werden. Benutzer können ihre Zustimmung oder Ablehnung ab folgenden Bedingungen erteilen:
+ die CodeCatalyst Konsole
+ ein Link, der von einem Teammitglied bereitgestellt wurde
+ eine automatisierte Slack-Benachrichtigung
Nachdem ein Benutzer seine Zustimmung oder Ablehnung erteilt hat, kann diese Entscheidung nicht mehr rückgängig gemacht werden.
**Anmerkung**
Nur bestimmte Benutzer können eine Workflow-Ausführung genehmigen oder ablehnen. Weitere Informationen finden Sie unter [Wer kann eine Genehmigung ausstellen?](workflows-approval.md#workflows-approval-who).
**Bevor Sie beginnen**
Stellen Sie sicher, dass Sie Ihrem Workflow ein **Genehmigungstor** hinzugefügt haben. Weitere Informationen finden Sie unter [Hinzufügen eines Genehmigungstors](workflows-approval-add.md).
**Um einen Workflow zu genehmigen oder abzulehnen, starten Sie ihn von der CodeCatalyst Konsole aus**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie im Workflow-Diagramm das Feld aus, das das **Genehmigungstor** darstellt.
Ein Seitenbereich wird angezeigt.
**Anmerkung**
An dieser Stelle können Sie die URL dieser Seite an andere Genehmiger senden, wenn Sie möchten.
1. Wählen Sie unter **Entscheidung überprüfen** die Option **Genehmigen** oder **Ablehnen** aus.
1. (Optional) Geben Sie im Feld **Kommentar — optional** einen Kommentar ein, der angibt, warum Sie den Workflow-Lauf genehmigt oder abgelehnt haben.
1. Wählen Sie **Absenden** aus.
**So genehmigen oder lehnen Sie einen Workflow-Lauf ab, der über einen von einem Teammitglied bereitgestellten Link erfolgt**
1. Wählen Sie den Link, den Sie von Ihrem Teammitglied erhalten haben. (Sie können Ihr Teammitglied das vorherige Verfahren lesen lassen, um den Link zu erhalten.)
1. Melden Sie sich an CodeCatalyst, wenn Sie dazu aufgefordert werden.
Sie werden auf die Seite zur Genehmigung der Workflow-Ausführung weitergeleitet.
1. Wählen Sie unter **Entscheidung überprüfen** die Option **Genehmigen** oder **Ablehnen** aus.
1. (Optional) Geben Sie im Feld **Kommentar — optional** einen Kommentar ein, der angibt, warum Sie den Workflow-Lauf genehmigt oder abgelehnt haben.
1. Wählen Sie **Absenden** aus.
**Um einen Workflow-Lauf ausgehend von einer automatisierten Slack-Benachrichtigung zu genehmigen oder abzulehnen**
1. Stelle sicher, dass Slack-Benachrichtigungen eingerichtet sind. Siehe [Konfiguration von Genehmigungsbenachrichtigungen](workflows-approval-notify.md).
1. Wähle in Slack in dem Channel, an den die Genehmigungsbenachrichtigung gesendet wurde, den Link in der Genehmigungsbenachrichtigung aus.
1. Melde dich an CodeCatalyst, wenn du dazu aufgefordert wirst.
Sie werden zur Workflow-Ausführungsseite weitergeleitet.
1. Wählen Sie im Workflow-Diagramm das Genehmigungstor aus.
1. Wählen Sie unter **Entscheidung überprüfen** die Option **Genehmigen** oder **Ablehnen** aus.
1. (Optional) Geben Sie im Feld **Kommentar — optional** einen Kommentar ein, der angibt, warum Sie den Workflow-Lauf genehmigt oder abgelehnt haben.
1. Wählen Sie **Absenden** aus.
# Zulassungsstelle YAML
Im Folgenden finden Sie die YAML-Definition des **Approval Gates**. Informationen zur Verwendung dieses Gates finden Sie unter[Genehmigungen für Workflow-Läufe erforderlich](workflows-approval.md).
Diese Aktionsdefinition ist als Abschnitt in einer umfassenderen Workflow-Definitionsdatei vorhanden. Weitere Informationen über diese Datei finden Sie unter [YAML-Workflow-Definition](workflow-reference.md).
**Anmerkung**
Die meisten der folgenden YAML-Eigenschaften haben entsprechende Benutzeroberflächenelemente im visuellen Editor. Verwenden Sie **Strg\$1F**, um nach einem UI-Element zu suchen. Das Element wird mit der zugehörigen YAML-Eigenschaft aufgelistet.
```
# The workflow definition starts here.
# See Eigenschaften der obersten Ebene for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(Erforderlich)
Geben Sie den Namen an, den Sie dem Gate geben möchten. Alle Gate-Namen müssen innerhalb des Workflows eindeutig sein. Gate-Namen sind auf alphanumerische Zeichen (a-z, A-Z, 0-9), Bindestriche (-) und Unterstriche (\$1) beschränkt. Leerzeichen sind nicht erlaubt. Sie können keine Anführungszeichen verwenden, um Sonderzeichen und Leerzeichen in Gate-Namen zuzulassen.
Standard: `Approval_nn`.
Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Gate-Name**“
## Identifier
(*Approval*/**Identifier**)
(Erforderlich)
Identifiziert das Gate. Das **Approval** Gate unterstützt die Version`1.0.0`. Ändern Sie diese Eigenschaft nicht, es sei denn, Sie möchten die Version verkürzen. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).
Standard: `aws/approval@v1`.
**Entsprechende Benutzeroberfläche: Workflow-Diagram/ Approval \$1nn/ aws/approval @v1 label**
## DependsOn
(*Approval*/**DependsOn**)
(Optional)
Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, das erfolgreich ausgeführt werden muss, damit dieses Gate ausgeführt werden kann. Wenn Sie einem Workflow ein Gate hinzufügen, ist das Gate standardmäßig so eingestellt, dass es von der letzten Aktion in Ihrem Workflow abhängt. Wenn Sie diese Eigenschaft entfernen, ist das Gate von nichts abhängig und wird zuerst ausgeführt, bevor andere Aktionen ausgeführt werden.
**Anmerkung**
Ein Gate muss so konfiguriert werden, dass es vor oder nach einer Aktion, Aktionsgruppe oder einem Gate ausgeführt wird. Es kann nicht so eingerichtet werden, dass es parallel zu anderen Aktionen, Aktionsgruppen und Gates läuft.
Weitere Hinweise zur Funktion **Hängt von ab**, finden Sie unter[Sequenzierung von Gates und Aktionen](workflows-gates-depends-on.md).
Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/**Hängt ab von**
## Configuration
(*Approval*/**Configuration**)
(Optional)
Ein Abschnitt, in dem Sie die Konfigurationseigenschaften des Gates definieren können.
Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(Optional)
Geben Sie die Mindestanzahl an Genehmigungen an, die erforderlich sind, um das **Genehmigungstor** zu entsperren. Das Minimum ist`1`. Das Maximum ist`2`. Wenn es weggelassen wird, ist die Standardeinstellung`1`.
**Anmerkung**
Wenn Sie die `ApprovalsRequired` Eigenschaft weglassen möchten, entfernen Sie den `Configuration` Abschnitt des Gates aus der Workflow-Definitionsdatei.
Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Anzahl der Genehmigungen**
# Konfiguration des Warteschlangenverhaltens von Läufen
Wenn in Amazon CodeCatalyst mehrere Workflow-Ausführungen gleichzeitig ausgeführt werden, werden sie standardmäßig in eine CodeCatalyst Warteschlange gestellt und nacheinander in der Reihenfolge verarbeitet, in der sie gestartet wurden. Sie können dieses Standardverhalten ändern, indem Sie einen *Ausführungsmodus* angeben. Es gibt einige Ausführungsmodi:
+ (Standard) Ausführungsmodus in Warteschlange — CodeCatalyst Prozesse werden nacheinander ausgeführt
+ Ersetzter Ausführungsmodus — CodeCatalyst Prozesse werden nacheinander ausgeführt, wobei neuere Läufe ältere überholen
+ Parallellauffunktion — CodeCatalyst Prozesse laufen parallel
Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
**Topics**
+ [Informationen zum Ausführungsmodus in der Warteschlange](#workflows-configure-runs-queued)
+ [Über den abgelösten Ausführungsmodus](#workflows-configure-runs-superseded)
+ [Über den Parallellaufmodus](#workflows-configure-runs-parallel)
+ [Konfiguration des Ausführungsmodus](#workflows-configure-runs-configure)
## Informationen zum Ausführungsmodus in der Warteschlange
Im *Modus „Ausführung in der Warteschlange*“ werden Läufe nacheinander ausgeführt, wobei Warteläufe eine Warteschlange bilden.
Warteschlangen bilden sich an den Eingangspunkten zu Aktionen und Aktionsgruppen, sodass Sie *mehrere Warteschlangen innerhalb desselben Workflows* haben können (siehe). [Figure 1](#figure-1-workflow-queued-run-mode) Wenn ein Lauf in der Warteschlange in eine Aktion aufgenommen wird, ist die Aktion gesperrt und es können keine weiteren Läufe mehr hinzugefügt werden. Wenn der Lauf abgeschlossen ist und die Aktion beendet wird, wird die Aktion entsperrt und ist bereit für den nächsten Lauf.
[Figure 1](#figure-1-workflow-queued-run-mode)veranschaulicht einen Workflow, der im Ausführungsmodus in der Warteschlange konfiguriert ist. Sie zeigt folgende Informationen an:
+ Sieben Läufe arbeiten sich ihren Weg durch den Workflow.
+ Zwei Warteschlangen: eine außerhalb des Eingangs zur Eingabequelle (**repo:Main**) und eine außerhalb des Eingangs zur Aktion. **BuildTestActionGroup**
+ Zwei gesperrte Blöcke: die Eingangsquelle (**repo:Main**) und der. **BuildTestActionGroup**
So werden sich die Dinge entwickeln, wenn der Workflow läuft und die Verarbeitung abgeschlossen ist:
+ **Wenn **Run-4D444** das Klonen des Quell-Repositorys abgeschlossen hat, verlässt es die Eingabequelle und tritt der Warteschlange hinter Run-3c333 bei.** **Dann wird Run-5e555 die Eingabequelle aufrufen.**
+ Wenn **Run-1a111** mit dem Erstellen und Testen fertig ist, wird die Aktion beendet und die Aktion gestartet. **BuildTestActionGroup**DeployAction**** Dann wird **Run-2b222** die Aktion starten. **BuildTestActionGroup**
**Abbildung 1**: Ein Workflow, der im Modus „Ausführung in der Warteschlange“ konfiguriert ist
![\[Ein im Modus „Ausführung in Warteschlange“ konfigurierter Workflow\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Verwenden Sie den Ausführungsmodus in der Warteschlange, wenn:
+ **Sie möchten eine one-to-one Beziehung zwischen Features und Läufen beibehalten — diese Features können gruppiert werden, wenn der Modus „Ersetzt“ verwendet wird.** Wenn Sie beispielsweise Feature 1 in Commit 1 zusammenführen, wird Lauf 1 gestartet, und wenn Sie Feature 2 in Commit 2 zusammenführen, startet Lauf 2 usw. Wenn Sie den abgelösten Modus anstelle des Warteschlangenmodus verwenden würden, werden Ihre Features (und Commits) in der Ausführung gruppiert, die die anderen ersetzt.
+ **Sie möchten Rennbedingungen und unerwartete Probleme vermeiden, die bei der Verwendung des Parallelmodus auftreten können**. Wenn beispielsweise zwei Softwareentwickler, Wang und Saanvi, Workflow-Läufe ungefähr zur gleichen Zeit starten, um sie auf einem Amazon ECS-Cluster bereitzustellen, kann Wangs Lauf Integrationstests auf dem Cluster beginnen, während der Lauf von Saanvi neuen Anwendungscode für den Cluster bereitstellt, was dazu führt, dass Wangs Tests entweder fehlschlagen oder den falschen Code testen. Ein weiteres Beispiel könnte sein, dass Sie ein Ziel haben, das keinen Sperrmechanismus hat. In diesem Fall könnten die beiden Läufe die Änderungen des jeweils anderen auf unerwartete Weise überschreiben.
+ **Sie möchten die Belastung der Rechenressourcen begrenzen**, die für die Verarbeitung Ihrer Läufe CodeCatalyst verwendet werden. Wenn Sie beispielsweise drei Aktionen in Ihrem Workflow haben, können Sie maximal drei Läufe gleichzeitig ausführen lassen. Wenn die Anzahl der Durchläufe, die gleichzeitig ausgeführt werden können, begrenzt wird, lässt sich der Durchsatz der Durchläufe besser vorhersagen.
+ **Sie möchten die Anzahl der Anfragen einschränken, die der Workflow an Dienste von Drittanbietern** stellt. Ihr Workflow könnte beispielsweise eine Build-Aktion enthalten, die Anweisungen zum Abrufen eines Images aus Docker Hub enthält. [Docker Hub begrenzt die Anzahl der Pull-Anfragen](https://www.docker.com/increase-rate-limits), die Sie stellen können, auf eine bestimmte Anzahl pro Stunde und Konto. Wenn Sie das Limit überschreiten, werden Sie gesperrt. Wenn Sie den Ausführungsmodus in der Warteschlange verwenden, um Ihren Durchsatz zu verlangsamen, werden weniger Anfragen an Docker Hub pro Stunde generiert, wodurch das Potenzial für Sperrungen und daraus resultierende Build- und Run-Fehler begrenzt wird.
**Maximale Warteschlangengröße**: 50
Hinweise zur **maximalen Warteschlangengröße**:
+ Die maximale Warteschlangengröße bezieht sich auf die maximale Anzahl von Durchläufen, die in *allen Warteschlangen* im Workflow zulässig sind.
+ Wenn eine Warteschlange länger als 50 Läufe wird CodeCatalyst , werden die 51. und die nachfolgenden Läufe gelöscht.
**Verhalten bei Fehlern**:
Wenn ein Lauf nicht mehr reagiert, während er durch eine Aktion verarbeitet wird, werden die dahinter stehenden Läufe in der Warteschlange zurückgehalten, bis die Aktion das Timeout erreicht. Aktionen laufen nach einer Stunde ab.
Wenn ein Lauf innerhalb einer Aktion fehlschlägt, darf der erste Lauf, der sich dahinter in der Warteschlange befindet, fortgesetzt werden.
## Über den abgelösten Ausführungsmodus
Der *abgelöste Ausführungsmodus entspricht dem Ausführungsmodus* in der *Warteschlange*, mit der Ausnahme, dass:
+ Wenn ein Lauf in der Warteschlange einen anderen Lauf in der Warteschlange einholt, ersetzt (übernimmt) der spätere Lauf den früheren Lauf, und der frühere Lauf wird abgebrochen und als „ersetzt“ markiert.
+ Aufgrund des im ersten Punkt beschriebenen Verhaltens kann eine Warteschlange nur einen Lauf enthalten, wenn der Modus „Ersetzte Ausführung“ verwendet wird.
Wenn Sie den Arbeitsablauf [Figure 1](#figure-1-workflow-queued-run-mode) als Leitfaden verwenden, würde die Anwendung des ersetzten Ausführungsmodus auf diesen Workflow zu folgenden Ergebnissen führen:
+ **Run-7g777** **würde die anderen beiden Läufe in der Warteschlange ersetzen und wäre der einzige in Warteschlange \$11 verbleibende Lauf.** **Run-6F666 und **Run-5E555 würden abgebrochen**.**
+ **Run-3c333 würde Run-2b222** ****ersetzen und wäre der einzige verbleibende Lauf in Warteschlange \$12.**** **Run-2b222** würde abgebrochen werden.
Verwenden Sie den abgelösten Ausführungsmodus, wenn Sie:
+ besserer Durchsatz als im Warteschlangenmodus
+ noch weniger Anfragen an Dienste von Drittanbietern als im Warteschlangenmodus; dies ist vorteilhaft, wenn für den Drittanbieter-Service Ratenbegrenzungen gelten, wie z. B. Docker Hub
## Über den Parallellaufmodus
Im *Parallellaufmodus* sind Läufe unabhängig voneinander und warten nicht, bis andere Läufe abgeschlossen sind, bevor sie gestartet werden. Es gibt keine Warteschlangen, und der Durchsatz der Ausführung wird nur dadurch begrenzt, wie schnell die Aktionen innerhalb des Workflows abgeschlossen werden.
Verwenden Sie den parallel Ausführungsmodus in Entwicklungsumgebungen, in denen jeder Benutzer seinen eigenen Feature-Branch hat und auf Zielen bereitgestellt wird, die nicht von anderen Benutzern gemeinsam genutzt werden.
**Wichtig**
Wenn Sie ein gemeinsames Ziel haben, für das mehrere Benutzer bereitstellen können, z. B. eine Lambda-Funktion in einer Produktionsumgebung, verwenden Sie den Parallelmodus nicht, da dies zu Rennbedingungen führen kann. Eine *Race-Condition* tritt auf, wenn parallel Workflow-Läufe versuchen, eine gemeinsam genutzte Ressource gleichzeitig zu ändern, was zu unvorhersehbaren Ergebnissen führt.
**Maximale Anzahl parallel Läufe**: 1000 pro CodeCatalyst Feld
## Konfiguration des Ausführungsmodus
Sie können den Ausführungsmodus auf „In Warteschlange“, „Ersetzt“ oder „Parallel“ setzen. Die Standardeinstellung ist in der Warteschlange.
Wenn Sie den Ausführungsmodus von „In Warteschlange“ oder „ersetzt“ in „Parallel“ ändern, werden die Läufe in der Warteschlange CodeCatalyst abgebrochen und die Läufe, die derzeit von einer Aktion verarbeitet werden, beendet, bevor sie abgebrochen werden.
Wenn Sie den Ausführungsmodus von „Parallel“ in „In Warteschlange gestellt“ oder „ersetzt“ ändern, werden alle derzeit laufenden parallel CodeCatalyst Läufe abgeschlossen. Alle Läufe, die Sie starten, nachdem Sie den Ausführungsmodus in Warteschlange oder ersetzt geändert haben, verwenden den neuen Modus.
------
#### [ Visual ]
**Um den Ausführungsmodus mit dem Visual Editor zu ändern**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Edit** (Bearbeiten) aus.
1. Wählen Sie oben rechts die Option **Workflow-Eigenschaften** aus.
1. Erweitern Sie **Erweitert** und wählen Sie unter **Ausführungsmodus** eine der folgenden Optionen aus:
1. In der **Warteschlange** — siehe [Informationen zum Ausführungsmodus in der Warteschlange](#workflows-configure-runs-queued)
1. **Ersetzt — siehe** [Über den abgelösten Ausführungsmodus](#workflows-configure-runs-superseded)
1. **Parallel** — siehe [Über den Parallellaufmodus](#workflows-configure-runs-parallel)
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
#### [ YAML ]
**Um den Ausführungsmodus mit dem YAML-Editor zu ändern**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Edit** (Bearbeiten) aus.
1. Wählen Sie **YAML.**
1. Fügen Sie die `RunMode` Eigenschaft wie folgt hinzu:
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Weitere Informationen finden Sie in der Beschreibung der `RunMode` Immobilie im [Eigenschaften der obersten Ebene](workflow-reference.md#workflow.top.level) Abschnitt der[YAML-Workflow-Definition](workflow-reference.md).
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
# Zwischenspeichern von Dateien zwischen Workflow-Läufen
Wenn das Zwischenspeichern von Dateien aktiviert ist, speichern die Build- und Testaktionen Dateien auf der Festplatte in einem Cache und stellen sie in nachfolgenden Workflow-Ausführungen aus diesem Cache wieder her. Durch das Zwischenspeichern wird die Latenz reduziert, die durch das Erstellen oder Herunterladen von Abhängigkeiten verursacht wird, die sich zwischen den Läufen nicht geändert haben. CodeCatalyst unterstützt auch Fallback-Caches, mit denen Teil-Caches wiederhergestellt werden können, die einige der benötigten Abhängigkeiten enthalten. Dies trägt dazu bei, die Latenzauswirkungen eines Cache-Fehlers zu reduzieren.
**Anmerkung**
Datei-Caching ist nur mit den CodeCatalyst [Build](build-workflow-actions.md) - und [Testaktionen](test-workflow-actions.md) von Amazon verfügbar und nur, wenn sie für die Verwendung des **EC2**[Berechnungstyps](workflows-working-compute.md#compute.types) konfiguriert sind.
**Topics**
+ [Über das Zwischenspeichern von Dateien](#workflows-caching.files)
+ [Einen Cache erstellen](#workflows-caching.fallback)
+ [Einschränkungen beim Zwischenspeichern von Dateien](#workflows-caching.constraints)
## Über das Zwischenspeichern von Dateien
Das Zwischenspeichern von Dateien ermöglicht es Ihnen, Ihre Daten in mehreren Caches zu organisieren, auf die jeweils unter der Eigenschaft verwiesen wird. `FileCaching` Jeder Cache speichert ein Verzeichnis, das durch einen bestimmten Pfad angegeben ist. Das angegebene Verzeichnis wird bei future Workflow-Ausführungen wiederhergestellt. Im Folgenden finden Sie ein Beispiel für ein YAML-Snippet für das Caching mit mehreren Caches mit dem Namen und. `cacheKey1` `cacheKey2`
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**Anmerkung**
CodeCatalyst verwendet mehrschichtiges Caching, das aus einem lokalen Cache und einem Remote-Cache besteht. Wenn bereitgestellte Flotten oder On-Demand-Computer auf einen Cache-Fehler in einem lokalen Cache stoßen, werden Abhängigkeiten aus einem Remote-Cache wiederhergestellt. Aus diesem Grund kann es bei einigen Aktionsläufen zu Latenzen beim Herunterladen eines Remote-Caches kommen.
CodeCatalyst wendet Cache-Zugriffsbeschränkungen an, um sicherzustellen, dass eine Aktion in einem Workflow die Caches eines anderen Workflows nicht ändern kann. Dadurch wird jeder Workflow vor anderen Workflows geschützt, die möglicherweise falsche Daten weiterleiten, die sich auf Builds oder Bereitstellungen auswirken. Einschränkungen werden durch Cache-Bereiche durchgesetzt, die Caches für jeden Workflow und jede Branch-Paarung isolieren. Beispielsweise `feature-A` hat ein Branch einen anderen Datei-Cache als ein Schwester-Branch. `workflow-A` `workflow-A` `feature-B`
Cachefehler treten auf, wenn ein Workflow nach einem bestimmten Dateicache sucht und ihn nicht finden kann. Dies kann mehrere Gründe haben, z. B. wenn ein neuer Branch erstellt wird oder wenn auf einen neuen Cache verwiesen wird, der noch nicht erstellt wurde. Es kann auch vorkommen, wenn ein Cache abläuft, was standardmäßig 14 Tage nach seiner letzten Verwendung der Fall ist. CodeCatalyst Unterstützt Fallback-Caches, um Cache-Fehlschläge zu vermeiden und die Rate von Cache-Treffern zu erhöhen. Fallback-Caches sind alternative Caches und bieten die Möglichkeit, partielle Caches wiederherzustellen, bei denen es sich um eine ältere Version eines Caches handeln kann. Ein Cache wird wiederhergestellt, indem zunächst unter dem Eigenschaftsnamen nach einem Treffer gesucht wird. `FileCaching` Falls er nicht gefunden wird, wird er ausgewertet. `RestoreKeys` Wenn sowohl für den Eigenschaftsnamen als auch für die gesamte Eigenschaft ein Cache-Fehler auftritt`RestoreKeys`, wird der Workflow weiter ausgeführt, da das Zwischenspeichern nach bestem Bemühen erfolgt und nicht garantiert werden kann.
## Einen Cache erstellen
Sie können die folgenden Anweisungen verwenden, um Ihrem Workflow einen Cache hinzuzufügen.
------
#### [ Visual ]
**Um einen Cache mit dem Visual Editor hinzuzufügen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Visual**.
1. Wählen Sie im Workflow-Diagramm die Aktion aus, zu der Sie Ihren Cache hinzufügen möchten.
1. Wählen Sie **Konfiguration**.
1. Wählen Sie unter **Datei-Caching — optional** die Option **Cache hinzufügen** aus und geben Sie Informationen wie folgt in die Felder ein:
**Key** (Schlüssel)
Geben Sie den Namen Ihrer primären Cache-Eigenschaft an. Die Namen der Cache-Eigenschaften müssen innerhalb Ihres Workflows eindeutig sein. Jede Aktion kann bis zu fünf Einträge enthalten`FileCaching`.
**Pfad**
Geben Sie den zugehörigen Pfad für Ihren Cache an.
**Schlüssel wiederherstellen — optional**
Geben Sie den Wiederherstellungsschlüssel an, der als Fallback verwendet werden soll, wenn die primäre Cache-Eigenschaft nicht gefunden werden kann. Die Namen der Wiederherstellungsschlüssel müssen innerhalb Ihres Workflows eindeutig sein. Jeder Cache kann bis zu fünf Einträge enthalten`RestoreKeys`.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein, und wählen Sie dann erneut **Commit** aus.
------
#### [ YAML ]
**Um einen Cache mit dem YAML-Editor hinzuzufügen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Fügen Sie in einer Workflow-Aktion Code hinzu, der dem folgenden ähnelt:
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Festschreiben zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
## Einschränkungen beim Zwischenspeichern von Dateien
Im Folgenden finden Sie die Einschränkungen für den Eigenschaftsnamen und`RestoreKeys`:
+ Namen müssen innerhalb eines Workflows eindeutig sein.
+ Namen sind auf alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-) und Unterstriche (\$1) beschränkt.
+ Namen können bis zu 180 Zeichen lang sein.
+ Jede Aktion kann bis zu fünf Caches enthalten. `FileCaching`
+ Jeder Cache kann bis zu fünf Einträge enthalten. `RestoreKeys`
Im Folgenden sind die Einschränkungen für Pfade aufgeführt:
+ Sternchen (\$1) sind nicht erlaubt.
+ Pfade können bis zu 255 Zeichen lang sein.
# Status und Details der Workflow-Ausführung anzeigen
IN Amazon CodeCatalyst können Sie den Status und die Details eines einzelnen Workflow-Laufs oder mehrerer Läufe gleichzeitig einsehen.
Eine Liste möglicher Ausführungsstatus finden Sie unter[Status der Workflow-Ausführung](workflows-view-run-status.md).
**Anmerkung**
Sie können auch den Workflow-Status anzeigen, der sich vom *Workflow-Ausführungsstatus* unterscheidet. Weitere Informationen finden Sie unter [Status eines Workflows anzeigen](workflows-view-status.md).
Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
**Topics**
+ [Status und Details eines einzelnen Laufs anzeigen](#workflows-view-run-single)
+ [Status und Details aller Läufe in Ihrem Projekt anzeigen](#workflows-view-run-all)
+ [Status und Details aller Ausführungen eines bestimmten Workflows anzeigen](#workflows-view-run-wf)
+ [Läufe eines Workflows im Workflow-Diagramm anzeigen](#workflows-view-run-wf-diagram)
## Status und Details eines einzelnen Laufs anzeigen
Möglicherweise möchten Sie den Status und die Details einer einzelnen Workflow-Ausführung anzeigen, um zu überprüfen, ob sie erfolgreich war, zu welchem Zeitpunkt sie abgeschlossen wurde oder um zu sehen, wer oder was sie gestartet hat.
**Um den Status und die Details eines einzelnen Laufs anzuzeigen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie unter dem Namen des Workflows die Option **Läufe** aus.
1. Wählen **Sie im Ausführungsverlauf** in der Spalte **Lauf-ID** einen Lauf aus. Beispiel, `Run-95a4d`.
1. Führen Sie unter dem Namen des Laufs einen der folgenden Schritte aus:
+ **Visuell**, um ein Workflow-Diagramm zu sehen, das die Aktionen Ihres Workflow-Laufs und deren Status zeigt (siehe[Status der Workflow-Ausführung](workflows-view-run-status.md)). In dieser Ansicht werden auch das Quell-Repository und der Branch angezeigt, die während der Ausführung verwendet wurden.
Wählen Sie im Workflow-Diagramm eine Aktion aus, um Details wie Protokolle, Berichte und Ausgaben anzuzeigen, die durch die Aktion während des Laufs generiert wurden. Die angezeigten Informationen hängen davon ab, welcher Aktionstyp ausgewählt ist. Weitere Informationen zum Anzeigen von Build- oder Deploy-Logs finden Sie unter [Ergebnisse einer Build-Aktion anzeigen](build-view-results.md) oder[Bereitstellungsprotokolle anzeigen](deploy-deployment-logs.md).
+ **YAML**, um die Workflow-Definitionsdatei zu sehen, die für den Lauf verwendet wurde.
+ **Artefakte**, um die Artefakte zu sehen, die bei der Workflow-Ausführung erzeugt wurden. Weitere Informationen zu Artefakten finden Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).
+ **Berichte**, in denen die Testberichte und andere Arten von Berichten angezeigt werden, die während der Workflow-Ausführung erstellt wurden. Weitere Informationen zu Berichten finden Sie unter[Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).
+ **Variablen**, um die von der Workflow-Ausführung erzeugten Ausgabevariablen anzuzeigen. Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).
**Anmerkung**
Wenn der dem Lauf übergeordnete Workflow gelöscht wurde, wird oben auf der Seite mit den Ausführungsdetails eine entsprechende Meldung angezeigt.
## Status und Details aller Läufe in Ihrem Projekt anzeigen
Möglicherweise möchten Sie den Status und die Details aller Workflow-Ausführungen in Ihrem Projekt einsehen, herausfinden, wie viele Workflow-Aktivitäten in Ihrem Projekt vor sich gehen, und sich über den allgemeinen Zustand Ihrer Workflows informieren.
**Um den Status und die Details aller Läufe in Ihrem Projekt einzusehen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. **Wählen Sie unter **Workflows die Option Läufe** aus.**
Alle Läufe für alle Workflows, in allen Branches und in allen Repositorys in Ihrem Projekt werden angezeigt.
Die Seite enthält die folgenden Spalten:
+ **Lauf-ID** — Die eindeutige Kennung des Laufs. Wählen Sie den Link zur Lauf-ID, um detaillierte Informationen zum Lauf anzuzeigen.
+ **Status** — Der Verarbeitungsstatus des Workflow-Laufs. Weitere Informationen zu den Ausführungsstatus finden Sie unter[Status der Workflow-Ausführung](workflows-view-run-status.md).
+ **Auslöser** — Die Person, der Commit, die Pull-Anfrage (PR) oder der Zeitplan, die die Workflow-Ausführung gestartet haben. Weitere Informationen finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ **Workflow** — Der Name des Workflows, für den ein Lauf gestartet wurde, sowie das Quell-Repository und der Branch, in dem sich die Workflow-Definitionsdatei befindet. Möglicherweise müssen Sie die Spaltenbreite vergrößern, um diese Informationen zu sehen.
**Anmerkung**
Wenn diese Spalte auf **Nicht verfügbar** gesetzt ist, liegt das in der Regel daran, dass der zugehörige Workflow gelöscht oder verschoben wurde.
+ **Startzeit** — Die Uhrzeit, zu der die Workflow-Ausführung gestartet wurde.
+ **Dauer** — Wie lange die Verarbeitung des Workflow-Laufs gedauert hat. Sehr lange oder sehr kurze Zeiträume können auf Probleme hinweisen.
+ **Endzeit** — Der Zeitpunkt, zu dem der Workflow-Lauf beendet wurde.
## Status und Details aller Ausführungen eines bestimmten Workflows anzeigen
Möglicherweise möchten Sie den Status und die Details aller Läufe anzeigen, die mit einem bestimmten Workflow verknüpft sind, um festzustellen, ob Läufe zu Engpässen innerhalb des Workflows führen, oder um zu sehen, welche Läufe gerade ausgeführt werden oder abgeschlossen sind.
**Um den Status und die Details aller Ausführungen eines bestimmten Workflows anzuzeigen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie unter dem Namen des Workflows die Option **Läufe** aus.
Die mit dem ausgewählten Workflow verknüpften Läufe werden angezeigt.
Die Seite ist in zwei Abschnitte unterteilt:
+ **Aktive Läufe** — Zeigt Läufe an, die gerade ausgeführt werden. Diese Läufe befinden sich in einem der folgenden Zustände: **In Bearbeitung**.
+ **Ausführungsverlauf** — Zeigt die Läufe an, die abgeschlossen wurden (d. h. nicht in Bearbeitung sind).
Weitere Informationen zu den Ausführungsstatus finden Sie unter[Status der Workflow-Ausführung](workflows-view-run-status.md).
## Läufe eines Workflows im Workflow-Diagramm anzeigen
Sie können den Status aller Läufe eines Workflows anzeigen, während sie gemeinsam den Workflow durchlaufen. Die Läufe werden im Workflow-Diagramm (und nicht in einer Listenansicht) angezeigt. Auf diese Weise können Sie visuell darstellen, welche Läufe von welchen Aktionen verarbeitet werden und welche Läufe in einer Warteschlange warten.
**Um den Status mehrerer Läufe anzuzeigen, während sie gemeinsam einen Workflow durchlaufen**
**Anmerkung**
Dieses Verfahren gilt nur, wenn Ihr Workflow den Ausführungsmodus in der Warteschlange oder als ersetzt verwendet. Weitere Informationen finden Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md).
1. [Öffnen Sie die CodeCatalyst Konsole unter https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
**Anmerkung**
Stellen Sie sicher, dass Sie sich eine Workflow-Seite und keine Ausführungsseite ansehen.
1. Wählen Sie oben links die Registerkarte **Neuester Status** aus.
Ein Workflow-Diagramm wird angezeigt.
1. Überprüfen Sie das Workflow-Diagramm. Das Diagramm zeigt alle Läufe, die derzeit innerhalb des Workflows ausgeführt werden, sowie die letzten Läufe, die abgeschlossen wurden. Genauer gesagt:
+ Läufe, die ganz oben vor **Sources** angezeigt werden, befinden sich in der Warteschlange und warten darauf, gestartet zu werden.
+ Läufe, die zwischen Aktionen erscheinen, werden in die Warteschlange gestellt und warten darauf, von der nächsten Aktion verarbeitet zu werden.
+ Läufe, die innerhalb einer Aktion erscheinen, sind 1. sie werden gerade von der Aktion verarbeitet, 2. sind fertig verarbeitet oder 3. wurden nicht von der Aktion verarbeitet (normalerweise, weil eine vorherige Aktion fehlgeschlagen ist).