View a markdown version of this page

Definition von Workflow-YAML - Amazon CodeCatalyst
Beispiel für eine Workflow-DefinitionsdateiRichtlinien und Konventionen zur SyntaxTop-level Eigenschaften

Amazon CodeCatalyst ist nicht mehr offen für neue Kunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Wie migriert man von CodeCatalyst.

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.

Definition von Workflow-YAML

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 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 Sie die visuellen Editoren und die YAML-Editoren der CodeCatalyst Konsole.

Anmerkung

Die meisten der folgenden YAML-Eigenschaften haben entsprechende UI-Elemente im visuellen Editor. Verwenden Sie Strg+F, um ein UI-Element nachzuschlagen. Das Element wird mit der zugehörigen YAML-Eigenschaft aufgelistet.

Beispiel für eine Workflow-Definitionsdatei

Das Folgende ist ein Beispiel für eine einfache Workflow-Definitionsdatei. Sie enthält einige Eigenschaften der obersten Ebene, einen Triggers Abschnitt und einen Actions Abschnitt mit zwei Aktionen: Build undTest. Weitere Informationen finden Sie unter Über die Workflow-Definitionsdatei.

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 zur YAML-Syntax

Die Workflow-Definitionsdatei ist in YAML geschrieben und folgt der YAML 1.1-Spezifikation, sodass alles, was in dieser Spezifikation zulässig ist, auch in der Workflow-YAML zulässig ist. Wenn Sie YAML noch nicht kennen, finden Sie hier einige kurze Richtlinien, um sicherzustellen, dass Sie gültigen YAML-Code angeben.

  • Case-sensitivity: In der Workflow-Definitionsdatei wird zwischen Groß- und Kleinschreibung unterschieden. Stellen Sie daher sicher, dass Sie die in dieser Dokumentation angegebene Groß- und Kleinschreibung verwenden.

  • Sonderzeichen: Wir empfehlen, Eigenschaftswerte in Anführungszeichen oder doppelte Anführungszeichen zu setzen{, } die eines der folgenden Sonderzeichen enthalten:,*,#,?,|,-,, <, >,=,!, %@, und [ ] : ` ,

    Wenn Sie die Anführungszeichen nicht verwenden, werden die zuvor aufgeführten Sonderzeichen möglicherweise auf unerwartete Weise interpretiert.

  • Eigenschaftsnamen: Eigenschaftsnamen (im Gegensatz zu Eigenschaftswerten) sind auf alphanumerische Zeichen (a-z, 0-9) A-Z, Bindestriche (-) und Unterstriche (_) beschränkt. Leerzeichen sind nicht erlaubt. Sie können keine Anführungszeichen oder doppelte Anführungszeichen verwenden, um Sonderzeichen und Leerzeichen in Eigenschaftsnamen zu aktivieren.

    Nicht zulässig:

    'My#Build@action'

    My#Build@action

    My Build Action

    Erlaubt:

    My-Build-Action_1

  • Escape-Codes: Wenn Ihr Immobilienwert Escape-Codes (z. B. \n oder\t) enthält, folgen Sie diesen Richtlinien:

    • Verwenden Sie einfache Anführungszeichen, um den Escape-Code als Zeichenfolge zurückzugeben. Gibt beispielsweise 'my string \n my string' die Zeichenfolge zurückmy string \n my string.

    • Verwenden Sie doppelte Anführungszeichen, um den Escape-Code zu analysieren. Gibt beispielsweise Folgendes "my string \n my new line" zurück:

      my string
my new line

  • Kommentare: Stellen Sie Kommentare mit einem # Vorwort vor.

    Beispiel:

    Name: MyWorkflow
# This is a comment.
SchemaVersion: 1.0

  • Dreifacher Bindestrich (---): 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 Eigenschaften:Name,, SchemaVersion RunMode TriggersType, und. Branches

  • Ein Abschnitt ist jede 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

