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. # YAML-Workflow-Definition Im Folgenden finden Sie die Referenzdokumentation für die Workflow-Definitionsdatei. Eine *Workflow-Definitionsdatei* ist eine YAML-Datei, die Ihren Workflow beschreibt. Standardmäßig wird die Datei in einem `~/.codecatalyst/workflows/` Ordner im Stammverzeichnis Ihres [Quell-Repositorys](source-repositories.md) gespeichert. Die Datei kann die Erweiterung „.yml“ oder „.yaml“ haben, und die Erweiterung muss in Kleinbuchstaben geschrieben werden. Um die Workflow-Definitionsdatei zu erstellen und zu bearbeiten, können Sie einen Editor wie vim verwenden, oder Sie können den visuellen Editor oder den YAML-Editor der CodeCatalyst Konsole verwenden. Weitere Informationen finden Sie unter [Verwenden der visuellen Editoren und der YAML-Editoren der CodeCatalyst Konsole](workflow.md#workflow.editors). **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. **Topics** + [Beispiel für eine Workflow-Definitionsdatei](#workflow.anatomy) + [Richtlinien und Konventionen zur Syntax](#workflow.terms.syntax.conv) + [Eigenschaften der obersten Ebene](#workflow.top.level) ## Beispiel für eine Workflow-Definitionsdatei Im Folgenden finden Sie ein Beispiel für eine einfache Workflow-Definitionsdatei. Sie umfasst einige Eigenschaften der obersten Ebene, einen `Triggers` Abschnitt und einen `Actions` Abschnitt mit zwei Aktionen: `Build` und`Test`. Weitere Informationen finden Sie unter [Informationen zur Workflow-Definitionsdatei](workflow.md#workflow.example). ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . Test: Identifier: aws/managed-test@v1 DependsOn: - Build Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test ``` ## Richtlinien und Konventionen zur Syntax In diesem Abschnitt werden die Syntaxregeln für die Workflow-Definitionsdatei sowie die in dieser Referenzdokumentation verwendeten Namenskonventionen beschrieben. ### Richtlinien für die YAML-Syntax Die Workflow-Definitionsdatei ist in YAML geschrieben und folgt der [YAML 1.1-Spezifikation, sodass alles, was in dieser Spezifikation](https://yaml.org/spec/) zulässig ist, auch in der Workflow-YAML zulässig ist. Wenn Sie mit YAML noch nicht vertraut sind, finden Sie hier einige kurze Richtlinien, um sicherzustellen, dass Sie gültigen YAML-Code angeben. + Berücksichtigung von Groß- und **Kleinschreibung**: In der Workflow-Definitionsdatei wird zwischen Groß- und Kleinschreibung unterschieden. Stellen Sie daher sicher, dass Sie die in dieser Dokumentation beschriebene Groß- und Kleinschreibung verwenden. + **Sonderzeichen**: Wir empfehlen die Verwendung von Anführungszeichen oder doppelten Anführungszeichen für Eigenschaftswerte, die eines der folgenden Sonderzeichen enthalten: `{` `}` `[``]`,,,`*`,`#`,`?`, < `|``-`, >,,,,,`=`, `!``%`, und `@` `:` ``` `,` Wenn Sie die Anführungszeichen nicht angeben, können die oben aufgeführten Sonderzeichen unerwartet interpretiert werden. + **Eigenschaftsnamen**: *Eigenschaftsnamen* (im Gegensatz zu *Eigenschaftswerten*) 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 oder doppelte Anführungszeichen verwenden, um Sonderzeichen und Leerzeichen in Eigenschaftsnamen zuzulassen. Nicht zulässig: `'My#Build@action'` `My#Build@action` `My Build Action` Zulässig: `My-Build-Action_1` + **Escape-Codes**: Wenn Ihr Immobilienwert Escape-Codes enthält (z. B. `\n` oder`\t`), befolgen Sie diese Richtlinien: + Verwenden Sie einfache Anführungszeichen, um den Escape-Code als Zeichenfolge zurückzugeben. Gibt beispielsweise `'my string \n my string'` die Zeichenfolge zurück`my string \n my string`. + Verwenden Sie doppelte Anführungszeichen, um den Escape-Code zu analysieren. Gibt zum `"my string \n my new line"` Beispiel zurück: ``` my string my new line ``` + **Kommentare: Kommentare** im Vorwort mit`#`. Beispiel: ``` Name: MyWorkflow # This is a comment. SchemaVersion: 1.0 ``` + **Dreifacher Gedankenstrich (`---`)**: Nicht `---` in Ihrem YAML-Code verwenden. CodeCatalyst ignoriert alles nach dem. `---` ### Namenskonventionen In diesem Handbuch beziehen wir uns mit den Begriffen *Eigenschaft* und *Abschnitt* auf die wichtigsten Elemente in einer Workflow-Definitionsdatei. + Eine *Eigenschaft* ist jedes Element, das einen Doppelpunkt (`:`) enthält. Im folgenden Codeausschnitt sind beispielsweise alle folgenden Eigenschaften:`Name`,,, `SchemaVersion` `RunMode` `Triggers``Type`, und. `Branches` + Ein *Abschnitt* ist eine Eigenschaft, die Untereigenschaften hat. Im folgenden Codeausschnitt gibt es einen Abschnitt. `Triggers` **Anmerkung** In diesem Handbuch werden „Abschnitte“ manchmal als „Eigenschaften“ bezeichnet und umgekehrt, je nach Kontext. ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main ``` ## Eigenschaften der obersten Ebene Im Folgenden finden Sie die Referenzdokumentation für die Eigenschaften der obersten Ebene in der Workflow-Definitionsdatei. ``` # Name Name: workflow-name # Schema version SchemaVersion: 1.0 # Run mode RunMode: QUEUED|SUPERSEDED|PARALLEL # Compute Compute: ... # Triggers Triggers: ... # Actions Actions: ... ``` ### Name (Erforderlich) Der Name des Workflows. Der Workflow-Name wird in der Workflow-Liste angezeigt und in Benachrichtigungen und Protokollen erwähnt. Der Workflowname und der Name der Workflow-Definitionsdatei können übereinstimmen, oder Sie können sie unterschiedlich benennen. Workflow-Namen müssen nicht eindeutig sein. Workflow-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 Workflow-Namen zuzulassen. **Entsprechende Benutzeroberfläche: visuelle editor/Workflow Eigenschaften/Workflow-Name** ### SchemaVersion (Erforderlich) Die Schemaversion der Workflow-Definition. Der einzige gültige Wert ist derzeit `1.0`. Entsprechende Benutzeroberfläche: *keine* ### RunMode (Optional) Wie CodeCatalyst geht man mit mehreren Durchläufen um? Sie können einen der folgenden Werte verwenden: + `QUEUED`— Mehrere Läufe werden in die Warteschlange gestellt und nacheinander ausgeführt. Sie können bis zu 50 Läufe in einer Warteschlange haben. + `SUPERSEDED`— Mehrere Läufe werden in die Warteschlange gestellt und nacheinander ausgeführt. Eine Warteschlange kann nur einen Lauf haben. Wenn also zwei Läufe zusammen in derselben Warteschlange landen, ersetzt der spätere Lauf den früheren Lauf (übernimmt ihn), und der frühere Lauf wird abgebrochen. + `PARALLEL`— Es finden mehrere Läufe gleichzeitig statt. Wenn diese Eigenschaft weggelassen wird, ist die Standardeinstellung`QUEUED`. Weitere Informationen finden Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md). **Entsprechende Benutzeroberfläche: visual editor/Workflow properties/Advanced/Run-Modus** ### Compute (Optional) Die Rechenengine, die zur Ausführung Ihrer Workflow-Aktionen verwendet wird. Sie können die Berechnung entweder auf Workflow-Ebene oder auf Aktionsebene angeben, aber nicht beide. Wenn auf Workflow-Ebene angegeben, gilt die Rechenkonfiguration für alle im Workflow definierten Aktionen. Auf Workflow-Ebene können Sie auch mehrere Aktionen auf derselben Instanz ausführen. Weitere Informationen finden Sie unter [Rechenleistung für mehrere Aktionen gemeinsam nutzen](compute-sharing.md). Weitere Informationen zu Compute finden Sie unter[Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md). Entsprechende Benutzeroberfläche: *keine* ``` Name: MyWorkflow SchemaVersion: 1.0 ... Compute: Type: EC2 | Lambda Fleet: fleet-name SharedInstance: true | false ``` #### Type (Compute/**Type**) (Erforderlich, `Compute` wenn gesetzt) Der Typ der Compute Engine. Sie können einen der folgenden Werte verwenden: + **EC2** (visueller Editor) oder `EC2` (YAML-Editor) Optimiert für Flexibilität bei Aktionsläufen. + **Lambda** (visueller Editor) oder `Lambda` (YAML-Editor) Optimierte Startgeschwindigkeiten für Aktionen. Weitere Informationen zu Datentypen finden Sie unter [Berechnungstypen](workflows-working-compute.md#compute.types). **Entsprechende Benutzeroberfläche: visuelle editor/Workflow Eigenschaften/Erweitert/Berechnungstyp** #### Fleet (Compute/**Fleet**) (Optional) Geben Sie die Maschine oder Flotte an, auf der Ihr Workflow oder Ihre Workflow-Aktionen ausgeführt werden sollen. Bei bedarfsgesteuerten Flotten stellt der Workflow zu Beginn einer Aktion die benötigten Ressourcen bereit, und die Maschinen werden zerstört, wenn die Aktion abgeschlossen ist. Beispiele für Flotten auf Abruf:`Linux.x86-64.Large`,. `Linux.x86-64.XLarge` Weitere Informationen zu Flotten auf Abruf finden Sie unter. [Eigenschaften von On-Demand-Flotten](workflows-working-compute.md#compute.on-demand) Bei bereitgestellten Flotten konfigurieren Sie eine Reihe von dedizierten Maschinen, um Ihre Workflow-Aktionen auszuführen. Diese Maschinen bleiben inaktiv und sind bereit, Aktionen sofort zu verarbeiten. Weitere Informationen zu bereitgestellten Flotten finden Sie unter. [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets) Wenn `Fleet` es weggelassen wird, ist die Standardeinstellung. `Linux.x86-64.Large` Weitere Informationen zu Rechenflotten finden Sie unter[Flotten berechnen](workflows-working-compute.md#compute.fleets). **Entsprechende Benutzeroberfläche: visual editor/Workflow properties/Advanced/ Compute fleet** #### SharedInstance (Compute/**SharedInstance**) (Optional) Geben Sie die Compute-Sharing-Funktion für Ihre Aktionen an. Bei Compute Sharing werden Aktionen in einem Workflow auf derselben Instanz ausgeführt (Image der Laufzeitumgebung). Sie können einen der folgenden Werte verwenden: + `TRUE`bedeutet, dass das Laufzeitumgebungs-Image von allen Workflow-Aktionen gemeinsam genutzt wird. + `FALSE`bedeutet, dass für jede Aktion in einem Workflow ein separates Laufzeitumgebungs-Image gestartet und verwendet wird, sodass Sie Ressourcen wie Artefakte und Variablen nicht ohne zusätzliche Konfiguration gemeinsam nutzen können. Weitere Informationen zur gemeinsamen Nutzung von Compute finden Sie unter[Rechenleistung für mehrere Aktionen gemeinsam nutzen](compute-sharing.md). Entsprechende Benutzeroberfläche: *keine* ### Triggers (Optional) Eine Sequenz von einem oder mehreren Triggern für diesen Workflow. Wenn kein Trigger angegeben ist, müssen Sie Ihren Workflow manuell starten. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md). **Entsprechende Benutzeroberfläche: visuelles editor/workflow Diagramm/Trigger** ``` Name: MyWorkflow SchemaVersion: 1.0 ... Triggers: - Type: PUSH Branches: - branch-name FilesChanged: - folder1/file - folder2/ - Type: PULLREQUEST Events: - OPEN - CLOSED - REVISION Branches: - branch-name FilesChanged: - file1.txt - Type: SCHEDULE # Run the workflow at 10:15 am (UTC+0) every Saturday Expression: "15 10 ? * 7 *" Branches: - branch-name ``` #### Type (Triggers/**Type**) (Erforderlich, wenn `Triggers` gesetzt) 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.triggers.expression). Beispiele finden Sie unter [Beispiele: Auslöser in Workflows](workflows-add-trigger-examples.md). **Entsprechende Benutzeroberfläche: visuelles editor/workflow Diagramm/Trigger/Triggertyp** #### Events (Triggers/**Events**) (Erforderlich, wenn der Trigger auf gesetzt ist) `Type` `PULLREQUEST` 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). **Entsprechende Benutzeroberfläche: visuelles editor/workflow Diagramm/Trigger/Ereignisse für Pull-Requests** #### Branches (Triggers/**Branches**) (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 zugeordneter Verzweigung 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 Zweige 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). Entsprechende Benutzeroberfläche: visualeditor/workflow diagram/Triggers//**Branches** #### FilesChanged (Triggers/**FilesChanged**) (Optional, wenn der Trigger auf`PUSH`, oder gesetzt `Type` ist`PULLREQUEST`. Wird nicht unterstützt, wenn der Trigger auf gesetzt `Type` ist`SCHEDULE`.) Geben Sie die Dateien oder Ordner in Ihrem Quell-Repository an, die der Trigger überwacht, um zu 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). **Entsprechende Benutzeroberfläche: visuelles editor/workflow Diagramm/Trigger/Dateien wurden geändert** #### Expression (Triggers/**Expression**) (Erforderlich, wenn der Trigger auf gesetzt ist) `Type` `SCHEDULE` 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** | Minuten | Stunden | Tage des Monats | Monat | Wochentage | Jahr | Bedeutung | | --- | --- | --- | --- | --- | --- | --- | | 0 | 0 | ? | \$1 | MO-FR | \$1 | Führt jeden Montag bis Freitag um Mitternacht (UTC\$10) einen Workflow aus. | | 0 | 2 | \$1 | \$1 | ? | \$1 | Führt jeden Tag um 2:00 Uhr (UTC\$10) einen Workflow aus. | | 15 | 22 | \$1 | \$1 | ? | \$1 | Führt jeden Tag um 22:15 Uhr (UTC\$10) einen Workflow aus. | | 0/30 | 22-2 | ? | \$1 | SAT-SUN | \$1 | Führt samstags bis sonntags alle 30 Minuten einen Workflow zwischen 22:00 Uhr am Starttag und 2:00 Uhr am Folgetag (UTC\$10) aus. | | 45 | 13 | L | \$1 | ? | 2023-2027 | Führt am letzten Tag des Monats zwischen 2023 und einschließlich 2027 um 13:45 Uhr (UTC\$10) einen Workflow aus. | 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). Entsprechende Benutzeroberfläche: visualeditor/workflow diagram/Triggers//**Schedule** ### Aktionen Eine Abfolge von einer oder mehreren Aktionen für diesen Workflow. CodeCatalyst unterstützt mehrere Aktionstypen, z. B. Build- und Testaktionen, die unterschiedliche Funktionen bieten. Jeder Aktionstyp hat: + eine `Identifier` Eigenschaft, die die eindeutige, hartcodierte ID der Aktion angibt. `aws/build@v1`Identifiziert beispielsweise die Build-Aktion. + ein `Configuration` Abschnitt, der Eigenschaften enthält, die für die Aktion spezifisch sind. Weitere Informationen zu den einzelnen Aktionstypen finden Sie unter[Aktionstypen](workflows-actions.md#workflows-actions-types). Das [Aktionstypen](workflows-actions.md#workflows-actions-types) Thema enthält Links zur Dokumentation der einzelnen Aktionen. Im Folgenden finden Sie die YAML-Referenz für Aktionen und Aktionsgruppen in der Workflow-Definitionsdatei. ``` Name: MyWorkflow SchemaVersion: 1.0 ... Actions: action-or-gate-name: Identifier: identifier Configuration: ... #Action groups action-group-name: Actions: ... ``` #### action-or-gate-name (Actions/*action-or-gate-name*) (Erforderlich) *action-name*Ersetzen Sie es durch einen Namen, den Sie der Aktion geben möchten. Aktionsnamen müssen innerhalb des Workflows eindeutig sein und dürfen nur alphanumerische Zeichen, Bindestriche und Unterstriche enthalten. Weitere Informationen zu Syntaxregeln finden Sie unter. [Richtlinien für die YAML-Syntax](#workflow.syntax.conv) Weitere Informationen zu Benennungspraktiken für Aktionen, einschließlich Einschränkungen, finden Sie unter[action-or-gate-name](#workflow.actions.name). **Entsprechende Benutzeroberfläche: Visual Editor/ *action-name* /Registerkarte Konfiguration/ Aktionsname oder **Aktionsanzeigename**** #### action-group-name (Actions/*action-group-name*) (Optional) Eine *Aktionsgruppe* enthält eine oder mehrere Aktionen. Das Gruppieren von Aktionen in Aktionsgruppen hilft Ihnen dabei, Ihren Arbeitsablauf zu organisieren, und ermöglicht es Ihnen auch, Abhängigkeiten zwischen verschiedenen Gruppen zu konfigurieren. *action-group-name*Ersetzen Sie es durch einen Namen, den Sie der Aktionsgruppe geben möchten. Namen von Aktionsgruppen müssen innerhalb des Workflows eindeutig sein und dürfen nur alphanumerische Zeichen, Bindestriche und Unterstriche enthalten. Weitere Informationen zu Syntaxregeln finden Sie unter. [Richtlinien für die YAML-Syntax](#workflow.syntax.conv) Weitere Informationen zu Aktionsgruppen finden Sie unter[Gruppierung von Aktionen in Aktionsgruppen](workflows-group-actions.md). Entsprechende Benutzeroberfläche: *keine*