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. # 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**. ------