Top-level Eigenschaften

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 Workflow-Name und der Name der Workflow-Definitionsdatei können übereinstimmen, oder Sie können sie anders benennen. Workflow-Namen müssen nicht eindeutig sein. Workflow-Namen sind auf alphanumerische Zeichen (a-z, 0-9) A-Z, Bindestriche (-) und Unterstriche (_) beschränkt. Leerzeichen sind nicht erlaubt. Sie können keine Anführungszeichen verwenden, um Sonderzeichen und Leerzeichen in Workflow-Namen zu aktivieren.

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 das 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. Du kannst 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 (übernimmt) der spätere Lauf den vorherigen Lauf, und der frühere Lauf wird abgebrochen.

  • PARALLEL— Es finden mehrere Durchläufe gleichzeitig statt.

Wenn diese Eigenschaft weggelassen wird, lautet die StandardeinstellungQUEUED.

Weitere Informationen finden Sie unter Konfiguration des Warteschlangenverhaltens von Läufen.

Entsprechende Benutzeroberfläche: editor/Workflow properties/Advanced visuell/Run-Modus

Datenverarbeitung

(Optional)

Die Rechenengine, mit der Ihre Workflow-Aktionen ausgeführt werden. Sie können Compute entweder auf Workflow-Ebene oder auf Aktionsebene angeben, aber nicht auf beiden. Wenn die Compute-Konfiguration auf Workflow-Ebene angegeben wird, gilt sie 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.

Weitere Informationen zu Compute finden Sie unterKonfiguration von Compute- und Runtime-Images.

Entsprechende Benutzeroberfläche: keine 

Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:  
  Type: EC2 | Lambda
  Fleet: fleet-name
  SharedInstance: true | false

Typ

(Compute/Type)

(Erforderlich, Compute wenn gesetzt)

Der Typ der Rechenmaschine. Sie können einen der folgenden Werte verwenden:

  • EC2 (visueller Editor) oder EC2 (YAML-Editor)

    Optimiert für Flexibilität bei Aktionsausführungen.

  • Lambda (visueller Editor) oder Lambda (YAML-Editor)

    Optimierte Startgeschwindigkeiten für Aktionen.

Weitere Informationen zu Datentypen finden Sie unter Typen berechnen.

Entsprechende Benutzeroberfläche: editor/Workflow properties/Advanced visuell/Compute-Typ

Flotte

(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 beim Start 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. On-demand Eigenschaften der Flotte

Bei bereitgestellten Flotten konfigurieren Sie eine Reihe von dedizierten Maschinen, auf denen Ihre Workflow-Aktionen ausgeführt werden. Diese Maschinen bleiben im Leerlauf und sind bereit, Aktionen sofort zu verarbeiten. Weitere Informationen zu bereitgestellten Flotten finden Sie unter. Eigenschaften von bereitgestellten Flotten

Wenn Fleet es weggelassen wird, ist die Standardeinstellung. Linux.x86-64.Large

Weitere Hinweise zur Berechnung von Flotten finden Sie unterFlotten berechnen.

Entsprechende Benutzeroberfläche: visual editor/Workflow properties/Advanced/Compute fleet

SharedInstance

(Compute/SharedInstance)

(Optional)

Geben Sie die Funktion zur gemeinsamen Nutzung von Rechenleistung 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:

  • TRUEbedeutet, dass das Image der Laufzeitumgebung von Workflow-Aktionen gemeinsam genutzt wird.

  • FALSEbedeutet, dass für jede Aktion in einem Workflow ein separates Laufzeitumgebungsabbild 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 Rechenleistung finden Sie unterRechenleistung für mehrere Aktionen gemeinsam nutzen.

Entsprechende Benutzeroberfläche: keine

Auslöser

(Optional)

Eine Abfolge 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.

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

Typ

(Triggers/Type)

(Erforderlich, Triggers wenn gesetzt)

Geben Sie den Typ des Triggers 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 an Ihr Quell-Repository übertragen wird. Der Workflow-Lauf verwendet die Dateien in dem Branch, zu dem du den Push sendest (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 deinem Quell-Repository geöffnet, aktualisiert oder geschlossen wird. Der Workflow-Lauf verwendet die Dateien in dem Branch, aus dem du die Daten abrufst (das ist der Quell-Branch).

  • Zeitplan (visueller Editor) oder SCHEDULE (YAML-Editor)

    Ein Zeitplan-Trigger startet die Workflow-Ausführung nach einem Zeitplan, der durch einen von Ihnen angegebenen Cron-Ausdruck definiert ist. Für jeden Branch in deinem Quell-Repository wird ein separater Workflow-Lauf gestartet, der die Dateien des Branches verwendet. (Um die Branches einzuschränken, für die der Trigger aktiviert wird, verwenden Sie das Branches-Feld (visueller Editor) oder die Branches Eigenschaft (YAML-Editor).)

    Beachten Sie bei der Konfiguration eines Schedule-Triggers die folgenden Richtlinien:

    • Verwenden Sie nur einen Zeitplan-Trigger pro Workflow.

    • Wenn Sie in Ihrem CodeCatalyst Bereich mehrere Workflows definiert haben, empfehlen wir, dass Sie nicht mehr als 10 davon so planen, dass sie gleichzeitig starten.

    • Stellen Sie sicher, dass Sie den Cron-Ausdruck des Triggers so konfigurieren, dass zwischen den einzelnen Durchläufen ausreichend Zeit vergeht. Weitere Informationen finden Sie unter Expression.

Beispiele finden Sie unter Beispiele: Auslöser in Workflows.

Entsprechende Benutzeroberfläche: visuell editor/workflow diagram/Triggers /Triggertyp

Ereignisse

(Triggers/Events)

(Erforderlich, wenn der Trigger auf gesetzt Type istPULLREQUEST)

Geben Sie den Typ der Pull-Request-Ereignisse an, die eine Workflow-Ausführung starten. Die folgenden Werte sind gültig:

  • Der Pull-Request wird erstellt (visueller Editor) oder OPEN (YAML-Editor)

    Der Workflow-Lauf wird gestartet, wenn ein Pull Request erstellt wird.

  • Der Pull-Request ist geschlossen (visueller Editor) oder CLOSED (YAML-Editor)

    Der Workflow-Lauf wird gestartet, wenn ein Pull Request geschlossen wird. Das Verhalten des CLOSED Events 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.

  • Der Pull-Request (visueller Editor) oder REVISION (YAML-Editor) wurde neu überarbeitet

    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 eine neue Revision erstellt, wenn jemand einen neuen Commit an den im Pull Request angegebenen Quell-Branch sendet. Wenn du das REVISION Ereignis in deinen Pull-Request-Trigger einbeziehst, kannst du das OPEN Ereignis weglassen, da es sich um eine Obermenge von REVISION handelt. OPEN

Du kannst mehrere Ereignisse in demselben Pull-Request-Trigger angeben.

Beispiele finden Sie unter Beispiele: Auslöser in Workflows.

Entsprechende Benutzeroberfläche: visual editor/workflow diagram/Triggers//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 zum Beispiel, um alle Zweige main.* abzugleichen, die mit beginnen. main

Die anzugebenden Zweige sind je nach Triggertyp unterschiedlich:

  • Geben Sie für einen Push-Trigger die Zweige an, zu denen Sie den Push ausführen, d. h. die Ziel-Branches. Pro übereinstimmendem Branch wird ein Workflow-Lauf gestartet, wobei die Dateien im passenden Branch verwendet werden.

    Beispiele: main.*, mainline

  • Für einen Pull-Request-Trigger gibst du die Branches an, zu denen du pushen möchtest, also die Ziel-Branches. Pro übereinstimmendem Branch wird ein Workflow-Lauf gestartet, wobei die Workflow-Definitionsdatei und die Quelldateien im Quell-Branch (nicht der passende Branch) verwendet werden.

    Beispiele:main.*,mainline, v1\-.* (entspricht Zweigen, die mit beginnenv1-)

  • Geben Sie für einen Schedule-Trigger die Branches an, die die Dateien enthalten, die Ihr geplanter Lauf verwenden soll. Pro übereinstimmendem Branch wird ein Workflow-Lauf gestartet, wobei die Workflow-Definitionsdatei und die Quelldateien im passenden Branch verwendet werden.

    Beispiele: main.*, version\-1\.0

Anmerkung

Wenn Sie keine Zweige angeben, überwacht der Trigger alle Branches in Ihrem Quell-Repository und startet einen Workflow-Lauf mit der Workflow-Definitionsdatei und den Quelldateien in:

Weitere Informationen zu Branches und Triggern finden Sie unterRichtlinien zur Verwendung von Triggern und Branches.

Weitere Beispiele finden Sie unter Beispiele: Auslöser in Workflows.

Entsprechende Benutzeroberfläche: visual editor/workflow diagram/Triggers/Branches

FilesChanged

(Triggers/FilesChanged)

(Optional, wenn der Trigger aufPUSH, oder gesetzt Type istPULLREQUEST. Wird nicht unterstützt, wenn der Trigger auf gesetzt Type istSCHEDULE.)

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.

Entsprechende Benutzeroberfläche: visual editor/workflow diagram/Triggers/Dateien geändert

Expression

(Triggers/Expression)

(Erforderlich, wenn der Trigger auf gesetzt Type istSCHEDULE)

Geben Sie den Cron-Ausdruck an, der beschreibt, wann Ihre geplanten Workflow-Ausführungen stattfinden sollen.

Cron-Ausdrücke CodeCatalyst verwenden die folgende Syntax mit sechs Feldern, 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

?

*

MON-FRI

*

Führt jeden Montag bis Freitag um Mitternacht (UTC+0) einen Workflow aus.

0

2

*

*

?

*

Führt jeden Tag um 2:00 Uhr (UTC+0) einen Workflow aus.

15

22

*

*

?

*

Führt täglich um 22:15 Uhr (UTC+0) einen Workflow aus.

0/30

22-2

?

*

SAT-SUN

*

Führt von Samstag bis Sonntag alle 30 Minuten zwischen 22:00 Uhr am Starttag und 2:00 Uhr am Folgetag einen Workflow aus (UTC+0).

45

13

L

*

?

2023-2027

Führt einen Workflow um 13:45 Uhr (UTC+0) am letzten Tag des Monats zwischen den Jahren 2023 und einschließlich 2027 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 einen Abstand von mindestens 30 Minuten zwischen den Läufen. Eine schnellere Schrittfrequenz 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 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 im Amazon-Benutzerhandbuch. EventBridge Cron-Ausdrücke funktionieren genauso EventBridge und CodeCatalyst funktionieren genauso.

Beispiele für Zeitplan-Trigger finden Sie unterBeispiele: Auslöser in Workflows.

Entsprechende Benutzeroberfläche: visual editor/workflow diagram/Triggers/Schedule

Aktionen

Eine Abfolge von einer oder mehreren Aktionen für diesen Workflow. CodeCatalyst unterstützt mehrere Aktionstypen, wie z. B. Build- und Testaktionen, die verschiedene Arten von Funktionen bieten. Jeder Aktionstyp hat:

  • eine Identifier Eigenschaft, die die eindeutige, fest codierte ID der Aktion angibt. aws/build@v1Identifiziert 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 unterAktionstypen. Das Aktionstypen 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:
      ...

Aktions-oder-Gate-Name

(Actions/action-or-gate-name)

(Erforderlich)

Ersetzen Sie action-name 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 Hinweise zu Syntaxregeln finden Sie unter. Richtlinien zur YAML-Syntax

Weitere Informationen zu Benennungspraktiken für Aktionen, einschließlich Einschränkungen, finden Sie unterAktions-oder-Gate-Name.

Entsprechende Benutzeroberfläche: visueller Editor/ action-name /Registerkarte „Konfiguration“/Aktionsname oder Anzeigename der Aktion

Name der Aktionsgruppe

(Actions/action-group-name)

(Optional)

Eine Aktionsgruppe enthält eine oder mehrere Aktionen. Das Gruppieren von Aktionen in Aktionsgruppen hilft Ihnen, Ihren Arbeitsablauf zu organisieren, und ermöglicht es Ihnen auch, Abhängigkeiten zwischen verschiedenen Gruppen zu konfigurieren.

action-group-nameErsetzen Sie durch einen Namen, den Sie der Aktionsgruppe geben möchten. Aktionsgruppennamen müssen innerhalb des Workflows eindeutig sein und dürfen nur alphanumerische Zeichen, Bindestriche und Unterstriche enthalten. Weitere Hinweise zu Syntaxregeln finden Sie unter. Richtlinien zur YAML-Syntax

Weitere Hinweise zu Aktionsgruppen finden Sie unterGruppierung von Aktionen in Aktionsgruppen.

Entsprechende Benutzeroberfläche: keine