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.

# Erstellen, Testen und Bereitstellen mit Workflows
<a name="workflow"></a>

Nachdem Sie Ihren Anwendungscode in einer [CodeCatalystEntwicklungsumgebung](devenvironment.md) geschrieben und in Ihr [CodeCatalyst Quell-Repository](source.md) übertragen haben, können Sie ihn bereitstellen. Dies erfolgt automatisch über einen Workflow.

Ein *Workflow* ist ein automatisiertes Verfahren, das beschreibt, wie Sie Ihren Code als Teil eines CI/CD-Systems (Continuous Integration and Continuous Delivery) erstellen, testen und bereitstellen. Ein Workflow definiert eine Reihe von Schritten oder *Aktionen*, die während einer Workflow-Ausführung ausgeführt werden sollen. Ein Workflow definiert auch die Ereignisse oder *Auslöser*, die den Start des Workflows auslösen. Um einen Workflow einzurichten, erstellen Sie mit dem [visuellen Editor oder dem YAML-Editor](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) der CodeCatalyst Konsole eine *Workflow-Definitionsdatei*.

**Tipp**  
Um einen schnellen Überblick darüber zu erhalten, wie Sie Workflows in einem Projekt verwenden könnten, [erstellen Sie ein Projekt mit einem Blueprint](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Jeder Blueprint stellt einen funktionierenden Workflow bereit, den Sie überprüfen, ausführen und mit dem Sie experimentieren können.

## Informationen zur Workflow-Definitionsdatei
<a name="workflow.example"></a>

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.

Im Folgenden finden Sie ein Beispiel für eine einfache Workflow-Definitionsdatei. Wir erklären jede Zeile dieses Beispiels in der folgenden Tabelle.

```
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 .
```


| Linien | Description | 
| --- | --- | 
|  <pre>Name: MyWorkflow</pre>  |  Gibt den Namen des Workflows an. Weitere Informationen zu der `Name` Eigenschaft finden Sie unter[Eigenschaften der obersten Ebene](workflow-reference.md#workflow.top.level).  | 
|  <pre>SchemaVersion: 1.0</pre>  |  Gibt die Version des Workflow-Schemas an. Weitere Informationen zu der `SchemaVersion` Eigenschaft finden Sie unter[Eigenschaften der obersten Ebene](workflow-reference.md#workflow.top.level).  | 
|  <pre>RunMode: QUEUED</pre>  |  Gibt an, wie CodeCatalyst mit mehreren Durchläufen umgegangen wird. Weitere Hinweise zum Ausführungsmodus finden Sie unter[Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md).  | 
|  <pre>Triggers:</pre>  |  Gibt die Logik an, nach der eine Workflow-Ausführung gestartet wird. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).   | 
|  <pre>- Type: PUSH<br />  Branches:<br />    - main</pre>  |  Gibt an, dass der Workflow immer dann gestartet werden muss, wenn Sie Code in den `main` Zweig des Standard-Quell-Repositorys übertragen. Weitere Informationen zur Workflow-Quelle finden Sie unter[Quell-Repositorys mit Workflows verbinden](workflows-sources.md).  | 
|  <pre>Actions:</pre>  |  Definiert die Aufgaben, die während einer Workflow-Ausführung ausgeführt werden müssen. In diesem Beispiel definiert der `Actions` Abschnitt eine einzelne Aktion namens`Build`. Weitere Informationen zu Aktionen finden Sie unter[Workflow-Aktionen konfigurieren](workflows-actions.md).  | 
|  <pre>Build:</pre>  |  Definiert die Eigenschaften für die `Build` Aktion. Weitere Hinweise zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).  | 
|  <pre>Identifier: aws/build@v1</pre>  |  Gibt den eindeutigen, hartcodierten Bezeichner für die Build-Aktion an.  | 
|  <pre>Inputs:<br />  Sources:<br />    - WorkflowSource</pre>  |  Gibt an, dass die Build-Aktion im `WorkflowSource` Quell-Repository nach den Dateien suchen soll, die sie zum Abschließen der Verarbeitung benötigt. Weitere Informationen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).  | 
|  <pre>Configuration:</pre>  |  Enthält die Konfigurationseigenschaften, die für die Build-Aktion spezifisch sind.  | 
|  <pre>Steps:<br />  - Run: docker build -t MyApp:latest .</pre>  |  Weist die Build-Aktion an, ein Docker-Image mit dem Namen zu erstellen `MyApp` und es mit `latest` zu kennzeichnen.  | 

Eine vollständige Liste aller in der Workflow-Definitionsdatei verfügbaren Eigenschaften finden Sie unter[YAML-Workflow-Definition](workflow-reference.md).

## Verwenden der visuellen Editoren und der YAML-Editoren der CodeCatalyst Konsole
<a name="workflow.editors"></a>

Um die Workflow-Definitionsdatei zu erstellen und zu bearbeiten, können Sie Ihren bevorzugten Editor verwenden. Wir empfehlen jedoch, den visuellen Editor oder den YAML-Editor der CodeCatalyst Konsole zu verwenden. Diese Editoren bieten eine hilfreiche Dateiüberprüfung, um sicherzustellen, dass YAML-Eigenschaftsnamen, Werte, Verschachtelungen, Abstände, Groß-/Kleinschreibung usw. korrekt sind.

Die folgende Abbildung zeigt einen Arbeitsablauf im Visual Editor. Der visuelle Editor bietet Ihnen eine vollständige Benutzeroberfläche, über die Sie Ihre Workflow-Definitionsdatei erstellen und konfigurieren können. Der visuelle Editor umfasst ein Workflow-Diagramm (1), das die Hauptkomponenten des Workflows zeigt, und einen Konfigurationsbereich (2).

![\[Visueller Workflow-Editor\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/workflow-visual-editor.png)


Alternativ können Sie den YAML-Editor verwenden, der im nächsten Bild gezeigt wird. Verwenden Sie den YAML-Editor, um große Codeblöcke einzufügen (z. B. aus einem Tutorial) oder um erweiterte Eigenschaften hinzuzufügen, die nicht im visuellen Editor angeboten werden.

![\[Der YAML-Editor für den Arbeitsablauf\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/workflow-yaml-editor.png)


Sie können vom visuellen Editor zum YAML-Editor wechseln, um zu sehen, welche Auswirkungen Ihre Konfigurationen auf den zugrunde liegenden YAML-Code haben.

## Workflows entdecken
<a name="workflow.discovering"></a>

Sie können Ihren Workflow zusammen mit anderen **Workflows**, die Sie im selben Projekt eingerichtet haben, auf der Workflow-Übersichtsseite einsehen.

Die folgende Abbildung zeigt die **Workflow-Übersichtsseite**. Sie enthält zwei Workflows: **BuildToProd**und **UnitTests**. Sie können sehen, dass beide einige Male ausgeführt wurden. Sie können **Letzte Läufe** auswählen, um schnell den Ausführungsverlauf anzuzeigen, oder den Namen des Workflows wählen, um den YAML-Code des Workflows und andere detaillierte Informationen anzuzeigen.

![\[Workflow-Protokolle\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/workflow-list.png)


## Details zur Workflow-Ausführung anzeigen
<a name="workflow.runs"></a>

Sie können die Details einer Workflow-Ausführung anzeigen, indem Sie die Ausführung auf der **Workflow-Übersichtsseite** auswählen.

Die folgende Abbildung zeigt die Details einer Workflow-Ausführung mit der Bezeichnung **run-CC11D**, die bei einem Commit to Source automatisch gestartet wurde. Das Workflow-Diagramm zeigt, dass eine Aktion fehlgeschlagen ist (1). Sie können zu den Protokollen (2) navigieren, um die detaillierten Protokollmeldungen einzusehen und Probleme zu beheben. Weitere Informationen zu Workflow-Ausführungen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).

![\[Workflow-Protokolle\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/workflow-visual-logs.png)


## Nächste Schritte
<a name="workflow.next"></a>

Weitere Informationen zu Workflow-Konzepten finden Sie unter[Workflow-Konzepte](workflows-concepts.md).

Informationen zum Erstellen Ihres ersten Workflows finden Sie unter[Erste Schritte mit Workflows](workflows-getting-started.md).

# Workflow-Konzepte
<a name="workflows-concepts"></a>

Im Folgenden finden Sie einige Konzepte und Begriffe, die Sie kennen sollten, wenn Sie Ihren Code mit Workflows erstellen, testen oder bereitstellen CodeCatalyst.

## Workflows
<a name="workflows-concepts-workflows"></a>

Ein *Workflow* ist ein automatisiertes Verfahren, das beschreibt, wie Sie Ihren Code als Teil eines CI/CD-Systems (Continuous Integration and Continuous Delivery) erstellen, testen und bereitstellen. Ein Workflow definiert eine Reihe von Schritten oder *Aktionen*, die während einer Workflow-Ausführung ausgeführt werden sollen. Ein Workflow definiert auch die Ereignisse oder *Auslöser*, die den Start des Workflows auslösen. Um einen Workflow einzurichten, erstellen Sie mit dem [visuellen Editor oder dem YAML-Editor](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) der CodeCatalyst Konsole eine *Workflow-Definitionsdatei*.

**Tipp**  
Um einen kurzen Überblick darüber zu erhalten, wie Sie Workflows in einem Projekt verwenden könnten, [erstellen Sie ein Projekt mit einem Blueprint](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Jeder Blueprint stellt einen funktionierenden Workflow bereit, den Sie überprüfen, ausführen und mit dem Sie experimentieren können.

## Workflow-Definitionsdateien
<a name="workflows-concepts-workflows-def"></a>

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.

Weitere Informationen zur Workflow-Definitionsdatei finden Sie unter. [YAML-Workflow-Definition](workflow-reference.md)

## Aktionen
<a name="workflows-concepts-actions"></a>

Eine *Aktion* ist der Hauptbaustein eines Workflows und definiert eine logische Arbeitseinheit oder Aufgabe, die während einer Workflow-Ausführung ausgeführt werden soll. In der Regel umfasst ein Workflow mehrere Aktionen, die nacheinander oder parallel ausgeführt werden, je nachdem, wie Sie sie konfiguriert haben.

Weitere Informationen zu Aktionen finden Sie unter[Workflow-Aktionen konfigurieren](workflows-actions.md).

## Aktionsgruppen
<a name="workflows-concepts-action-groups"></a>

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.

Weitere Informationen zu Aktionsgruppen finden Sie unter[Gruppierung von Aktionen in Aktionsgruppen](workflows-group-actions.md).

## -Artefakte
<a name="workflows-concepts-artifacts"></a>

Ein *Artefakt* ist das Ergebnis einer Workflow-Aktion und besteht in der Regel aus einem Ordner oder Archiv mit Dateien. Artefakte sind wichtig, weil sie es Ihnen ermöglichen, Dateien und Informationen zwischen Aktionen gemeinsam zu nutzen.

Weitere Informationen zu Artefakten finden Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

## Datenverarbeitung
<a name="workflows-concepts-compute"></a>

*Compute* bezieht sich auf die Computing-Engine (CPU, Arbeitsspeicher und Betriebssystem), die CodeCatalyst zur Ausführung von Workflow-Aktionen verwaltet und gewartet wird.

Weitere Informationen zu Compute finden Sie unter[Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).

## Umgebungen
<a name="workflows-concepts-environments"></a>

Eine CodeCatalyst *Umgebung*, nicht zu verwechseln mit einer [Entwicklungsumgebung](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html), definiert das Ziel AWS-Konto und die optionale Amazon-VPC, mit der ein CodeCatalyst [Workflow](workflow.md) eine Verbindung herstellt. Eine Umgebung definiert auch die [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Workflow benötigt, um auf die AWS Dienste und Ressourcen innerhalb des Zielkontos zuzugreifen.

Sie können mehrere Umgebungen einrichten und ihnen Namen wie „Entwicklung“, „Test“, „Staging“ und „Produktion“ geben. Wenn Sie die Bereitstellung in diesen Umgebungen durchführen, werden Informationen zu den Bereitstellungen auf den Registerkarten CodeCatalyst **Bereitstellungsaktivität** und **Bereitstellungsziele** in der Umgebung angezeigt.

Weitere Informationen zu Umgebungen finden Sie unter[Einsatz in AWS-Konten und VPCs](deploy-environments.md).

## Tore
<a name="workflows-concepts-gates"></a>

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 Gates finden Sie unter[Gating eines Workflow-Laufs](workflows-gates.md).

## Berichte
<a name="workflows-concepts-test-reports"></a>

Ein *Bericht* enthält Details zu Tests, die während einer Workflow-Ausführung durchgeführt werden. Sie können Berichte wie einen Testbericht, einen Bericht zur Codeabdeckung, einen Analysebericht zur Softwarezusammensetzung und einen statischen Analysebericht erstellen. Sie können einen Bericht verwenden, um ein Problem während eines Workflows zu beheben. Wenn Sie über viele Berichte aus mehreren Workflows verfügen, können Sie anhand Ihrer Berichte Trends und Fehlerraten anzeigen und so Ihre Anwendungen und Bereitstellungskonfigurationen optimieren.

Weitere Informationen zu Berichten finden Sie unter[Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).

## Ausführungen
<a name="workflows-concepts-runs"></a>

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.

Weitere Informationen zu Läufen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).

## Quellen
<a name="workflows-concepts-sources"></a>

Eine *Quelle*, auch *Eingabequelle* genannt, ist ein Quell-Repository, mit dem eine [Workflow-Aktion](workflows-actions.md) eine Verbindung herstellt, um die Dateien abzurufen, die sie zur Ausführung ihrer Operationen benötigt. Beispielsweise kann eine Workflow-Aktion eine Verbindung zu einem Quell-Repository herstellen, um Anwendungsquelldateien für die Erstellung einer Anwendung abzurufen.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

## Variablen
<a name="workflows-concepts-variables"></a>

 Eine *Variable* ist ein Schlüssel-Wert-Paar, das Informationen enthält, auf die Sie in Ihrem CodeCatalyst Amazon-Workflow verweisen können. Der Wertteil der Variablen wird bei der Ausführung des Workflows durch einen tatsächlichen Wert ersetzt.

Weitere Informationen zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

## Workflow-Auslöser
<a name="workflows-concepts-triggers"></a>

Mit einem *Workflow-Trigger* oder einfach einem *Trigger* können Sie eine Workflow-Ausführung automatisch 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.

Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).

# Erste Schritte mit Workflows
<a name="workflows-getting-started"></a>

In diesem Tutorial erfahren Sie, wie Sie Ihren ersten Workflow erstellen und konfigurieren.

**Tipp**  
Möchten Sie lieber mit einem vorkonfigurierten Workflow beginnen? Siehe[Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template), dort finden Sie Anweisungen zum Einrichten eines Projekts mit einem funktionierenden Workflow, eine Beispielanwendung und andere Ressourcen.

**Topics**
+ [

## Voraussetzungen
](#get-started-create-workflow-prerequisites)
+ [

## Schritt 1: Erstellen und konfigurieren Sie Ihren Workflow
](#get-started-create-workflow-create)
+ [

## Schritt 2: Speichern Sie Ihren Workflow mit einem Commit
](#get-started-create-workflow-commit)
+ [

## Schritt 3: Ausführungsergebnisse anzeigen
](#get-started-create-workflow-results)
+ [

## (Optional) Schritt 4: Bereinigen
](#get-started-create-workflow-cleanup)

## Voraussetzungen
<a name="get-started-create-workflow-prerequisites"></a>

Bevor Sie beginnen:
+ Sie benötigen ein CodeCatalyst **Leerzeichen**. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In Ihrem CodeCatalyst Bereich benötigen Sie ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-project
  ```

   Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).
+ In Ihrem Projekt benötigen Sie ein CodeCatalyst **Repository** mit dem Namen:

  ```
  codecatalyst-source-repository
  ```

  Weitere Informationen finden Sie unter [Erstellen eines Quell-Repositorys](source-repositories-create.md).

**Anmerkung**  
Wenn Sie bereits über ein Projekt und ein Quell-Repository verfügen, können Sie diese verwenden. Wenn Sie jedoch neue erstellen, wird das Aufräumen am Ende dieses Tutorials erleichtert.

## Schritt 1: Erstellen und konfigurieren Sie Ihren Workflow
<a name="get-started-create-workflow-create"></a>

In diesem Schritt erstellen und konfigurieren Sie einen Workflow, der Ihren Quellcode automatisch erstellt und testet, wenn Änderungen vorgenommen werden.

**Um Ihren Workflow zu erstellen**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

   Die Workflow-Definitionsdatei wird im YAML-Editor der CodeCatalyst Konsole angezeigt.

**Um Ihren Workflow zu konfigurieren**

Sie können Ihren Workflow im **Visual** Editor oder im **YAML-Editor** konfigurieren. Beginnen wir mit dem YAML-Editor und wechseln dann zum visuellen Editor.

1. Wählen Sie **\$1 Aktionen**, um eine Liste von Workflow-Aktionen anzuzeigen, die Sie Ihrem Workflow hinzufügen können.

1. Wählen Sie in der Aktion **Erstellen** **\$1** aus, um das YAML der Aktion zu Ihrer Workflow-Definitionsdatei hinzuzufügen. Ihr Workflow sieht jetzt wie folgt aus.

   ```
   Name: Workflow_fe47
   SchemaVersion: "1.0"
   
   # Optional - Set automatic triggers.
   Triggers:
     - Type: Push
       Branches:
         - main
   
   # Required - Define action configurations.
   Actions:
     Build_f0:
       Identifier: aws/build@v1
   
       Inputs:
         Sources:
           - WorkflowSource # This specifies that the action requires this workflow as a source
   
       Outputs:
         AutoDiscoverReports:
           Enabled: true
           # Use as prefix for the report files
           ReportNamePrefix: rpt
   
       Configuration:
         Steps:
           - Run: echo "Hello, World!"
           - Run: echo "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>" >> report.xml
           - Run: echo "<testsuite tests=\"1\" name=\"TestAgentJunit\" >" >> report.xml
           - Run: echo "<testcase classname=\"TestAgentJunit\" name=\"Dummy
               Test\"/></testsuite>" >> report.xml
   ```

   **Der Workflow kopiert die Dateien im `WorkflowSource` Quell-Repository auf den Computer, auf dem die `Build_f0` Aktion ausgeführt wird, druckt `Hello, World!` in die Protokolle, erkennt Testberichte auf dem Computercomputer und gibt sie auf der Berichtsseite der CodeCatalyst Konsole aus.**

1. Wählen Sie **Visual**, um die Workflow-Definitionsdatei im Visual Editor anzuzeigen. Mit den Feldern im visuellen Editor können Sie die im YAML-Editor angezeigten YAML-Eigenschaften konfigurieren.

## Schritt 2: Speichern Sie Ihren Workflow mit einem Commit
<a name="get-started-create-workflow-commit"></a>

In diesem Schritt speichern Sie Ihre Änderungen. Da Workflows als `.yaml` Dateien in Ihrem Repository gespeichert werden, speichern Sie Ihre Änderungen mit Commits.

**Um Ihre Workflow-Änderungen zu übernehmen**

1. (Optional) Wählen Sie **Validieren**, um sicherzustellen, dass der YAML-Code des Workflows gültig ist.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im Feld **Workflow-Dateiname** einen Namen für Ihre Workflow-Konfigurationsdatei ein, z. B. **my-first-workflow**

1. Geben Sie im Feld **Commit-Nachricht** eine Nachricht ein, um Ihren Commit zu identifizieren, z. **create my-first-workflow.yaml** B.

1. Wählen Sie unter **Repository** das Repository aus, in dem Sie den Workflow speichern möchten (`codecatalyst-repository`).

1. Wählen Sie unter **Branchname** den Branch aus, in dem Sie den Workflow speichern möchten (`main`).

1. Wählen Sie **Commit** (Übergeben).

Ihr neuer Workflow wird in der Liste der Workflows angezeigt. Es kann einen Moment dauern, bis es angezeigt wird.

Da Workflows mit Commits gespeichert werden und für den Workflow ein Code-Push-Trigger konfiguriert ist, wird beim Speichern des Workflows automatisch eine Workflow-Ausführung gestartet.

## Schritt 3: Ausführungsergebnisse anzeigen
<a name="get-started-create-workflow-results"></a>

In diesem Schritt navigieren Sie zu dem Lauf, der von Ihrem Commit aus gestartet wurde, und sehen sich die Ergebnisse an.

**Um die Ergebnisse des Laufs anzuzeigen**

1. Wählen Sie den Namen Ihres Workflows, zum Beispiel`Workflow_fe47`.

   Ein Workflow-Diagramm, das die Bezeichnung Ihres Quell-Repositorys (**WorkflowSource**) und die Build-Aktion (z. B. **build\$1F0**) zeigt.

1. **Wählen Sie im Workflow-Ausführungsdiagramm die Build-Aktion aus (z. B. build\$1F0).**

1. **Überprüfen Sie den Inhalt der **Registerkarten Protokolle**, **Berichte**, **Konfiguration** und Variablen.** Auf diesen Registerkarten werden die Ergebnisse Ihrer Build-Aktion angezeigt.

   Weitere Informationen finden Sie unter [Ergebnisse einer Build-Aktion anzeigen](build-view-results.md).

## (Optional) Schritt 4: Bereinigen
<a name="get-started-create-workflow-cleanup"></a>

In diesem Schritt bereinigen Sie die Ressourcen, die Sie in diesem Tutorial erstellt haben.

**Um Ressourcen zu löschen**
+ Wenn Sie für dieses Tutorial ein neues Projekt erstellt haben, löschen Sie es. Detaillierte Anweisungen finden Sie unter [Löschen eines Projekts](projects-delete.md). Durch das Löschen des Projekts werden auch das Quell-Repository und der Workflow gelöscht. 

# Bauen mit Workflows
<a name="build-workflow-actions"></a>

Mithilfe von [CodeCatalyst Workflows](workflow.md) können Sie Anwendungen und andere Ressourcen erstellen. 

**Topics**
+ [

## Wie erstelle ich eine Anwendung?
](#build-how-to)
+ [

## Vorteile der Build-Aktion
](#build-benefits)
+ [

## Alternativen zur Build-Aktion
](#build-alternatives)
+ [

# Hinzufügen der Build-Aktion
](build-add-action.md)
+ [

# Ergebnisse einer Build-Aktion anzeigen
](build-view-results.md)
+ [

# Tutorial: Artefakte auf Amazon S3 hochladen
](build-deploy.md)
+ [

# Aktionen erstellen und testen YAML
](build-action-ref.md)

## Wie erstelle ich eine Anwendung?
<a name="build-how-to"></a>

Um eine Anwendung oder Ressource darin zu erstellen CodeCatalyst, erstellen Sie zunächst einen Workflow und geben dann eine darin enthaltene Build-Aktion an.

Eine *Build-Aktion* ist ein Workflow-Baustein, der Ihren Quellcode kompiliert, Komponententests ausführt und Artefakte erzeugt, die sofort bereitgestellt werden können.

Sie fügen Ihrem Workflow mithilfe des Visual Editors oder YAML-Editors der CodeCatalyst Konsole eine Build-Aktion hinzu.

Die allgemeinen Schritte zum Erstellen einer Anwendung oder Ressource lauten wie folgt.

**Um eine Anwendung zu erstellen (Aufgaben auf hoher Ebene)**

1. In CodeCatalyst **fügen Sie Quellcode** für eine Anwendung hinzu, die Sie erstellen möchten. Weitere Informationen finden Sie unter [Speichern von Quellcode in Repositorys für ein Projekt in CodeCatalyst](source-repositories.md).

1.  CodeCatalystIn **erstellen Sie einen Workflow**. In diesem Workflow definieren Sie, wie Ihre Anwendung erstellt, getestet und bereitgestellt werden soll. Weitere Informationen finden Sie unter [Erste Schritte mit Workflows](workflows-getting-started.md).

1. (Optional) Im Workflow **fügen Sie einen Trigger** hinzu, der die Ereignisse angibt, die dazu führen, dass der Workflow automatisch gestartet wird. Weitere Informationen finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).

1. Im Workflow fügen Sie eine **Build-Aktion** hinzu, die den Quellcode Ihrer Anwendung oder Ressource kompiliert und verpackt. Optional können Sie mit der Build-Aktion auch Komponententests ausführen, Berichte generieren und Ihre Anwendung bereitstellen, wenn Sie für diese Zwecke keine Test- oder Bereitstellungsaktion verwenden möchten. Weitere Informationen zu den Test- und Bereitstellungsaktionen finden Sie unter[Hinzufügen der Build-Aktion](build-add-action.md).

1. (Optional) Im Workflow **fügen Sie eine Testaktion und eine **Bereitstellungsaktion**** hinzu, um Ihre Anwendung oder Ressource zu testen und bereitzustellen. Sie können aus mehreren vorkonfigurierten Aktionen wählen, um Ihre Anwendung für verschiedene Ziele bereitzustellen, z. B. Amazon ECS. Weitere Informationen finden Sie unter [Testen mit WorkflowsTesten mit Workflows](test-workflow-actions.md) und [Bereitstellung mit WorkflowsBereitstellung mit Workflows](deploy.md).

1. Sie **starten den Workflow** entweder manuell oder automatisch über einen Trigger. Der Workflow führt die Build-, Test- und Bereitstellungsaktionen nacheinander aus, um Ihre Anwendung und Ressourcen zu erstellen, zu testen und auf dem Ziel bereitzustellen. Weitere Informationen finden Sie unter [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).

## Vorteile der Build-Aktion
<a name="build-benefits"></a>

Die Verwendung der Build-Aktion innerhalb eines Workflows hat die folgenden Vorteile:
+ **Vollständig verwaltet** — Durch die Build-Aktion müssen Sie Ihre eigenen Build-Server nicht mehr einrichten, patchen, aktualisieren und verwalten. 
+ **Bei Bedarf** — Die Build-Aktion wird nach Bedarf skaliert, um Ihre Build-Anforderungen zu erfüllen. Sie zahlen nur für die Anzahl der Build-Minuten, die Sie wirklich nutzen. Weitere Informationen finden Sie unter [Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).
+ **Sofort einsatzbereit** — CodeCatalyst enthält vorkonfigurierte Docker-Images für die Laufzeitumgebung, die zur Ausführung all Ihrer Workflow-Aktionen, einschließlich Build-Aktionen, verwendet werden. Diese Images sind mit nützlichen Tools für die Erstellung von Anwendungen wie Node.js und The AWS CLI vorkonfiguriert. Sie können so konfigurieren CodeCatalyst , dass ein Build-Image verwendet wird, das Sie aus einer öffentlichen oder privaten Registrierung bereitstellen. Weitere Informationen finden Sie unter [Angabe von Images für die Laufzeitumgebung](build-images.md).

## Alternativen zur Build-Aktion
<a name="build-alternatives"></a>

Wenn Sie eine Build-Aktion zur Bereitstellung Ihrer Anwendung verwenden, sollten Sie stattdessen eine CodeCatalyst *Bereitstellungsaktion* verwenden. Bereitstellungsaktionen führen behind-the-scenes Konfigurationen durch, die Sie sonst manuell schreiben müssten, wenn Sie eine Build-Aktion verwenden würden. Weitere Informationen zu den verfügbaren Bereitstellungsaktionen finden Sie unter[Liste der Bereitstellungsaktionen](deploy.md#deploy-concepts-action-supported).

Sie können es auch verwenden AWS CodeBuild , um Ihre Anwendungen zu erstellen. Weitere Informationen finden Sie unter [Was ist CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html).

# Hinzufügen der Build-Aktion
<a name="build-add-action"></a>

Gehen Sie wie folgt vor, um Ihrem CodeCatalyst Workflow eine Build-Aktion hinzuzufügen. 

------
#### [ Visual ]

**Um eine Build-Aktion mit dem Visual Editor hinzuzufügen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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

1. Wählen Sie unter **Aktionen** die Option **Build** aus. 

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktionen erstellen und testen YAML](build-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 eine Build-Aktion mit dem YAML-Editor hinzuzufügen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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. Wählen Sie **Aktionen**.

1. Wählen Sie unter **Aktionen** die Option **Build** aus.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktionen erstellen und testen YAML](build-action-ref.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.

------

## Erstellen Sie eine Aktionsdefinition
<a name="build-add-action-definition"></a>

Die Build-Aktion ist als ein Satz von YAML-Eigenschaften in Ihrer Workflow-Definitionsdatei definiert. Informationen zu diesen Eigenschaften finden Sie [Aktionen erstellen und testen YAML](build-action-ref.md) in der[YAML-Workflow-Definition](workflow-reference.md).

# Ergebnisse einer Build-Aktion anzeigen
<a name="build-view-results"></a>

Verwenden Sie die folgenden Anweisungen, um die Ergebnisse einer Build-Aktion, einschließlich der generierten Protokolle, Berichte und Variablen, anzuzeigen.

**So zeigen Sie die Ergebnisse einer Build-Aktion an**

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 den Namen Ihrer Build-Aktion aus, zum Beispiel **Build**.

1. Um die Protokolle für den Build-Lauf anzuzeigen, wählen Sie **Logs** aus. Die Protokolle für die verschiedenen Build-Phasen werden angezeigt. Sie können die Protokolle nach Bedarf erweitern oder reduzieren.

1. Um die durch die Build-Aktion erstellten Testberichte anzuzeigen, wählen Sie **Berichte** aus, oder wählen Sie im Navigationsbereich **Berichte** aus. Weitere Informationen finden Sie unter [Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).

1. Um die für die Build-Aktion verwendete Konfiguration anzuzeigen, wählen Sie **Konfiguration** aus. Weitere Informationen finden Sie unter [Hinzufügen der Build-Aktion](build-add-action.md).

1. Um die von der Build-Aktion verwendeten Variablen anzuzeigen, wählen Sie **Variablen**. Weitere Informationen finden Sie unter [Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

# Tutorial: Artefakte auf Amazon S3 hochladen
<a name="build-deploy"></a>

In diesem Tutorial erfahren Sie, wie Sie mithilfe eines CodeCatalyst [Amazon-Workflows](workflows-concepts.md#workflows-concepts-workflows), der einige [Build-Aktionen](workflows-concepts.md#workflows-concepts-actions) umfasst, Artefakte in einen Amazon S3-Bucket hochladen. Diese Aktionen werden nacheinander ausgeführt, wenn der Workflow gestartet wird. Die erste Build-Aktion generiert zwei Dateien `Hello.txt` und`Goodbye.txt`, und bündelt sie zu einem Build-Artefakt. Die zweite Build-Aktion lädt das Artefakt auf Amazon S3 hoch. Sie konfigurieren den Workflow so, dass er jedes Mal ausgeführt wird, wenn Sie einen Commit in Ihr Quell-Repository übertragen.

**Topics**
+ [

## Voraussetzungen
](#build-deploy-tut-prereqs)
+ [

## Schritt 1: Eine AWS Rolle erstellen
](#build-deploy-tut-role)
+ [

## Schritt 2: Erstellen Sie einen Amazon S3 S3-Bucket
](#build-deploy-tut-artifact)
+ [

## Schritt 3: Erstellen Sie ein Quell-Repository
](#deploy-tut-lambda-cfn-source)
+ [

## Schritt 4: Erstellen Sie einen Workflow
](#build-deploy-tut-workflow.title)
+ [

## Schritt 5: Überprüfen Sie die Ergebnisse
](#build-deploy.s3.verify)
+ [

## Bereinigen
](#deploy-tut-lambda-cfn-clean-up)

## Voraussetzungen
<a name="build-deploy-tut-prereqs"></a>

Bevor Sie beginnen, muss Folgendes sichergestellt sein:
+ Sie benötigen einen CodeCatalyst **Bereich** mit einem verbundenen AWS Konto. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In Ihrem Bereich benötigen Sie ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-artifact-project
  ```

  Verwenden Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).
+ In Ihrem Projekt benötigen Sie eine CodeCatalyst **Umgebung** namens:

  ```
  codecatalyst-artifact-environment
  ```

  Konfigurieren Sie diese Umgebung wie folgt:
  + Wählen Sie einen beliebigen Typ, z. B. **Entwicklung**.
  + Connect dein AWS Konto damit.
  + Wählen Sie für die **Standard-IAM-Rolle eine** beliebige Rolle aus. Sie werden später eine andere Rolle angeben.

  Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).

## Schritt 1: Eine AWS Rolle erstellen
<a name="build-deploy-tut-role"></a>

In diesem Schritt erstellen Sie eine AWS IAM-Rolle, die Sie später der Build-Aktion in Ihrem Workflow zuweisen. Diese Rolle gewährt der CodeCatalyst Build-Aktion die Berechtigung, auf Ihr AWS Konto zuzugreifen und in Amazon S3 zu schreiben, wo Ihr Artefakt gespeichert wird. Die Rolle wird **Build-Rolle** genannt.

**Anmerkung**  
Wenn Sie bereits über eine Build-Rolle verfügen, die Sie für ein anderes Tutorial erstellt haben, können Sie sie auch für dieses Tutorial verwenden. Stellen Sie einfach sicher, dass sie über die im folgenden Verfahren beschriebenen Berechtigungen und Vertrauensrichtlinien verfügt.

Weitere Informationen zu IAM-Rollen finden Sie unter [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) im *AWS AWS Identity and Access Management Benutzerhandbuch*.

**Um eine Build-Rolle zu erstellen**

1. Erstellen Sie wie folgt eine Richtlinie für die Rolle:

   1. Melden Sie sich an bei AWS.

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Wählen Sie im Navigationsbereich **Richtlinien**.

   1. Wählen Sie **Richtlinie erstellen** aus.

   1. Wählen Sie den Tab **JSON**.

   1. Löschen Sie den vorhandenen Code.

   1. Fügen Sie folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "VisualEditor0",
                  "Effect": "Allow",
                  "Action": [
                      "s3:PutObject",
                      "s3:ListBucket"
                  ],
                  "Resource": "*"
              }
          ]
      }
      ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.

   1. Klicken Sie auf **Weiter: Prüfen**.

   1. Geben Sie im Feld **Name** Folgendes ein:

      ```
      codecatalyst-s3-build-policy
      ```

   1. Wählen Sie **Richtlinie erstellen** aus.

      Sie haben jetzt eine Berechtigungsrichtlinie erstellt.

1. Erstellen Sie die Build-Rolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.

   1. Wählen Sie **Benutzerdefinierte Vertrauensrichtlinie**.

   1. Löschen Sie die bestehende benutzerdefinierte Vertrauensrichtlinie.

   1. Fügen Sie die folgende benutzerdefinierte Vertrauensrichtlinie hinzu:

   1. Wählen Sie **Weiter** aus.

   1. Suchen Sie **unter Berechtigungsrichtlinien** nach dem entsprechenden Kontrollkästchen `codecatalyst-s3-build-policy` und aktivieren Sie es.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-s3-build-role
      ```

   1. Geben Sie **als Rollenbeschreibung** Folgendes ein:

      ```
      CodeCatalyst build role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

   Sie haben jetzt eine Build-Rolle mit einer Vertrauensrichtlinie und einer Berechtigungsrichtlinie erstellt.

## Schritt 2: Erstellen Sie einen Amazon S3 S3-Bucket
<a name="build-deploy-tut-artifact"></a>

In diesem Schritt erstellen Sie einen Amazon S3 S3-Bucket, in den die `Hello.txt` und `Goodbye.txt` -Artefakte hochgeladen werden.

**So erstellen Sie einen Amazon-S3-Bucket**

1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Wählen Sie im Hauptbereich **Create Bucket** aus.

1. Geben Sie als **Bucket-Namen** Folgendes ein:

   ```
   codecatalyst-artifact-bucket
   ```

1. Wählen Sie unter **AWS -Region** eine Region aus. In diesem Tutorial wird davon ausgegangen, dass Sie **US West (Oregon) us-west-2** ausgewählt haben. Informationen zu den von Amazon S3 unterstützten Regionen finden Sie unter [Amazon Simple Storage Service-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/s3.html) in der *Allgemeine AWS-Referenz*.

1. Wählen Sie unten auf der Seite **Bucket erstellen** aus.

1. Kopieren Sie den Namen des Buckets, den Sie gerade erstellt haben, zum Beispiel:

   ```
   codecatalyst-artifact-bucket
   ```

Sie haben jetzt einen Bucket mit dem Namen **codecatalyst-artifact-bucket** in der Region USA West (Oregon) us-west-2 erstellt.

## Schritt 3: Erstellen Sie ein Quell-Repository
<a name="deploy-tut-lambda-cfn-source"></a>

In diesem Schritt erstellen Sie ein Quell-Repository in CodeCatalyst. Dieses Repository wird verwendet, um die Workflow-Definitionsdatei des Tutorials zu speichern. 

Weitere Informationen zu Quell-Repositorys finden Sie unter[Erstellen eines Quell-Repositorys](source-repositories-create.md).

**Um ein Quell-Repository zu erstellen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Navigieren Sie zu Ihrem Projekt,`codecatalyst-artifact-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Source Repositories** aus. 

1. Wählen **Sie Repository hinzufügen** und anschließend **Repository erstellen** aus.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   codecatalyst-artifact-source-repository
   ```

1. Wählen Sie **Erstellen** aus.

Sie haben jetzt ein Repository mit dem Namen erstellt`codecatalyst-artifact-source-repository`.

## Schritt 4: Erstellen Sie einen Workflow
<a name="build-deploy-tut-workflow.title"></a>

In diesem Schritt erstellen Sie einen Workflow, der aus den folgenden Bausteinen besteht, die nacheinander ausgeführt werden:
+ Ein Trigger — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Triggern finden Sie unter[Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine Build-Aktion namens `GenerateFiles` — Beim Trigger erstellt die `GenerateFiles` Aktion zwei Dateien `Hello.txt` und `Goodbye.txt` packt sie in ein Ausgabeartefakt namens`codecatalystArtifact`.
+ Eine weitere Build-Aktion namens `Upload` — Nach Abschluss der `GenerateFiles` Aktion führt die `Upload` Aktion den AWS CLI Befehl aus, `aws s3 sync` um die Dateien im `codecatalystArtifact` und in Ihrem Quell-Repository in Ihren Amazon S3 S3-Bucket hochzuladen. Das AWS CLI ist auf der CodeCatalyst Rechenplattform vorinstalliert und vorkonfiguriert, sodass Sie es nicht installieren oder konfigurieren müssen.

  Weitere Informationen zur vorkonfigurierten Software auf der CodeCatalyst Rechenplattform finden Sie unter. [Angabe von Images für die Laufzeitumgebung](build-images.md) Weitere Informationen zum `aws s3 sync` Befehl AWS CLI's finden Sie unter [sync](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html) in der *AWS CLI Befehlsreferenz.*

Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).

**So erstellen Sie ein Workflow**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie den folgenden YAML-Code hinzu:
**Anmerkung**  
Im folgenden YAML-Code können Sie den `Connections:` Abschnitt weglassen, wenn Sie möchten. Wenn Sie diesen Abschnitt weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle angegebene Rolle** in Ihrer Umgebung die unter beschriebenen Berechtigungen und Vertrauensrichtlinien enthält. [Schritt 1: Eine AWS Rolle erstellen](#build-deploy-tut-role) Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)

   ```
   Name: codecatalyst-artifact-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: Push
       Branches:
         - main   
   Actions:
     GenerateFiles:
       Identifier: aws/build@v1
       Configuration: 
         Steps:
           # Create the output files.
           - Run: echo "Hello, World!" > "Hello.txt"
           - Run: echo "Goodbye!" > "Goodbye.txt"
       Outputs:
         Artifacts:
           - Name: codecatalystArtifact
             Files:
               - "**/*"
     Upload:
       Identifier: aws/build@v1
       DependsOn: 
         - GenerateFiles
       Environment:
         Name: codecatalyst-artifact-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-s3-build-role
       Inputs:
         Artifacts:
           - codecatalystArtifact
       Configuration: 
         Steps:
           # Upload the output artifact to the S3 bucket.
           - Run: aws s3 sync . s3://codecatalyst-artifact-bucket
   ```

   Ersetzen Sie im obigen Code:
   + *codecatalyst-artifact-environment*durch den Namen der Umgebung, in der Sie erstellt haben[Voraussetzungen](#build-deploy-tut-prereqs).
   + *codecatalyst-account-connection*mit dem Namen der Kontoverbindung, in der Sie eine Verbindung erstellt haben[Voraussetzungen](#build-deploy-tut-prereqs).
   + *codecatalyst-s3-build-role*mit dem Namen der Build-Rolle, in der Sie erstellt haben[Schritt 1: Eine AWS Rolle erstellen](#build-deploy-tut-role).
   + *codecatalyst-artifact-bucket*mit dem Namen des Amazon S3, in dem Sie es erstellt haben[Schritt 2: Erstellen Sie einen Amazon S3 S3-Bucket](#build-deploy-tut-artifact).

   Informationen zu den Eigenschaften in dieser Datei finden Sie unter[Aktionen erstellen und testen YAML](build-action-ref.md).

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im **Dialogfeld „Workflow bestätigen**“ Folgendes ein:

   1. Behalten Sie für **Workflow-Dateiname** die Standardeinstellung bei`codecatalyst-artifact-workflow`.

   1. Geben Sie für **Commit-Nachricht** Folgendes ein:

      ```
      add initial workflow file
      ```

   1. Wählen Sie für **Repository **codecatalyst-artifact-source-repository****.

   1. Wählen Sie als **Branch-Name** **main** aus.

   1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt einen Workflow erstellt. Eine Workflow-Ausführung wird aufgrund des oben im Workflow definierten Triggers automatisch gestartet. Insbesondere, als Sie die `codecatalyst-artifact-workflow.yaml` Datei in Ihr Quell-Repository übernommen (und per Push übertragen) haben, hat der Trigger die Workflow-Ausführung gestartet.

**Um den laufenden Workflow-Lauf zu sehen**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Workflow aus, den Sie gerade erstellt haben:. `codecatalyst-artifact-workflow`

1. Wählen Sie **GenerateFiles**, ob Sie den Fortschritt der ersten Build-Aktion sehen möchten.

1. Wählen Sie **Hochladen**, um den Fortschritt der zweiten Build-Aktion zu sehen.

1. Wenn die **Upload-Aktion** abgeschlossen ist, gehen Sie wie folgt vor:
   + Wenn die Workflow-Ausführung erfolgreich war, fahren Sie mit dem nächsten Verfahren fort.
   + Wenn die Workflow-Ausführung fehlgeschlagen ist, wählen Sie **Protokolle** aus, um das Problem zu beheben.

## Schritt 5: Überprüfen Sie die Ergebnisse
<a name="build-deploy.s3.verify"></a>

Gehen Sie nach der Ausführung des Workflows zum Amazon S3 S3-Service und schauen Sie in Ihrem *codecatalyst-artifact-bucket* Bucket nach. Es sollte jetzt die folgenden Dateien und Ordner enthalten:

```
.
|— .aws/
|— .git/
|Goodbye.txt
|Hello.txt
|REAME.md
```

Die `Hello.txt` Dateien `Goodbye.txt` und wurden hochgeladen, weil sie Teil des `codecatalystArtifact` Artefakts waren. Die `README.md` Dateien `.aws/``.git/`, und wurden hochgeladen, weil sie sich in Ihrem Quell-Repository befanden.

## Bereinigen
<a name="deploy-tut-lambda-cfn-clean-up"></a>

Räumen Sie auf CodeCatalyst und vermeiden Sie AWS , dass Ihnen diese Dienste in Rechnung gestellt werden.

**Zum Aufräumen in CodeCatalyst**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Löschen Sie das `codecatalyst-artifact-source-repository` Quell-Repository.

1. Löschen Sie den `codecatalyst-artifact-workflow` Workflow.

**Zum Aufräumen in AWS**

1. Bereinigen Sie in Amazon S3 wie folgt:

   1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

   1. Löschen Sie die Dateien im `codecatalyst-artifact-bucket` Bucket.

   1. Löschen Sie den `codecatalyst-artifact-bucket` Bucket.

1. Bereinigen Sie in IAM wie folgt:

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Löschen Sie das `codecatalyst-s3-build-policy`.

   1. Löschen Sie das `codecatalyst-s3-build-role`.

# Aktionen erstellen und testen YAML
<a name="build-action-ref"></a><a name="test-action-ref"></a>

Im Folgenden finden Sie die YAML-Definition der Build- und Testaktionen. Es gibt eine Referenz für zwei Aktionen, da sich ihre YAML-Eigenschaften sehr ähnlich sind.

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).

Wählen Sie im folgenden Code eine YAML-Eigenschaft aus, um eine Beschreibung zu erhalten.

**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 action definition starts here.
  action-name:
    Identifier: aws/build@v1 | aws/managed-test@v1
    DependsOn:
      - dependent-action-name-1
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Caching:  
      FileCaching:
        key-name-1:
          Path: file1.txt
          RestoreKeys:
            - restore-key-1
    Inputs:
      Sources:
        - source-name-1
        - source-name-2
      Artifacts:
        - artifact-name
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2   
    Outputs:
      Artifacts:
        - Name: output-artifact-1
          Files: 
            - build-output/artifact-1.jar
            - "build-output/build*"
        - Name: output-artifact-2
          Files:
            - build-output/artifact-2.1.jar
            - build-output/artifact-2.2.jar
      Variables:
        - variable-name-1
        - variable-name-2
      AutoDiscoverReports:
        Enabled: true | false
        ReportNamePrefix: AutoDiscovered
        IncludePaths:
          - "**/*"
        ExcludePaths:
          - node_modules/cdk/junit.xml
        SuccessCriteria:
          PassRate: percent
          LineCoverage: percent
          BranchCoverage: percent
          Vulnerabilities:
            Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
            Number: whole-number
          StaticAnalysisBug:
            Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
            Number: whole-number
          StaticAnalysisSecurity:
            Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
            Number: whole-number
          StaticAnalysisQuality:
            Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
            Number: whole-number
          StaticAnalysisFinding:
            Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
            Number: whole-number
      Reports:
        report-name-1:
          Format: format
          IncludePaths:
            - "*.xml"
          ExcludePaths:
            - report2.xml
            - report3.xml
          SuccessCriteria:
            PassRate: percent
            LineCoverage: percent
            BranchCoverage: percent
            Vulnerabilities:
              Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
              Number: whole-number
            StaticAnalysisBug:
                Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
                Number: whole-number
            StaticAnalysisSecurity:
                Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
                Number: whole-number
            StaticAnalysisQuality:
                Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
                Number: whole-number
            StaticAnalysisFinding:
                Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
                Number: whole-number
    Configuration:
      Container:
        Registry: registry
        Image: image
      Steps:
        - Run: "step 1"
        - Run: "step 2"
      Packages:
        NpmConfiguration:
          PackageRegistries:
            - PackagesRepository: package-repository
              Scopes:
                - "@scope"
        ExportAuthorizationToken: true | false
```

## Aktionsname
<a name="build.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aktionsname“**

## Identifier
<a name="build.identifier"></a>

(*action-name*/**Identifier**)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Wird `aws/build@v1` für Build-Aktionen verwendet.

`aws/managed-test@v1`Für Testaktionen verwenden.

Entsprechende Benutzeroberfläche: Workflow-Diagramm/Aktionsname/Bezeichnung *aws/build@v1\$1aws/managed-test@v1*

## DependsOn
<a name="build.depends-on"></a>

(*action-name*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="build.computename"></a>

(*action-name*/**Compute**)

(Optional)

Die Rechen-Engine, die zur Ausführung Ihrer Workflow-Aktionen verwendet wurde. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="build.computetype"></a>

(*action-name*/Compute/**Typ**)

([Compute](#build.computename)Erforderlich, falls enthalten)

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: Registerkarte „**Konfiguration/Berechnungstyp**“

## Fleet
<a name="build.computefleet"></a>

(*action-name*/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 im Leerlauf 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`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„Flotte **berechnen**“

## Timeout
<a name="build.timeout"></a>

(*action-name*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Environment
<a name="build.environment"></a>

(*action-name*/**Environment**)

(Optional)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="build.environment.name"></a>

(*action-name*/Environment/**Name**)

(Optional)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="build.environment.connections"></a>

(*action-name*/Environment/**Connections**)

(Optional)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Ist tab/Environment/What die Konfiguration aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Name
<a name="build.environment.connections.name"></a>

(*action-name*/Environment/Connections/**Name**)

(Erforderlich, falls enthalten[Connections](#build.environment.connections))

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Ist tab/Environment/What die Konfiguration aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Role
<a name="build.environment.connections.role"></a>

(*action-name*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#build.environment.connections))

Geben Sie den Namen der IAM-Rolle an, die diese Aktion verwendet, um auf AWS Dienste wie Amazon S3 und Amazon ECR zuzugreifen und diese zu nutzen. Stellen Sie sicher, dass diese Rolle zu Ihrer AWS-Konto Verbindung in Ihrem Bereich hinzugefügt wird. Informationen zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter[Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der Konsole aufgeführt ist. CodeCatalyst Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

**Warnung**  
Beschränken Sie die Berechtigungen auf diejenigen, die für die Build- und Testaktionen erforderlich sind. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

Entsprechende Benutzeroberfläche: tab/Environment/What Die Konfiguration ist aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Caching
<a name="build.caching"></a>

(*action-name*/**Caching**)

(Optional)

Ein Abschnitt, in dem Sie einen Cache angeben können, um Dateien auf der Festplatte zu speichern und sie bei nachfolgenden Workflow-Ausführungen aus diesem Cache wiederherzustellen.

Weitere Informationen zum Zwischenspeichern von Dateien finden Sie unter. [Zwischenspeichern von Dateien zwischen Workflow-Läufen](workflows-caching.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Datei-Caching** — optional

## FileCaching
<a name="build.caching.filecaching"></a>

(*action-name*/Caching/**FileCaching**)

(Optional)

Ein Abschnitt, der die Konfiguration für eine Sequenz von Caches spezifiziert.

**Entsprechende Benutzeroberfläche: tab/File Konfigurations-Caching — optional/ Cache hinzufügen**

## Schlüsselname-1
<a name="build.caching.filecaching.key-name-1"></a>

(*action-name*/Caching/FileCaching/***key-name-1***)

(Optional)

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`.

**Entsprechende Benutzeroberfläche: tab/File Konfigurations-Caching — optional/Cache hinzufügen/Schlüssel**

## Path
<a name="build.caching.filecaching.key-name-1.path"></a>

(*action-name*/Caching/FileCaching/*key-name-1*/**Path**)

(Optional)

Geben Sie den zugehörigen Pfad für Ihren Cache an. 

**Entsprechende Benutzeroberfläche: tab/File Konfigurations-Caching — optional/Cache hinzufügen/Pfad**

## RestoreKeys
<a name="build.caching.filecaching.key-name-1.restorekeys"></a>

(*action-name*/Caching/FileCaching/*key-name-1*/**RestoreKeys**)

(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`.

**Entsprechende Benutzeroberfläche: tab/File Konfigurations-Caching — optional/Cache hinzufügen/Schlüssel wiederherstellen — optional**

## Inputs
<a name="build.inputs"></a>

(*action-name*/**Inputs**)

(Optional)

Der `Inputs` Abschnitt definiert die Daten, die eine Aktion während einer Workflow-Ausführung benötigt.

**Anmerkung**  
Pro Build-Aktion oder Testaktion sind maximal vier Eingaben (eine Quelle und drei Artefakte) zulässig. Variablen werden auf diese Summe nicht angerechnet.

Wenn Sie auf Dateien verweisen müssen, die sich in unterschiedlichen Eingaben befinden (z. B. eine Quelle und ein Artefakt), ist die Quelleingabe die primäre Eingabe und das Artefakt die sekundäre Eingabe. Verweise auf Dateien in sekundären Eingaben benötigen ein spezielles Präfix, um sie von der primären Eingabe zu unterscheiden. Details hierzu finden Sie unter [Beispiel: Referenzieren von Dateien in mehreren Artefakten](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“**

## Sources
<a name="build.inputs.sources"></a>

(*action-name*/Inputs/**Sources**)

(Optional)

Geben Sie die Labels an, die die Quell-Repositorys repräsentieren, die für die Aktion benötigt werden. Derzeit wird nur die Bezeichnung, die das Quell-Repository darstellt`WorkflowSource`, in dem Ihre Workflow-Definitionsdatei gespeichert ist, unterstützt.

Wenn Sie eine Quelle weglassen, müssen Sie mindestens ein Eingabeartefakt unter angeben. `action-name/Inputs/Artifacts`

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

*Entsprechende Benutzeroberfläche: keine*

## Artifacts - input
<a name="build.inputs.artifacts"></a>

(*action-name*/Inputs/**Artifacts**)

(Optional)

Geben Sie Artefakte aus früheren Aktionen an, die Sie als Eingabe für diese Aktion bereitstellen möchten. Diese Artefakte müssen bereits in früheren Aktionen als Ausgabeartefakte definiert sein.

Wenn Sie keine Eingabeartefakte angeben, müssen Sie mindestens ein Quell-Repository unter angeben`action-name/Inputs/Sources`.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Anmerkung**  
Wenn die Dropdownliste **Artefakte — optional** nicht verfügbar ist (visueller Editor) oder wenn Sie bei der Validierung Ihres YAML (YAML-Editors) Fehler erhalten, kann das daran liegen, dass die Aktion nur eine Eingabe unterstützt. Versuchen Sie in diesem Fall, die Quelleingabe zu entfernen.

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Artefakte“ — optional**

## Variables - input
<a name="build.inputs.variables"></a>

(*action-name*/Inputs/**Variables**)

(Optional)

Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Variablen“ — optional**

## Outputs
<a name="build.outputs"></a>

(*action-name*/**Outputs**)

(Optional)

Definiert die Daten, die von der Aktion während einer Workflow-Ausführung ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts - output
<a name="build.outputs.artifacts"></a>

(*action-name*/Outputs/**Artifacts**)

(Optional)

Geben Sie den Namen eines Artefakts an, das durch die Aktion generiert wurde. Artefaktnamen müssen innerhalb eines Workflows eindeutig sein und sind auf alphanumerische Zeichen (a-z, A-Z, 0-9) und Unterstriche (\$1) beschränkt. Leerzeichen, Bindestriche (-) und andere Sonderzeichen sind nicht zulässig. Sie können keine Anführungszeichen verwenden, um Leerzeichen, Bindestriche und andere Sonderzeichen in Namen von Ausgabeartefakten zuzulassen.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte**

## Name
<a name="build.outputs.artifacts.name"></a>

(*action-name*/Outputs/Artifacts/**Name**)

(Erforderlich, wenn [Artifacts - output](#build.outputs.artifacts) es enthalten ist)

Geben Sie den Namen eines Artefakts an, das durch die Aktion generiert wurde. Artefaktnamen müssen innerhalb eines Workflows eindeutig sein und sind auf alphanumerische Zeichen (a-z, A-Z, 0-9) und Unterstriche (\$1) beschränkt. Leerzeichen, Bindestriche (-) und andere Sonderzeichen sind nicht zulässig. Sie können keine Anführungszeichen verwenden, um Leerzeichen, Bindestriche und andere Sonderzeichen in Namen von Ausgabeartefakten zuzulassen.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Gibt die tab/Artifacts/New Ausgabe/den Namen des **Build-Artefakts** aus

## Files
<a name="build.outputs.artifacts.files"></a>

(*action-name*/Outputs/Artifacts/**Files**)

(Erforderlich, wenn es enthalten [Artifacts - output](#build.outputs.artifacts) ist)

Geben Sie die Dateien an, die in dem Artefakt CodeCatalyst enthalten sind, das von der Aktion ausgegeben wird. Diese Dateien werden durch die Workflow-Aktion generiert, wenn sie ausgeführt wird, und sind auch in Ihrem Quell-Repository verfügbar. Dateipfade können sich in einem Quell-Repository oder einem Artefakt aus einer früheren Aktion befinden und sind relativ zum Quell-Repository oder Artefakt-Stamm. Sie können Glob-Muster verwenden, um Pfade anzugeben. Beispiele:
+ Um eine einzelne Datei anzugeben, die sich im Stammverzeichnis Ihres Build-Speicherorts oder Quell-Repository-Speicherorts befindet, verwenden Sie`my-file.jar`.
+ Um eine einzelne Datei in einem Unterverzeichnis anzugeben, verwenden Sie `directory/my-file.jar` oder`directory/subdirectory/my-file.jar`.
+ Um alle Dateien anzugeben, verwenden Sie`"**/*"`. Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
+ Um alle Dateien und Verzeichnisse in einem Verzeichnis mit dem Namen anzugeben`directory`, verwenden Sie. `"directory/**/*"` Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
+ Um alle Dateien in einem Verzeichnis mit dem Namen`directory`, aber nicht in einem seiner Unterverzeichnisse anzugeben, verwenden Sie. `"directory/*"` 

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder ein anderes Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Anmerkung**  
Möglicherweise müssen Sie dem Dateipfad ein Präfix hinzufügen, um anzugeben, in welchem Artefakt oder in welcher Quelle das Objekt gefunden werden soll. Weitere Informationen erhalten Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

Entsprechende Benutzeroberfläche: Gibt die tab/Artifacts/New Ausgabe/die von Build **erstellten Dateien aus**

## Variables - output
<a name="build.outputs.variables"></a>

(*action-name*/Outputs/**Variables**)

(Optional)

Geben Sie die Variablen an, die die Aktion exportieren soll, damit sie für nachfolgende Aktionen verfügbar sind.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Variablen/Variable hinzufügen**

## Variablenname-1
<a name="build.outputs.variables.name"></a>

(*action-name*/Outputs/Variables/*variable-name-1*)

(Optional)

Geben Sie den Namen einer Variablen an, die von der Aktion exportiert werden soll. Diese Variable muss bereits im `Steps` Abschnitt `Inputs` oder derselben Aktion definiert sein.

Weitere Hinweise zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Entsprechende Benutzeroberfläche: Gibt tab/Variables/Add Variable/ Namen aus**

## AutoDiscoverReports
<a name="build.outputs.autodiscover"></a>

(*action-name*/Outputs/**AutoDiscoverReports**)

(Optional)

Definiert die Konfiguration für die Auto-Discovery-Funktion.

Wenn Sie die automatische Erkennung aktivieren, werden alle `Inputs` an die Aktion übergebenen sowie alle von der Aktion selbst generierten Dateien CodeCatalyst durchsucht, wobei nach Test-, Codeabdeckungs- und SCA-Berichten (Software Composition Analysis) gesucht wird. Wandelt jeden gefundenen Bericht in einen CodeCatalyst Bericht um. CodeCatalyst Ein *CodeCatalyst Bericht* ist ein Bericht, der vollständig in den CodeCatalyst Service integriert ist und über die Konsole angezeigt und bearbeitet werden kann. CodeCatalyst 

**Anmerkung**  
Standardmäßig überprüft die automatische Erkennungsfunktion alle Dateien. Mithilfe der Eigenschaften [IncludePaths](#build.reports.includepaths) oder [ExcludePaths](#build.reports.excludepaths) können Sie einschränken, welche Dateien überprüft werden. 

**Entsprechende Benutzeroberfläche: Registerkarte „Ausgaben/Berichte“/„Automatische Erkennung von Berichten“**

## Enabled
<a name="build.outputs.autodiscover.enabled"></a>

(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)

(Optional)

Aktivieren oder deaktivieren Sie die automatische Erkennungsfunktion.

Gültige Werte sind `true` oder `false`.

Wenn `Enabled` es weggelassen wird, ist `true` die Standardeinstellung.

**Entsprechende Benutzeroberfläche: Registerkarte „Ausgaben/Berichte“/„Automatische Erkennung von Berichten“**

## ReportNamePrefix
<a name="build.outputs.autodiscover.reportnameprefix"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)

(Erforderlich, wenn [AutoDiscoverReports](#build.outputs.autodiscover) es enthalten und aktiviert ist)

Geben Sie ein Präfix an, das allen gefundenen Berichten CodeCatalyst vorangestellt wird, um die zugehörigen CodeCatalyst Berichte zu benennen. Wenn Sie beispielsweise das Präfix von `AutoDiscovered` angeben und zwei Testberichte CodeCatalyst automatisch erkennen, erhalten die zugehörigen CodeCatalyst Berichte den Namen `TestSuiteOne.xml` `AutoDiscoveredTestSuiteOne` und`TestSuiteTwo.xml`. `AutoDiscoveredTestSuiteTwo`

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Berichte/Präfixname**

## IncludePaths
<a name="build.reports.includepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)

(Erforderlich, wenn [AutoDiscoverReports](#build.outputs.autodiscover) es enthalten und aktiviert ist, oder wenn es enthalten ist) [Reports](#test.configuration.reports)

Geben Sie die Dateien und Dateipfade an, CodeCatalyst die bei der Suche nach Rohberichten berücksichtigt werden. Wenn Sie beispielsweise angeben`"/test/report/*"`, wird das gesamte [Build-Image](build-images.md), das von der Aktion verwendet wurde, nach dem `/test/report/*` Verzeichnis CodeCatalyst durchsucht. Wenn das Verzeichnis gefunden CodeCatalyst wird, wird in diesem Verzeichnis nach Berichten gesucht.

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder andere Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Wenn diese Eigenschaft weggelassen wird, ist die Standardeinstellung`"**/*"`, was bedeutet, dass die Suche alle Dateien in allen Pfaden umfasst.

**Anmerkung**  
Bei manuell konfigurierten Berichten `IncludePaths` muss es sich um ein Glob-Muster handeln, das einer einzelnen Datei entspricht.

Entsprechende Benutzeroberfläche:
+ **Gibt Pfade tab/Reports/Auto-discover reports/Include/exclude aus/Pfade einschließen**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /Pfadeeinschließen/Ausschließen/ Pfade *report-name-1* einschließen**

## ExcludePaths
<a name="build.reports.excludepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**)

(Optional)

Geben Sie die Dateien und Dateipfade an, die bei der Suche nach Rohberichten ausgeschlossen werden sollen. CodeCatalyst Wenn Sie beispielsweise angeben`"/test/my-reports/**/*"`, CodeCatalyst wird nicht nach Dateien im `/test/my-reports/` Verzeichnis gesucht. Um alle Dateien in einem Verzeichnis zu ignorieren, verwenden Sie das `**/*` Glob-Muster.

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder andere Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Entsprechende Benutzeroberfläche:
+ **Gibt tab/Reports/Auto-discover reports/Include/exclude Pfade aus/ Pfade ausschließen**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /Pfadeeinschließen/Ausschließen/ Pfade ausschließen *report-name-1***

## SuccessCriteria
<a name="build.reports.successcriteria"></a>

(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**)

(Optional)

Geben Sie die Erfolgskriterien für die Berichte Test, Codeabdeckung, Software Composition Analysis (SCA) und Static Analysis (SA) an.

Weitere Informationen finden Sie unter [Erfolgskriterien für Berichte konfigurieren](test-config-action.md#test.success-criteria).

**Entsprechende Benutzeroberfläche: Registerkarte „Ausgabe/Berichte/Erfolgskriterien“**

## PassRate
<a name="build.reports.successcriteria.passrate"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)

(Optional)

Geben Sie den Prozentsatz der Tests in einem Testbericht an, die bestanden werden müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Erfolgsquote werden nur auf Testberichte angewendet. Weitere Informationen zu Testberichten finden Sie unter[Testberichte](test-workflow-actions.md#test-reports).

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Erfolgsquote**

## LineCoverage
<a name="build.reports.successcriteria.linecoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)

(Optional)

Geben Sie den Prozentsatz der Zeilen in einem Bericht zur Codeabdeckung an, die abgedeckt sein müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Leitungsabdeckung werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Linienabdeckung**

## BranchCoverage
<a name="build.reports.successcriteria.branchcoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)

(Optional)

Geben Sie den Prozentsatz der Zweige in einem Bericht zur Codeabdeckung an, die abgedeckt werden müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Gültige Werte beinhalten Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Abdeckung von Filialen werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Branchenabdeckung**

## Vulnerabilities
<a name="build.reports.successcriteria.vulnerabilities"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad der Sicherheitslücken an, die im SCA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Sicherheitslücken zu spezifizieren, müssen Sie Folgendes angeben:
+ Der Mindestschweregrad der Sicherheitsanfälligkeiten, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie beispielsweise wählen `HIGH``HIGH`, werden alle `CRITICAL` Sicherheitslücken gezählt.
+ Die maximale Anzahl von Sicherheitslücken mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Kriterien für Sicherheitslücken werden nur auf SCA-Berichte angewendet. Weitere Informationen zu SCA-Berichten finden Sie unter[Berichte zur Analyse der Softwarezusammensetzung](test-workflow-actions.md#test-sca-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Sicherheitslücken**

## StaticAnalysisBug
<a name="build.reports.successcriteria.bugs"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisBug**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisBug**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad von Fehlern an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Fehler zu spezifizieren, müssen Sie Folgendes angeben:
+ Der minimale Schweregrad der Fehler, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie beispielsweise wählen`HIGH`, dann werden `HIGH` alle `CRITICAL` Bugs gezählt.
+ Die maximale Anzahl von Fehlern mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Kriterien für Fehler werden nur auf Berichte PyLint und ESLint Sicherheitsüberprüfungen angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Bugs**

## StaticAnalysisSecurity
<a name="build.reports.successcriteria.securityvulnerabilities"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisSecurity**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisSecurity**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad der Sicherheitslücken an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Sicherheitslücken zu spezifizieren, müssen Sie Folgendes angeben:
+ Der Mindestschweregrad der Sicherheitslücken, die Sie in die Zählung einbeziehen möchten. Gültige Werte (vom höchsten bis zum geringsten Schweregrad) sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie beispielsweise wählen`HIGH`, dann `HIGH` werden `CRITICAL` Sicherheitslücken gezählt.
+ Die maximale Anzahl von Sicherheitslücken mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Kriterien für Sicherheitslücken werden nur auf PyLint Berichte von ESLint Sicherheitslücken angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Sicherheitslücken**

## StaticAnalysisQuality
<a name="build.reports.successcriteria.qualityissues"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisQuality**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisQuality**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad von Qualitätsproblemen an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert werden kann. Um Qualitätsprobleme zu spezifizieren, müssen Sie Folgendes angeben:
+ Der Mindestschweregrad der Qualitätsprobleme, die Sie in die Zählung einbeziehen möchten. Gültige Werte (vom höchsten bis zum geringsten Schweregrad) sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie sich beispielsweise dafür entscheiden `HIGH``HIGH`, werden `CRITICAL` Qualitätsprobleme gezählt.
+ Die maximale Anzahl von Qualitätsproblemen mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Kriterien für Qualitätsprobleme werden nur auf Berichte PyLint und ESLint SA-Berichte angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Qualitätsprobleme**

## StaticAnalysisFinding
<a name="build.reports.successcriteria.findings"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisFinding**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisFinding**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad der Ergebnisse an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert werden kann. Um Ergebnisse zu spezifizieren, müssen Sie Folgendes angeben:
+ Der Mindestschweregrad der Ergebnisse, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie beispielsweise wählen`HIGH`, dann werden `HIGH` die `CRITICAL` Ergebnisse zusammengezählt.
+ Die maximale Anzahl von Ergebnissen mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Ergebnisse werden nur auf Berichte der SARIF SA angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

**Entsprechende Benutzeroberfläche: tab/Reports/Success Ausgabekriterien/Ergebnisse**

## Reports
<a name="test.configuration.reports"></a>

(*action-name*/Outputs/**Reports** )

(Optional)

Ein Abschnitt, der die Konfiguration für Testberichte spezifiziert.

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Berichte**

## Berichtsname-1
<a name="test.configuration.reports.report-name-1"></a>

**(Berichtsname-1) *action-name* /Outputs/Reports/**

(Erforderlich, falls enthalten) [Reports](#test.configuration.reports)

Der Name, den Sie dem CodeCatalyst Bericht geben möchten, der aus Ihren Rohberichten generiert wird.

**Entsprechende Benutzeroberfläche: Ausgaben, Berichte tab/Reports/Manually konfigurieren/Berichtsname**

## Format
<a name="test.configuration.reports.name.testresults.format"></a>

(*action-name*/Outputs/Reports/*report-name-1*/**Format**)

(Erforderlich, falls enthalten[Reports](#test.configuration.reports))

Geben Sie das Dateiformat an, das Sie für Ihre Berichte verwenden. Mögliche Werte können sein wie folgt.
+ Für Testberichte:
  + Geben Sie für Cucumber JSON **Cucumber** (visueller Editor) oder `CUCUMBERJSON` (YAML-Editor) an.
  + Geben Sie für JUnit XML **JUnit**(visueller Editor) oder `JUNITXML` (YAML-Editor) an.
  + Geben Sie für NUnit XML **NUnit**(visueller Editor) oder `NUNITXML` (YAML-Editor) an.
  + Geben Sie für NUnit 3-XML **NUnit3**(visueller Editor) oder `NUNIT3XML` (YAML-Editor) an.
  + Geben Sie für Visual Studio TRX **Visual Studio TRX** (visueller Editor) oder `VISUALSTUDIOTRX` (YAML-Editor) an.
  + Geben Sie für TestNG XML **TestNG** (visueller Editor) oder `TESTNGXML` (YAML-Editor) an.
+ Für Berichte über die Codeabdeckung:
  + Geben Sie für Clover-XML **Clover** (visueller Editor) oder `CLOVERXML` (YAML-Editor) an.
  + Geben Sie für Cobertura XML **Cobertura (visueller Editor) oder (YAML-Editor**) an. `COBERTURAXML`
  + Geben Sie für JaCoCo XML **JaCoCo**(visueller Editor) oder `JACOCOXML` (YAML-Editor) an.
  + Geben Sie für SimpleCov JSON, das von [simplecov und nicht von simplecov-json](https://github.com/simplecov-ruby/simplecov) [generiert wurde, Simplecov](https://github.com/vicentllongo/simplecov-json) (visueller Editor) oder (**YAML-Editor**) an. `SIMPLECOV`
+ Für SCA-Berichte (Software Composition Analysis):
  + Geben Sie für SARIF **SARIF** (Visual Editor) oder `SARIFSCA` (YAML-Editor) an.

****Entsprechende Benutzeroberfläche: Gibt tab/Reports/Manually configure reports/Add/configure Berichte aus*report-name-1*//Berichtstyp und Berichtsformat****

## Configuration
<a name="build.configuration"></a>

(*action-name*/**Configuration**)

(Erforderlich) Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können. 

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## Container
<a name="build.configuration.container"></a>

(*action-name*/Configuration/**Container**)

(Optional)

Geben Sie das Docker-Image oder den *Container* an, den die Aktion verwendet, um die Verarbeitung abzuschließen. Sie können eines der mitgelieferten [aktiven Images](build-images.md#build-curated-images) angeben CodeCatalyst, oder Sie können Ihr eigenes Image verwenden. Wenn Sie Ihr eigenes Image verwenden möchten, kann es sich in Amazon ECR, Docker Hub oder einer anderen Registrierung befinden. Wenn Sie kein Docker-Image angeben, verwendet die Aktion eines der aktiven Images für die Verarbeitung. Informationen darüber, welches aktive Image standardmäßig verwendet wird, finden Sie unter[Aktive Bilder](build-images.md#build-curated-images).

Weitere Informationen zur Angabe Ihres eigenen Docker-Images finden Sie unter[Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](build-images.md#build-images-specify).

Entsprechende Benutzeroberfläche: **Docker-Image für die Laufzeitumgebung** — optional

## Registry
<a name="build.configuration.container.registry"></a>

(*action-name*/Configuration/Container/**Registry**)

(Erforderlich, wenn `Container` es enthalten ist)

Geben Sie die Registrierung an, in der Ihr Bild gespeichert ist. Gültige Werte sind:
+ `CODECATALYST`(YAML-Editor)

  Das Bild wird in der CodeCatalyst Registrierung gespeichert.
+ **Docker Hub** (visueller Editor) oder `DockerHub` (YAML-Editor)

  Das Bild wird in der Docker Hub-Image-Registry gespeichert.
+ **Andere Registrierung** (visueller Editor) oder `Other` (YAML-Editor)

  Das Bild wird in einer benutzerdefinierten Bildregistrierung gespeichert. Jede öffentlich verfügbare Registrierung kann verwendet werden.
+ **Amazon Elastic Container Registry** (visueller Editor) oder `ECR` (YAML-Editor)

  Das Bild wird in einem Image-Repository der Amazon Elastic Container Registry gespeichert. Um ein Bild in einem Amazon ECR-Repository zu verwenden, benötigt diese Aktion Zugriff auf Amazon ECR. Um diesen Zugriff zu aktivieren, müssen Sie eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) erstellen, die die folgenden Berechtigungen und eine benutzerdefinierte Vertrauensrichtlinie umfasst. (Sie können eine bestehende Rolle so ändern, dass sie die Berechtigungen und die Richtlinie einbezieht, wenn Sie möchten.)

  Die IAM-Rolle muss die folgenden Berechtigungen in ihrer Rollenrichtlinie enthalten:
  + `ecr:BatchCheckLayerAvailability`
  + `ecr:BatchGetImage`
  + `ecr:GetAuthorizationToken`
  + `ecr:GetDownloadUrlForLayer`

  Die IAM-Rolle muss die folgende benutzerdefinierte Vertrauensrichtlinie enthalten:

  Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) im *IAM-Benutzerhandbuch*.

  Nachdem Sie die Rolle erstellt haben, müssen Sie sie der Aktion über eine Umgebung zuweisen. Weitere Informationen finden Sie unter [Eine Umgebung mit einer Aktion verknüpfen](deploy-environments-add-app-to-environment.md).

Entsprechende Benutzeroberfläche: **Amazon Elastic Container Registry**, **Docker Hub** und **andere Registrierungsoptionen**

## Image
<a name="build.configuration.container.image"></a>

(*action-name*/Configuration/Container/**Image**)

(Erforderlich, falls `Container` enthalten)

Geben Sie eines der folgenden Elemente an:
+ Wenn Sie eine `CODECATALYST` Registrierung verwenden, legen Sie für das Image eines der folgenden [aktiven Images](build-images.md#build-curated-images) fest:
  + `CodeCatalystLinux_x86_64:2024_03`
  + `CodeCatalystLinux_x86_64:2022_11`
  + `CodeCatalystLinux_Arm64:2024_03`
  + `CodeCatalystLinux_Arm64:2022_11`
  + `CodeCatalystLinuxLambda_x86_64:2024_03`
  + `CodeCatalystLinuxLambda_x86_64:2022_11`
  + `CodeCatalystLinuxLambda_Arm64:2024_03`
  + `CodeCatalystLinuxLambda_Arm64:2022_11`
  + `CodeCatalystWindows_x86_64:2022_11`
+ Wenn Sie eine Docker Hub-Registry verwenden, legen Sie für das Image den Namen des Docker Hub-Images und das optionale Tag fest.

  Beispiel: `postgres:latest`
+ Wenn Sie eine Amazon ECR-Registrierung verwenden, setzen Sie das Bild auf die Amazon ECR-Registrierungs-URI.

  Beispiel: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ Wenn Sie eine benutzerdefinierte Registrierung verwenden, setzen Sie das Bild auf den Wert, der von der benutzerdefinierten Registrierung erwartet wird.

**Entsprechende Benutzeroberfläche: **Docker-Image der Laufzeitumgebung** (falls die Registrierung vorhanden ist`CODECATALYST`), **Docker Hub-Image** (wenn die Registrierung **Docker Hub** ist), **ECR-Image-URL** (wenn die Registrierung **Amazon Elastic Container** Registry ist) und **Image-URL** (wenn die Registrierung Andere Registrierung ist).**

## Steps
<a name="build.configuration.steps"></a>

(*action-name*/Configuration/**Steps**)

(Erforderlich) 

Geben Sie die Shell-Befehle an, die Sie während der Aktion zur Installation, Konfiguration und Ausführung Ihrer Build-Tools ausführen möchten.

Hier ist ein Beispiel für die Erstellung eines NPM-Projekts:

```
Steps:
  - Run: npm install
  - Run: npm run build
```

Hier ist ein Beispiel für die Angabe von Dateipfaden:

```
Steps:
  - Run: cd $ACTION_BUILD_SOURCE_PATH_WorkflowSource/app  && cat file2.txt
  - Run: cd $ACTION_BUILD_SOURCE_PATH_MyBuildArtifact/build-output/  && cat file.txt
```

Weitere Hinweise zum Angeben von Dateipfaden finden Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und[Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Shell-Befehle**

## Packages
<a name="build.configuration.packages"></a>

(*action-name*/Configuration/**Packages**)

(Optional) 

Ein Abschnitt, in dem Sie ein Paket-Repository angeben können, das die Aktion zum Auflösen von Abhängigkeiten verwendet. Mit Paketen können Sie Softwarepakete, die für die Anwendungsentwicklung verwendet werden, sicher speichern und gemeinsam nutzen.

Weitere Informationen zu Paketen finden Sie unter[Veröffentlichen und teilen Sie Softwarepakete in CodeCatalyst](packages.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„Pakete“**

## NpmConfiguration
<a name="build.configuration.packages.npm"></a>

(*action-name*/Configuration/Packages/**NpmConfiguration**)

(Erforderlich, wenn [Packages](#build.configuration.packages) es enthalten ist)

Ein Abschnitt, der die Konfiguration für das npm-Paketformat definiert. Diese Konfiguration wird von einer Aktion während einer Workflow-Ausführung verwendet.

Weitere Informationen zur Konfiguration des npm-Pakets finden Sie unter[Verwenden von npm](packages-npm.md).

**Entsprechende Benutzeroberfläche: Configuration tab/Packages/Add configuration/npm**

## PackageRegistries
<a name="build.configuration.packages.registry"></a>

(*action-name*/Configuration/Packages/NpmConfiguration/**PackageRegistries**)

(Erforderlich, wenn [Packages](#build.configuration.packages) es enthalten ist)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften einer Folge von Paket-Repositorys definieren können.

Entsprechende Benutzeroberfläche: Konfigurationtab/Packages/Add configuration/npm//**Paket-Repository hinzufügen**

## PackagesRepository
<a name="build.configuration.packages.repository"></a>

(*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**PackagesRepository**)

(Erforderlich, wenn [Packages](#build.configuration.packages) es enthalten ist)

Geben Sie den Namen Ihres CodeCatalyst *Paket-Repositorys* an, das die Aktion verwenden soll.

Wenn Sie mehrere Standard-Repositorys angeben, hat das letzte Repository Priorität.

Weitere Hinweise zu Paket-Repositorys finden Sie unter. [Paket-Repositorys](packages-concepts.md#packages-concepts-repository)

**Entsprechende Benutzeroberfläche: tab/Packages/Add configuration/npm/Add Konfigurationspaket-Repository/ Paket-Repository**

## Scopes
<a name="build.configuration.packages.scope"></a>

(*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**Scopes**)

(Optional) 

Geben Sie eine Reihenfolge von Bereichen an, *die* Sie in Ihrer Paketregistrierung definieren möchten. Bei der Definition von Bereichen wird das angegebene Paket-Repository als Registrierung für alle aufgelisteten Bereiche konfiguriert. Wenn ein Paket mit dem Bereich über den npm-Client angefordert wird, verwendet es dieses Repository anstelle des Standard-Repositorys. Jedem Bereichsnamen muss ein „@“ vorangestellt werden.

Wenn Sie übergeordnete Bereiche einbeziehen, hat das letzte Repository Vorrang.

Wenn `Scopes` es weggelassen wird, wird das angegebene Paket-Repository als Standardregistrierung für alle von der Aktion verwendeten Pakete konfiguriert.

Weitere Informationen zu Bereichen finden Sie unter [Paket-Namespaces](packages-concepts.md#packages-concepts-package-namespaces) und Pakete mit [Geltungsbereich](https://docs.npmjs.com/cli/v10/using-npm/scope).

**Entsprechende Benutzeroberfläche: tab/Packages/Add configuration/npm/Add Konfigurationspaket-Repository/ Scopes — optional**

## ExportAuthorizationToken
<a name="build.configuration.packages.exportauthtoken"></a>

(*action-name*/Configuration/Packages/**ExportAuthorizationToken**)

(Optional) 

Aktivieren oder deaktivieren Sie die Funktion für Exportautorisierungstoken. Wenn diese Option aktiviert ist, können exportierte Autorisierungstoken verwendet werden, um einen Paketmanager manuell für die Authentifizierung bei CodeCatalyst Paket-Repositorys zu konfigurieren. Sie können das Token als Umgebungsvariable verwenden, auf die in Ihren Aktionen verwiesen werden kann.

Gültige Werte sind `true` oder `false`.

Wenn `ExportAuthorizationToken` es weggelassen wird, ist die Standardeinstellung`false`.

Weitere Hinweise zum Exportautorisierungstoken finden Sie unter[Verwenden von Autorisierungstoken in Workflow-Aktionen](workflows-package-export-token.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Pakete/Autorisierungstoken exportieren“**

# Testen mit Workflows
<a name="test-workflow-actions"></a>

 CodeCatalystIn können Sie Tests als Teil verschiedener Workflow-Aktionen wie Build und Test ausführen. Diese Workflow-Aktionen können alle Qualitätsberichte generieren. Eine *Testaktion* ist eine Workflow-Aktion, mit der Berichte zu Tests, zur Codeabdeckung, zur Softwarezusammensetzung und zu statischen Analysen erstellt werden. Diese Berichte werden in der CodeCatalyst Konsole angezeigt.

**Topics**
+ [

## Typen von Qualitätsberichten
](#test-reporting)
+ [

# Testaktion hinzufügen
](test-add-action.md)
+ [

# Ergebnisse einer Testaktion anzeigen
](test-view-results.md)
+ [

# Fehlgeschlagene Tests in einer Aktion überspringen
](test.error-handling.md)
+ [

# Integrieren mit universal-test-runner
](test.universal-test-runner.md)
+ [

# Qualitätsberichte in einer Aktion konfigurieren
](test-config-action.md)
+ [

# Bewährte Methoden zum Testen
](test-best-practices.md)
+ [

# Unterstützte SARIF-Eigenschaften
](test.sarif.md)

## Typen von Qualitätsberichten
<a name="test-reporting"></a>

Die CodeCatalyst Amazon-Testaktion unterstützt die folgenden Arten von Qualitätsberichten. Ein Beispiel zur Formatierung dieser Berichte in Ihrem YAML finden Sie unter[YAML-Beispiel für Qualitätsberichte](test-config-action.md#test.success-criteria-example).

**Topics**
+ [

### Testberichte
](#test-reports)
+ [

### Code-Abdeckungsberichte
](#test-code-coverage-reports)
+ [

### Berichte zur Analyse der Softwarezusammensetzung
](#test-sca-reports)
+ [

### Statische Analyseberichte
](#test-static-analysis-reports)

### Testberichte
<a name="test-reports"></a>

In CodeCatalyst können Sie Komponententests, Integrationstests und Systemtests konfigurieren, die während Builds ausgeführt werden. Anschließend CodeCatalyst können Sie Berichte erstellen, die die Ergebnisse Ihrer Tests enthalten.

Sie können einen Testbericht verwenden, um Probleme mit Ihren Tests zu beheben. Wenn Sie über viele Testberichte von mehreren Builds verfügen, können Sie anhand Ihrer Testberichte die Fehlerraten anzeigen und so Ihre Builds optimieren.

Sie können die folgenden Dateiformate für Testberichte verwenden:
+ Gurke JSON (.json)
+ JUnit XML (.xml)
+ NUnit XML (.xml)
+ NUnit3 XML (.xml)
+ TestNG XML (.xml)
+ Visual Studio TRX (.trx, .xml)

### Code-Abdeckungsberichte
<a name="test-code-coverage-reports"></a>

 CodeCatalystIn können Sie Berichte zur Codeabdeckung für Ihre Tests erstellen. CodeCatalyst bietet die folgenden Kennzahlen zur Codeabdeckung:

Zeilenabdeckung  
Misst, wie viele Aussagen Ihre Tests abdecken. Eine Aussage ist eine einzelne Anweisung, ohne Kommentare.  
`line coverage = (total lines covered)/(total number of lines)`

Verzweigungsabdeckung  
Misst, wie viele Zweige Ihre Tests von allen möglichen Zweigen einer Kontrollstruktur, wie z. B. einer `case` ODER-Anweisung, abdecken. `if`  
`branch coverage = (total branches covered)/(total number of branches)`

Für Code-Abdeckungsberichte werden die folgenden Dateiformate unterstützt:
+ JaCoCo XML (.xml)
+ SimpleCov [JSON (generiert von [simplecov, nicht simplecov-json](https://github.com/simplecov-ruby/simplecov), .json)](https://github.com/vicentllongo/simplecov-json)
+ Clover XML (Version 3, .xml)
+ XML-Cover (.xml)
+ LCOV (.info)

### Berichte zur Analyse der Softwarezusammensetzung
<a name="test-sca-reports"></a>

In CodeCatalyst können Sie Tools zur Software Composition Analysis (SCA) verwenden, um Komponenten Ihrer Anwendung zu analysieren und nach bekannten Sicherheitslücken zu suchen. Sie können SARIF-Berichte entdecken und analysieren, in denen Sicherheitslücken mit unterschiedlichem Schweregrad und Möglichkeiten zu ihrer Behebung detailliert beschrieben werden. Gültige Schweregradwerte, vom höchsten bis zum geringsten Schweregrad, sind:`CRITICAL`,,,`HIGH`,`MEDIUM`. `LOW` `INFORMATIONAL`

Die folgenden Dateiformate für SCA-Berichte werden unterstützt:
+ SARIF (.sarif, .json)

### Statische Analyseberichte
<a name="test-static-analysis-reports"></a>

Sie können statische Analyseberichte (SA) verwenden, um Codefehler auf Quelltextebene zu identifizieren. In können Sie SA-Berichte generieren CodeCatalyst, um Probleme in Ihrem Code zu beheben, bevor Sie ihn bereitstellen. Zu diesen Problemen gehören Bugs, Sicherheitslücken, Qualitätsprobleme und andere Sicherheitslücken. Gültige Schweregradwerte, vom höchsten bis zum niedrigsten Schweregrad`CRITICAL`, sind: `HIGH``MEDIUM`,`LOW`,, und`INFORMATIONAL`.

CodeCatalyst bietet die folgenden SA-Metriken:

Bugs  
Identifiziert eine Reihe möglicher Fehler in Ihrem Quellcode. Zu diesen Fehlern können Probleme im Zusammenhang mit der Speichersicherheit gehören. Das Folgende ist ein Beispiel für einen Fehler.  

```
// The while loop will inadvertently index into array x out-of-bounds
int x[64];
while (int n = 0; n <= 64; n++) {
  x[n] = 0;
}
```

Sicherheitslücken  
Identifiziert eine Reihe möglicher Sicherheitslücken in Ihrem Quellcode. Zu diesen Sicherheitslücken können Probleme wie das Speichern Ihrer geheimen Token im Klartext gehören.

Probleme mit der Qualität  
Identifiziert eine Reihe möglicher Qualitätsprobleme in Ihrem Quellcode. Zu diesen Qualitätsproblemen können auch Probleme im Zusammenhang mit Stilkonventionen gehören. Im Folgenden finden Sie ein Beispiel für ein Qualitätsproblem.  

```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
  return x-y
}
```

Andere Sicherheitslücken  
Identifiziert eine Reihe möglicher anderer Sicherheitslücken, die in Ihrem Quellcode gefunden wurden.

CodeCatalyst unterstützt die folgenden SA-Berichtsdateiformate:
+ PyLint (.py)
+ ESLint (.js, .jsx, .ts, .tsx)
+ SARIF (.sarif, .json)

# Testaktion hinzufügen
<a name="test-add-action"></a>

Gehen Sie wie folgt vor, um Ihrem CodeCatalyst Workflow eine Testaktion hinzuzufügen. 

------
#### [ Visual ]

**Um eine Testaktion mit dem Visual Editor hinzuzufügen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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

1. Wählen Sie **unter Aktionen** die Option **Test** aus. 

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktionen erstellen und testen YAML](build-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 eine Build-Aktion mit dem YAML-Editor hinzuzufügen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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. Wählen Sie **Aktionen**.

1. Wählen Sie unter **Aktionen** die Option **Test** aus.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktionen erstellen und testen YAML](build-action-ref.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**.

------

## Testen Sie die Aktionsdefinition
<a name="test-add-action-definition"></a>

Die Testaktion ist als ein Satz von YAML-Eigenschaften in Ihrer Workflow-Definitionsdatei definiert. Informationen zu diesen Eigenschaften finden Sie [Aktionen erstellen und testen YAML](build-action-ref.md) in der[YAML-Workflow-Definition](workflow-reference.md).

# Ergebnisse einer Testaktion anzeigen
<a name="test-view-results"></a>

Verwenden Sie die folgenden Anweisungen, um die Ergebnisse einer Testaktion, einschließlich der generierten Protokolle, Berichte und Variablen, anzuzeigen.

**So zeigen Sie die Ergebnisse einer Testaktion an**

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 den Namen Ihrer Testaktion aus, zum Beispiel **Test**.

1. Um die durch eine Aktion generierten Protokolle anzuzeigen, wählen Sie **Logs** aus. Die Protokolle für die verschiedenen Aktionsphasen werden angezeigt. Sie können die Protokolle nach Bedarf erweitern oder reduzieren.

1. Um die durch die Testaktion erstellten Testberichte anzuzeigen, wählen Sie **Berichte** aus, oder wählen Sie im Navigationsbereich **Berichte** aus. Weitere Informationen finden Sie unter [Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).

1. Um die für die Testaktion verwendete Konfiguration anzuzeigen, wählen Sie **Konfiguration**. Weitere Informationen finden Sie unter [Testaktion hinzufügen](test-add-action.md).

1. Um die von der Testaktion verwendeten Variablen anzuzeigen, wählen Sie **Variablen**. Weitere Informationen finden Sie unter [Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

# Fehlgeschlagene Tests in einer Aktion überspringen
<a name="test.error-handling"></a>

Wenn Ihre Aktion mehr als einen Testbefehl umfasst, möchten Sie möglicherweise zulassen, dass nachfolgende Testbefehle in der Aktion ausgeführt werden, auch wenn ein vorheriger Befehl fehlschlägt. In den folgenden Befehlen können Sie beispielsweise festlegen, dass `test2` sie immer ausgeführt werden, auch wenn sie `test1` fehlschlagen.

```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```

Wenn ein Schritt einen Fehler zurückgibt, CodeCatalyst stoppt Amazon normalerweise die Workflow-Aktion und markiert sie als fehlgeschlagen. Sie können zulassen, dass die Aktionsschritte weiterhin ausgeführt werden, indem Sie die Fehlerausgabe an umleiten. `null` Sie können dies tun, indem Sie dem Befehl etwas `2>/dev/null` hinzufügen. Mit dieser Änderung würde das vorherige Beispiel wie folgt aussehen.

```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```

Im zweiten Codeausschnitt wird der Status des `npm install` Befehls berücksichtigt, aber alle vom `npm run test1` Befehl zurückgegebenen Fehler werden ignoriert. Infolgedessen wird der `npm run test2` Befehl ausgeführt. Auf diese Weise können Sie beide Berichte gleichzeitig anzeigen, unabhängig davon, ob ein Fehler auftritt.

# Integrieren mit universal-test-runner
<a name="test.universal-test-runner"></a>

Testaktionen sind in das Open-Source-Befehlszeilentool `universal-test-runner` integriert. `universal-test-runner`verwendet das [Test Execution Protocol](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md), um Ihre Tests für jede Sprache in einem bestimmten Framework auszuführen. `universal-test-runner`unterstützt die folgenden Frameworks:
+ [Gradle](https://gradle.org/)
+ [Scherz](https://jestjs.io/)
+ [Seherin](https://maven.apache.org/)
+ [Pytest](https://pytest.org)
+ [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/)

`universal-test-runner` wird nur auf den kuratierten Images für Testaktionen installiert. Wenn Sie eine Testaktion für die Verwendung eines benutzerdefinierten Docker Hub oder Amazon ECR konfigurieren, müssen Sie `universal-test-runner` manuell installieren, um erweiterte Testfunktionen aktivieren zu können. Installieren Sie dazu Node.js (14 oder höher) auf dem Image und installieren Sie dann `universal-test-runner` über `npm` mithilfe des Shell-Befehls `- Run: npm install -g @aws/universal-test-runner`. Weitere Informationen zur Installation von Node.js in Ihrem Container mithilfe von Shell-Befehlen finden Sie unter [Node Version Manager installieren und aktualisieren](https://github.com/nvm-sh/nvm#install--update-script).

Weitere Informationen zu `universal-test-runner` finden Sie unter [Was ist universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner)

------
#### [ Visual ]

**Zur Verwendung universal-test-runner im visuellen Editor**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Namen Ihres Workflows.

1. Wählen Sie **Bearbeiten** aus.

1. Wählen Sie **Visual**.

1. Wählen Sie **Aktionen**.

1. Wählen Sie **unter Aktionen** die Option **Test** aus. 

1. Füllen Sie auf der Registerkarte **Konfiguration** das Feld **Shell-Befehle** aus, indem Sie den Beispielcode mit den unterstützten Frameworks Ihrer Wahl aktualisieren. Um beispielsweise ein unterstütztes Framework zu verwenden, würden Sie einen `Run` Befehl verwenden, der dem folgenden ähnelt.

   ```
   - Run: run-tests <framework>
   ```

   Wenn das gewünschte Framework nicht unterstützt wird, können Sie einen eigenen benutzerdefinierten Adapter oder Runner beisteuern. Eine Beschreibung des Felds **Shell-Befehle** finden Sie unter[Steps](build-action-ref.md#build.configuration.steps).

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 ]

**Zur Verwendung universal-test-runner im YAML-Editor**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Namen Ihres Workflows.

1. Wählen Sie **Bearbeiten** aus.

1. Wählen Sie **YAML.**

1. Wählen Sie **Aktionen**.

1. Wählen Sie unter **Aktionen** die Option **Test** aus.

1. Ändern Sie den YAML-Code nach Ihren Bedürfnissen. Um beispielsweise ein unterstütztes Framework zu verwenden, würden Sie einen `Run` Befehl ähnlich dem folgenden verwenden.

   ```
   Configuration:
     Steps:
       - Run: run-tests <framework>
   ```

   Wenn das gewünschte Framework nicht unterstützt wird, können Sie einen eigenen benutzerdefinierten Adapter oder Runner beisteuern. Eine Beschreibung der Eigenschaft **Steps** finden Sie unter[Steps](build-action-ref.md#build.configuration.steps).

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

------

# Qualitätsberichte in einer Aktion konfigurieren
<a name="test-config-action"></a>

In diesem Abschnitt wird beschrieben, wie Sie einen Qualitätsbericht in einer Aktion konfigurieren.

**Topics**
+ [

## Automatische Erkennung und manuelle Berichte
](#test.auto-discovery)
+ [

## Erfolgskriterien für Berichte konfigurieren
](#test.success-criteria)
+ [

## YAML-Beispiel für Qualitätsberichte
](#test.success-criteria-example)

## Automatische Erkennung und manuelle Berichte
<a name="test.auto-discovery"></a>

Wenn die automatische Erkennung aktiviert ist, werden alle Eingaben, die an die Aktion übergeben wurden, und alle von der Aktion selbst generierten Dateien CodeCatalyst durchsucht. Dabei wird nach Berichten über Tests, Codeabdeckung, Software Composition Analysis (SCA) und statische Analyse (SA) gesucht. Sie können jeden dieser Berichte in CodeCatalyst anzeigen und bearbeiten.

Sie können auch manuell konfigurieren, welche Berichte generiert werden. Sie können den Typ des Berichts, den Sie generieren möchten, sowie das Dateiformat angeben. Weitere Informationen finden Sie unter [Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).

## Erfolgskriterien für Berichte konfigurieren
<a name="test.success-criteria"></a>

Sie können die Werte festlegen, die die Erfolgskriterien für einen Test-, Codeabdeckungs-, Software Composition Analysis (SCA) oder Static Analysis (SA) -Bericht bestimmen.

Erfolgskriterien sind Schwellenwerte, die bestimmen, ob ein Bericht erfolgreich ist oder nicht. CodeCatalyst generiert zunächst Ihren Bericht, bei dem es sich um einen Test-, Codeabdeckungs-, SCA- oder SA-Bericht handeln kann, und wendet dann die Erfolgskriterien auf die generierten Berichte an. Anschließend wird angezeigt, ob und in welchem Umfang die Erfolgskriterien erfüllt wurden. Wenn ein Bericht die angegebenen Erfolgskriterien nicht erfüllt, schlägt die CodeCatalyst Aktion fehl, mit der die Erfolgskriterien angegeben wurden.

Wenn Sie beispielsweise die Erfolgskriterien für Ihren SCA-Bericht festlegen, lauten die gültigen Sicherheitsanfälligkeitswerte zwischen dem schwersten und dem geringsten `CRITICAL` Schweregrad: `HIGH``MEDIUM`,,`LOW`,`INFORMATIONAL`. Wenn Sie die Kriterien für die Suche nach einer Sicherheitsanfälligkeit mit ihrem `HIGH` Schweregrad festlegen, schlägt der Bericht fehl, wenn entweder mindestens eine Sicherheitsanfälligkeit mit `HIGH` Schweregrad oder keine Sicherheitslücken mit `HIGH` Schweregrad vorhanden sind, aber mindestens eine Sicherheitsanfälligkeit mit einem höheren Schweregrad, z. B. eine Sicherheitsanfälligkeit mit `CRITICAL` Schweregrad.

Wenn Sie keine Erfolgskriterien angeben, gehen Sie wie folgt vor:
+ Der CodeCatalyst Bericht, der auf der Grundlage Ihrer Rohberichte generiert wird, zeigt keine Erfolgskriterien an.
+ Erfolgskriterien werden nicht verwendet, um zu bestimmen, ob die zugehörige Workflow-Aktion erfolgreich war oder nicht.

------
#### [ Visual ]

**Um Erfolgskriterien zu konfigurieren**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie einen Workflow aus, der eine Aktion enthält, die einen Bericht generiert. Dies ist der Bericht, für den Sie Erfolgskriterien anwenden möchten. 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, die Sie für die Generierung von CodeCatalyst Berichten konfiguriert haben.

1. Wählen Sie die Registerkarte **Outputs**.

1. Wählen Sie unter **Automatische Erkennung von Berichten** oder unter **Berichte manuell konfigurieren** die Option **Erfolgskriterien** aus.

   Erfolgskriterien werden angezeigt. Abhängig von Ihrer vorherigen Auswahl werden Ihnen möglicherweise einige oder alle dieser Optionen angezeigt:

   **Erfolgsquote**

   Geben Sie den Prozentsatz der Tests in einem Testbericht an, die bestanden werden müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Erfolgsquote werden nur auf Testberichte angewendet. Weitere Informationen zu Testberichten finden Sie unter[Testberichte](test-workflow-actions.md#test-reports).

   **Abdeckung der Leitungen**

   Geben Sie den Prozentsatz der Zeilen in einem Bericht über die Codeabdeckung an, die abgedeckt sein müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Leitungsabdeckung werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

   **Abdeckung der Filialen**

   Geben Sie den Prozentsatz der Filialen in einem Bericht über die Codeabdeckung an, die abgedeckt sein müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Gültige Werte beinhalten Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Abdeckung von Filialen werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

   **Sicherheitslücken (SCA)**

   Geben Sie die maximale Anzahl und den Schweregrad der Sicherheitslücken an, die im SCA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert werden kann. Um Sicherheitslücken zu spezifizieren, müssen Sie Folgendes angeben:
   + Der Mindestschweregrad der Sicherheitsanfälligkeiten, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

     Wenn Sie beispielsweise wählen `HIGH``HIGH`, werden alle `CRITICAL` Sicherheitslücken gezählt.
   + Die maximale Anzahl von Sicherheitslücken mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

   Die Kriterien für Sicherheitslücken werden nur auf SCA-Berichte angewendet. Weitere Informationen zu SCA-Berichten finden Sie unter[Berichte zur Analyse der Softwarezusammensetzung](test-workflow-actions.md#test-sca-reports).

   **Bugs**

   Geben Sie die maximale Anzahl und den Schweregrad der Fehler an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Fehler zu spezifizieren, müssen Sie Folgendes angeben:
   + Der minimale Schweregrad der Fehler, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

     Wenn Sie beispielsweise wählen`HIGH`, dann werden `HIGH` alle `CRITICAL` Bugs gezählt.
   + Die maximale Anzahl von Fehlern mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

   Die Kriterien für Fehler werden nur auf Berichte PyLint und ESLint Sicherheitsüberprüfungen angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

   **Sicherheitslücken**

   Geben Sie die maximale Anzahl und den Schweregrad der Sicherheitslücken an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Sicherheitslücken zu spezifizieren, müssen Sie Folgendes angeben:
   + Der Mindestschweregrad der Sicherheitslücken, die Sie in die Zählung einbeziehen möchten. Gültige Werte (vom höchsten bis zum geringsten Schweregrad) sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

     Wenn Sie beispielsweise wählen`HIGH`, dann `HIGH` werden `CRITICAL` Sicherheitslücken gezählt.
   + Die maximale Anzahl von Sicherheitslücken mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

   Die Kriterien für Sicherheitslücken werden nur auf PyLint Berichte von ESLint Sicherheitslücken angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

   **Probleme mit der Qualität**

   Geben Sie die maximale Anzahl und den Schweregrad der Qualitätsprobleme an, die im SA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert werden kann. Um Qualitätsprobleme zu spezifizieren, müssen Sie Folgendes angeben:
   + Der Mindestschweregrad der Qualitätsprobleme, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

     Wenn Sie sich beispielsweise dafür entscheiden `HIGH``HIGH`, werden `CRITICAL` Qualitätsprobleme gezählt.
   + Die maximale Anzahl von Qualitätsproblemen mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

   Die Kriterien für Qualitätsprobleme werden nur auf Berichte PyLint und ESLint SA-Berichte angewendet. Weitere Informationen zu SA-Berichten finden Sie unter[Statische Analyseberichte](test-workflow-actions.md#test-static-analysis-reports).

1. Wählen Sie **Commit** (Übergeben).

1. Führen Sie Ihren Workflow so aus, dass Erfolgskriterien auf Ihre Rohberichte CodeCatalyst angewendet werden, und generieren Sie die zugehörigen CodeCatalyst Berichte erneut, einschließlich der Informationen zu den Erfolgskriterien. Weitere Informationen finden Sie unter [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).

------
#### [ YAML ]

**Um Erfolgskriterien zu konfigurieren**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie einen Workflow aus, der eine Aktion enthält, die einen Bericht generiert. Dies ist der Bericht, für den Sie Erfolgskriterien anwenden möchten. 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. Wählen Sie im Workflow-Diagramm die Aktion aus, die Sie für die Generierung von CodeCatalyst Berichten konfiguriert haben.

1. Wählen Sie im Detailbereich die Registerkarte **Ausgaben** aus.

1. Fügen Sie in der Aktion, im `AutoDiscoverReports` Abschnitt oder im `Reports` Abschnitt eine **SuccessCriteria**Eigenschaft zusammen mit`PassRate`,,`LineCoverage`,`BranchCoverage`, `Vulnerabilities` `StaticAnalysisBug``StaticAnalysisSecurity`, und `StaticAnalysisQuality` Eigenschaften hinzu.

   Eine Erläuterung der einzelnen Eigenschaften finden Sie im[Aktionen erstellen und testen YAML](build-action-ref.md).

1. Wählen Sie **Commit** (Übergeben).

1. Führen Sie Ihren Workflow so aus, dass Erfolgskriterien auf Ihre Rohberichte CodeCatalyst angewendet werden, und generieren Sie die zugehörigen CodeCatalyst Berichte erneut, einschließlich der Informationen zu den Erfolgskriterien. Weitere Informationen zum Starten eines Workflows finden Sie unter[Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).

------

## YAML-Beispiel für Qualitätsberichte
<a name="test.success-criteria-example"></a>

 Das folgende Beispiel zeigt, wie Sie vier Berichte manuell konfigurieren: einen Testbericht, einen Bericht zur Codeabdeckung, einen Analysebericht zur Softwarezusammensetzung und einen statischen Analysebericht.

```
Reports:
  MyTestReport:
    Format: JUNITXML
    IncludePaths:
      - "*.xml"
    ExcludePaths:
      - report1.xml
      SuccessCriteria:
        PassRate: 90
  MyCoverageReport:
    Format: CLOVERXML
    IncludePaths:
      - output/coverage/jest/clover.xml
      SuccessCriteria:
        LineCoverage: 75
        BranchCoverage: 75
  MySCAReport:
    Format: SARIFSCA
    IncludePaths:
      - output/sca/reports.xml
      SuccessCriteria:
        Vulnerabilities:
          Number: 5
          Severity: HIGH
  MySAReport:
    Format: ESLINTJSON
    IncludePaths:
      - output/static/eslint.xml
      SuccessCriteria:
        StaticAnalysisBug:
          Number: 10
          Severity: MEDIUM
        StaticAnalysisSecurity:
          Number: 5
          Severity: CRITICAL
        StaticAnalysisQuality:
          Number: 0
          Severity: INFORMATIONAL
```

# Bewährte Methoden zum Testen
<a name="test-best-practices"></a>

Wenn Sie die von bereitgestellten Testfunktionen verwenden CodeCatalyst, empfehlen wir Ihnen, diese bewährten Methoden zu befolgen.

**Topics**
+ [

## Automatische Erkennung
](#test.best-auto-discovery)
+ [

## Erfolgskriterien
](#test.best-success-criteria)
+ [

## Pfade einschließen/ausschließen
](#test.best-include-exclude)

## Automatische Erkennung
<a name="test.best-auto-discovery"></a>

Bei der Konfiguration von Aktionen in CodeCatalyst können Sie mit der automatischen Erkennung automatisch die Ergebnisse verschiedener Tools ermitteln, z. B. JUnit Testberichte, und daraus relevante CodeCatalyst Berichte generieren. Durch die automatische Erkennung wird sichergestellt, dass weiterhin Berichte generiert werden, auch wenn sich die Namen oder Pfade zu den erkannten Ergebnissen ändern. Wenn neue Dateien hinzugefügt werden, werden diese CodeCatalyst automatisch erkannt und relevante Berichte erstellt. Wenn Sie jedoch die automatische Erkennung verwenden, ist es wichtig, einige der folgenden Aspekte dieser Funktion zu berücksichtigen:
+ Wenn Sie in Ihrer Aktion die automatische Erkennung aktivieren, weisen alle automatisch erkannten Berichte desselben Typs dieselben Erfolgskriterien auf. Beispielsweise würden gemeinsame Kriterien wie die Mindestbestehensquote für alle automatisch erkannten Testberichte gelten. Wenn Sie unterschiedliche Kriterien für Berichte desselben Typs benötigen, müssen Sie jeden dieser Berichte explizit konfigurieren.
+ Mit der automatischen Erkennung können auch Berichte gefunden werden, die von Ihren Abhängigkeiten erstellt wurden. Wenn Erfolgskriterien konfiguriert sind, schlägt die Aktion für diese Berichte möglicherweise fehl. Dieses Problem kann durch eine Aktualisierung der Konfiguration für den Ausschlusspfad behoben werden.
+ Es kann nicht garantiert werden, dass bei der automatischen Erkennung jedes Mal dieselbe Berichtsliste erstellt wird, da die Aktion zur Laufzeit gescannt wird. Wenn Sie möchten, dass ein bestimmter Bericht immer erstellt wird, sollten Sie Berichte explizit konfigurieren. Wenn beispielsweise Tests im Rahmen Ihres Builds nicht mehr ausgeführt werden, würde das Testframework keine Ausgaben erzeugen und folglich würde kein Testbericht erstellt werden, und die Aktion könnte erfolgreich sein. Wenn Sie möchten, dass der Erfolg Ihrer Aktion von diesem speziellen Test abhängt, müssen Sie diesen Bericht explizit konfigurieren.

**Tipp**  
Wenn Sie mit einem neuen oder vorhandenen Projekt beginnen, verwenden Sie die automatische Erkennung für das gesamte Projektverzeichnis (einschließlich`**/*`). Dadurch wird die Berichtsgenerierung für alle Dateien in Ihrem Projekt aufgerufen, einschließlich der Dateien in Unterverzeichnissen.

Weitere Informationen finden Sie unter [Qualitätsberichte in einer Aktion konfigurieren](test-config-action.md).

## Erfolgskriterien
<a name="test.best-success-criteria"></a>

Sie können Qualitätsgrenzwerte für Ihre Berichte durchsetzen, indem Sie Erfolgskriterien konfigurieren. Wenn beispielsweise zwei Codeabdeckungsberichte automatisch erkannt wurden, einer mit einer Leitungsabdeckung von 80% und der andere mit einer Leitungsabdeckung von 60%, haben Sie die folgenden Optionen:
+ Legen Sie die Erfolgskriterien für die automatische Erkennung für die Leitungsabdeckung auf 80% fest. Dies würde dazu führen, dass der erste Bericht erfolgreich und der zweite Bericht fehlschlägt, was dazu führen würde, dass die gesamte Aktion fehlschlägt. Um den Workflow zu entsperren, fügen Sie Ihrem Projekt neue Tests hinzu, bis die Zeilenabdeckung für den zweiten Bericht 80% überschreitet.
+ Legen Sie die Erfolgskriterien für die automatische Erkennung für die Leitungsabdeckung auf 60% fest. Dies würde dazu führen, dass beide Berichte erfolgreich sind, was wiederum zum Erfolg der Aktion führen würde. Sie könnten dann daran arbeiten, die Codeabdeckung im zweiten Bericht zu erhöhen. Mit diesem Ansatz können Sie jedoch nicht garantieren, dass der Erfassungsgrad im ersten Bericht nicht unter 80% fällt.
+ Konfigurieren Sie einen oder beide Berichte explizit, indem Sie den visuellen Editor verwenden oder für jeden Bericht einen expliziten YAML-Abschnitt und -Pfad hinzufügen. Auf diese Weise könnten Sie separate Erfolgskriterien und benutzerdefinierte Namen für jeden Bericht konfigurieren. Bei diesem Ansatz könnte die Aktion jedoch fehlschlagen, wenn sich die Berichtspfade ändern.

Weitere Informationen finden Sie unter [Erfolgskriterien für Berichte konfigurieren](test-config-action.md#test.success-criteria).

## Pfade einschließen/ausschließen
<a name="test.best-include-exclude"></a>

Bei der Überprüfung der Aktionsergebnisse können Sie die Liste der Berichte, die generiert werden, anpassen, CodeCatalyst indem Sie und konfigurieren`IncludePaths`. `ExcludePaths`
+ Geben `IncludePaths` Sie hier die Dateien und Dateipfade CodeCatalyst an, die Sie bei der Suche nach Berichten berücksichtigen möchten. Wenn Sie beispielsweise angeben, dass das gesamte Build-Image`"/test/report/*"`, das von der Aktion verwendet wurde, nach dem `/test/report/` Verzeichnis CodeCatalyst durchsucht wird, durchsucht wird. Wenn das Verzeichnis gefunden CodeCatalyst wird, wird in diesem Verzeichnis nach Berichten gesucht.
**Anmerkung**  
Bei manuell konfigurierten Berichten `IncludePaths` muss es sich um ein Glob-Muster handeln, das einer einzelnen Datei entspricht.
+ Geben `ExcludePaths` Sie hier die Dateien und Dateipfade an, die Sie bei der Suche nach Berichten ausschließen möchten CodeCatalyst . Wenn Sie beispielsweise angeben`"/test/reports/**/*"`, CodeCatalyst wird nicht nach Dateien im `/test/reports/` Verzeichnis gesucht. Um alle Dateien in einem Verzeichnis zu ignorieren, verwenden Sie das `**/*` Glob-Muster.

Im Folgenden finden Sie Beispiele für mögliche Glob-Muster.


| Muster | Description | 
| --- | --- | 
|  `*.*`  |  Entspricht allen Objektnamen im aktuellen Verzeichnis, die einen Punkt enthalten  | 
|  `*.xml`  |  Entspricht allen Objektnamen im aktuellen Verzeichnis, die mit enden `.xml`  | 
|  `*.{xml,txt}`  |  Entspricht allen Objektnamen im aktuellen Verzeichnis, die mit `.xml` oder enden `.txt`  | 
|  `**/*.xml`  |  Entspricht Objektnamen in allen Verzeichnissen, die mit enden `.xml`  | 
|  `testFolder`  |  Entspricht einem `testFolder` aufgerufenen Objekt und behandelt es als Datei  | 
|  `testFolder/*`  |  Entspricht Objekten auf einer Ebene des Unterordners von`testFolder`, wie zum Beispiel `testFolder/file.xml`  | 
|  `testFolder/*/*`  |  Entspricht Objekten auf zwei Ebenen des Unterordners von`testFolder`, wie z. B. `testFolder/reportsFolder/file.xml`  | 
|  `testFolder/**`  |  Entspricht dem Unterordner `testFolder` und Dateien unter `testFolder`, wie z. B. `testFolder/file.xml` und `testFolder/otherFolder/file.xml`  | 

CodeCatalyst interpretiert die Glob-Muster wie folgt:
+ Der Schrägstrich (`/`) trennt Verzeichnisse in Dateipfaden.
+ Das Sternchen (`*`) entspricht einem oder mehreren Zeichen einer Namenskomponente ohne Überschreiten der Ordnergrenzen.
+ Ein doppeltes Sternchen (`**`) steht für null oder mehr Zeichen einer Namenskomponente in allen Verzeichnissen.

**Anmerkung**  
`ExcludePaths`hat Vorrang vor. `IncludePaths` Wenn beide `IncludePaths` den gleichen Ordner `ExcludePaths` enthalten, wird dieser Ordner nicht nach Berichten durchsucht.

# Unterstützte SARIF-Eigenschaften
<a name="test.sarif"></a>

Das Static Analysis Results Interchange Format (SARIF) ist ein Ausgabedateiformat, das in Software Composition Analysis (SCA) und statischen Analyseberichten bei Amazon CodeCatalyst verfügbar ist. Das folgende Beispiel zeigt, wie SARIF in einem statischen Analysebericht manuell konfiguriert wird:

```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
    - output/sa_report.json
SuccessCriteria:
    StaticAnalysisFinding:
    Number: 25
    Severity: HIGH
```

CodeCatalyst unterstützt die folgenden SARIF-Eigenschaften, mit denen Sie die Darstellung der Analyseergebnisse in Ihren Berichten optimieren können.

**Topics**
+ [

## `sarifLog`-Objekt
](#test.sarif.sarifLog)
+ [

## `run`-Objekt
](#test.sarif.run)
+ [

## `toolComponent`-Objekt
](#test.sarif.toolComponent)
+ [

## `reportingDescriptor`-Objekt
](#test.sarif.reportingDescriptor)
+ [

## `result`-Objekt
](#test.sarif.result)
+ [

## `location`-Objekt
](#test.sarif.location)
+ [

## `physicalLocation`-Objekt
](#test.sarif.physicalLocation)
+ [

## `logicalLocation`-Objekt
](#test.sarif.logicalLocation)
+ [

## `fix`-Objekt
](#test.sarif.fix)

## `sarifLog`-Objekt
<a name="test.sarif.sarifLog"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `$schema`  |  Ja  |  [Die URI des SARIF-JSON-Schemas für Version 2.1.0.](https://json.schemastore.org/sarif-2.1.0.json)  | 
|  `version`  |  Ja  |  CodeCatalyst unterstützt nur SARIF Version 2.1.0.  | 
|  `runs[]`  |  Ja  |  Eine SARIF-Datei enthält ein Array von einem oder mehreren Durchläufen, von denen jeder einen einzelnen Lauf des Analysetools darstellt.  | 

## `run`-Objekt
<a name="test.sarif.run"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `tool.driver`  |  Ja  |  Ein `toolComponent` Objekt, das das Analysetool beschreibt.  | 
|  `tool.name`  |  Nein  |  Eine Eigenschaft, die den Namen des Tools angibt, das zur Durchführung der Analyse verwendet wird.  | 
|  `results[]`  |  Ja  |  Die Ergebnisse des Analysetools, die am angezeigt werden CodeCatalyst.  | 

## `toolComponent`-Objekt
<a name="test.sarif.toolComponent"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `name`  |  Ja  |  Der Name des Analysetools.  | 
|  `properties.artifactScanned`  |  Nein  |  Die Gesamtzahl der vom Tool analysierten Artefakte.  | 
|  `rules[]`  |  Ja  |  Eine Reihe von `reportingDescriptor` Objekten, die Regeln darstellen. Auf der Grundlage dieser Regeln findet das Analysetool Probleme im analysierten Code.  | 

## `reportingDescriptor`-Objekt
<a name="test.sarif.reportingDescriptor"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `id`  |  Ja  |  Die eindeutige Kennung für die Regel, die verwendet wird, um auf ein Ergebnis zu verweisen. Maximale Länge: 1.024 Zeichen  | 
|  `name`  |  Nein  |  Der Anzeigename der Regel. Maximale Länge: 1.024 Zeichen  | 
|  `shortDescription.text`  |  Nein  |  Eine verkürzte Beschreibung der Regel. Maximale Länge: 3.000 Zeichen  | 
|  `fullDescription.text`  |  Nein  |  Eine vollständige Beschreibung der Regel. Maximale Länge: 3.000 Zeichen  | 
|  `helpUri`  |  Nein  |  Eine Zeichenfolge, die so lokalisiert werden kann, dass sie den absoluten URI der Primärdokumentation für die Regel enthält. Maximale Länge: 3.000 Zeichen  | 
|  `properties.unscore`  |  Nein  |  Eine Markierung, die angibt, ob das Scan-Ergebnis bewertet wurde.  | 
|  `properties.score.severity`  |  Nein  |  Ein fester Satz von Zeichenketten, die den Schweregrad des Ergebnisses angeben. Maximale Länge: 1.024 Zeichen  | 
|  `properties.cvssv3_baseSeverity`  |  Nein  |  Eine qualitative Bewertung des Schweregrads des [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document).  | 
|  `properties.cvssv3_baseScore`  |  Nein  |  Ein CVSS v3-Basiswert im Bereich von [0,0 bis 10,0](https://nvd.nist.gov/vuln-metrics/cvss).  | 
|  `properties.cvssv2_severity`  |  Nein  |  Wenn CVSS v3-Werte nicht verfügbar sind, wird nach CVSS v2-Werten CodeCatalyst gesucht.  | 
|  `properties.cvssv2_score`  |  Nein  |  Ein CVSS v2-Basiswert im Bereich von [0,0 bis 10,0](https://nvd.nist.gov/vuln-metrics/cvss).  | 
|  `properties.severity`  |  Nein  |  Ein fester Satz von Zeichenketten, die den Schweregrad des Ergebnisses angeben. Maximale Länge: 1.024 Zeichen  | 
|  `defaultConfiguration.level`  |  Nein  |  Der Standardschweregrad einer Regel.  | 

## `result`-Objekt
<a name="test.sarif.result"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `ruleId`  |  Ja  |  Die eindeutige Kennung für die Regel, die verwendet wird, um auf ein Ergebnis zu verweisen. Maximale Länge: 1.024 Zeichen  | 
|  `ruleIndex`  |  Ja  |  Der Index der zugehörigen Regel in der Tool-Komponente`rules[]`.  | 
|  `message.text`  |  Ja  |  Eine Meldung, die das Ergebnis beschreibt und die Meldung für jedes Ergebnis anzeigt. Maximale Länge: 3.000 Zeichen  | 
|  `rank`  |  Nein  |  Ein Wert zwischen 0,0 und einschließlich 100,0, der die Priorität oder Wichtigkeit des Ergebnisses angibt. Auf dieser Skala steht der Wert 0,0 für die niedrigste Priorität und 100,0 für die höchste Priorität.  | 
|  `level`  |  Nein  |  Der Schweregrad des Ergebnisses. Maximale Länge: 1.024 Zeichen  | 
|  `properties.unscore`  |  Nein  |  Eine Markierung, die angibt, ob das Scanergebnis bewertet wurde.  | 
|  `properties.score.severity`  |  Nein  |  Ein fester Satz von Zeichenketten, die den Schweregrad des Ergebnisses angeben. Maximale Länge: 1.024 Zeichen  | 
|  `properties.cvssv3_baseSeverity`  |  Nein  |  Eine qualitative Bewertung des Schweregrads des [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document).  | 
|  `properties.cvssv3_baseScore`  |  Nein  |  Ein CVSS v3-Basiswert im Bereich von [0,0 bis 10,0](https://nvd.nist.gov/vuln-metrics/cvss).  | 
|  `properties.cvssv2_severity`  |  Nein  |  Wenn CVSS v3-Werte nicht verfügbar sind, wird nach CVSS v2-Werten CodeCatalyst gesucht.  | 
|  `properties.cvssv2_score`  |  Nein  |  Ein CVSS v2-Basiswert im Bereich von [0,0 bis 10,0](https://nvd.nist.gov/vuln-metrics/cvss).  | 
|  `properties.severity`  |  Nein  |  Ein fester Satz von Zeichenketten, die den Schweregrad des Ergebnisses angeben. Maximale Länge: 1.024 Zeichen  | 
|  `locations[]`  |  Ja  |  Die Gruppe von Orten, an denen das Ergebnis erkannt wurde. Es sollte nur ein Standort angegeben werden, es sei denn, das Problem kann nur behoben werden, indem an jeder angegebenen Position eine Änderung vorgenommen wird. CodeCatalyst verwendet den ersten Wert in der Ortsmatrix, um das Ergebnis mit Anmerkungen zu versehen. Maximale Anzahl von `location` Objekten: 10  | 
|  `relatedLocations[]`  |  Nein  |  Eine Liste zusätzlicher Ortsverweise im Ergebnis. Maximale Anzahl von `location` Objekten: 50  | 
|  `fixes[]`  |  Nein  |  Eine Reihe von `fix` Objekten, die der Empfehlung des Scan-Tools entsprechen. CodeCatalyst verwendet die erste Empfehlung im `fixes` Array.  | 

## `location`-Objekt
<a name="test.sarif.location"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `physicalLocation`  |  Ja  |  Identifiziert das Artefakt und die Region.  | 
|  `logicalLocations[]`  |  Nein  |  Die Gruppe von Orten, die namentlich ohne Bezugnahme auf das Artefakt beschrieben werden.  | 

## `physicalLocation`-Objekt
<a name="test.sarif.physicalLocation"></a>


| Name | Erforderlich | Beschreibung | 
| --- | --- | --- | 
|  `artifactLocation.uri`  |  Ja  |  Der URI, der den Speicherort eines Artefakts angibt, normalerweise eine Datei, die entweder im Repository oder während eines Builds generiert wurde.  | 
|  `fileLocation.uri`  |  Nein  |  Der Fallback-URI, der den Speicherort der Datei angibt. Dieser Wert wird verwendet, wenn er leer `artifactLocation.uri` zurückgegeben wird.  | 
|  `region.startLine`  |  Ja  |  Die Zeilennummer des ersten Zeichens in der Region.  | 
|  `region.startColumn`  |  Ja  |  Die Spaltennummer des ersten Zeichens in der Region.  | 
|  `region.endLine`  |  Ja  |  Die Zeilennummer des letzten Zeichens in der Region.  | 
|  `region.endColumn`  |  Ja  |  Die Spaltennummer des letzten Zeichens in der Region.  | 

## `logicalLocation`-Objekt
<a name="test.sarif.logicalLocation"></a>


| Name | Erforderlich | Description | 
| --- | --- | --- | 
|  `fullyQualifiedName`  |  Nein  |  Zusätzliche Informationen, die den Speicherort des Ergebnisses beschreiben. Maximale Länge: 1.024 Zeichen  | 

## `fix`-Objekt
<a name="test.sarif.fix"></a>


| Name | Erforderlich | Description | 
| --- | --- | --- | 
|  `description.text`  |  Nein  |  Eine Meldung, in der für jedes Ergebnis eine Empfehlung angezeigt wird. Maximale Länge: 3.000 Zeichen  | 
|  `artifactChanges.[0].artifactLocation.uri`  |  Nein  |  Die URI, die den Speicherort des Artefakts angibt, das aktualisiert werden muss.  | 

# Bereitstellung mit Workflows
<a name="deploy"></a>



Mithilfe von [CodeCatalyst Workflows](workflow.md) können Sie Anwendungen und andere Ressourcen für verschiedene Ziele wie Amazon ECS und mehr bereitstellen. AWS Lambda

## Wie stelle ich eine Anwendung bereit?
<a name="deploy-concepts"></a>

Um eine Anwendung oder Ressource bereitzustellen CodeCatalyst, erstellen Sie zunächst einen Workflow und geben dann darin eine Bereitstellungsaktion an. Eine *Bereitstellungsaktion* ist ein Workflow-Baustein, der definiert, *was* Sie bereitstellen möchten, *wo* Sie es bereitstellen möchten und *wie* Sie es bereitstellen möchten (z. B. mithilfe eines blue/green Schemas). Sie fügen Ihrem Workflow mithilfe des visuellen Editors oder YAML-Editors der CodeCatalyst Konsole eine Bereitstellungsaktion hinzu.

Die allgemeinen Schritte zur Bereitstellung einer Anwendung oder Ressource lauten wie folgt.

**So stellen Sie eine Anwendung bereit (Aufgaben auf hoher Ebene)**

1. In Ihrem CodeCatalyst Projekt **fügen Sie Quellcode** für eine Anwendung hinzu, die Sie bereitstellen möchten. Weitere Informationen finden Sie unter [Speichern von Quellcode in Repositorys für ein Projekt in CodeCatalyst](source-repositories.md).

1. In Ihrem CodeCatalyst Projekt **fügen Sie eine Umgebung** hinzu, die das Ziel AWS-Konto und die optionale Amazon Virtual Private Cloud (VPC) definiert, für die Sie die Bereitstellung durchführen möchten. Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).

1. In Ihrem CodeCatalyst Projekt **erstellen Sie einen Workflow**. In diesem Workflow definieren Sie, wie Ihre Anwendung erstellt, getestet und bereitgestellt werden soll. Weitere Informationen finden Sie unter [Erste Schritte mit Workflows](workflows-getting-started.md).

1. Im Workflow **fügen Sie einen Auslöser**, eine **Build-Aktion** und optional eine **Testaktion** hinzu. Weitere Informationen finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md), [Hinzufügen der Build-Aktion](build-add-action.md) und [Testaktion hinzufügen](test-add-action.md).

1. Im Workflow **fügen Sie eine Bereitstellungsaktion** hinzu. Sie können aus mehreren CodeCatalyst bereitgestellten Bereitstellungsaktionen für Ihre Anwendung für verschiedene Ziele wählen, z. B. Amazon ECS. (Sie können auch eine Build-Aktion oder eine GitHub Aktion verwenden, um Ihre Anwendung bereitzustellen. Weitere Informationen zur Build-Aktion und zu GitHub Aktionen finden Sie unter[Alternativen zur Bereitstellung von Aktionen](#deploy-concepts-alternatives).)

1. Sie **starten den Workflow** entweder manuell oder automatisch über einen Trigger. Der Workflow führt die Build-, Test- und Bereitstellungsaktionen nacheinander aus, um Ihre Anwendung und Ressourcen auf dem Ziel bereitzustellen. Weitere Informationen finden Sie unter [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).

## Liste der Bereitstellungsaktionen
<a name="deploy-concepts-action-supported"></a>

Die folgenden Bereitstellungsaktionen sind verfügbar:
+  CloudFormation Stack bereitstellen — Diese Aktion erstellt einen CloudFormation Stack auf der AWS Grundlage einer [CloudFormation Vorlage](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) oder [AWS Serverless Application Model Vorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html), die Sie bereitstellen. Weitere Informationen finden Sie unter [Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md).
+ In Amazon ECS bereitstellen — Diese Aktion registriert eine von Ihnen bereitgestellte [Aufgabendefinitionsdatei](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions). Weitere Informationen finden Sie unter [Bereitstellung auf Amazon ECS mit einem Workflow](deploy-action-ecs.md).
+ Auf Kubernetes-Cluster bereitstellen — Diese Aktion stellt eine Anwendung in einem Amazon Elastic Kubernetes Service Service-Cluster bereit. Weitere Informationen finden Sie unter [Bereitstellung auf Amazon EKS mit einem Workflow](deploy-action-eks.md).
+ AWS CDK [bereitstellen — Diese Aktion stellt eine App bereit in.AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_concepts) AWS Weitere Informationen finden Sie unter [Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.md).

**Anmerkung**  
Es gibt andere CodeCatalyst Aktionen, mit denen Ressourcen bereitgestellt werden können. Sie gelten jedoch nicht als *Bereitstellungsaktionen*, da ihre Bereitstellungsinformationen nicht auf der Seite **Umgebungen** angezeigt werden. Weitere Informationen zur Seite „**Umgebungen**“ und zum Anzeigen von Bereitstellungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Bereitstellungsinformationen anzeigen](deploy-view-deployment-info.md).

## Vorteile von Bereitstellungsaktionen
<a name="deploy-concepts-why-use"></a>

Die Verwendung von Bereitstellungsaktionen innerhalb eines Workflows hat die folgenden Vorteile:
+ **Bereitstellungsverlauf** — Sehen Sie sich einen Verlauf Ihrer Bereitstellungen an, um Änderungen an Ihrer bereitgestellten Software besser verwalten und kommunizieren zu können. 
+ **Rückverfolgbarkeit** — Verfolgen Sie den Status Ihrer Bereitstellungen über die CodeCatalyst Konsole und sehen Sie, wann und wo die einzelnen Anwendungsversionen bereitgestellt wurden.
+ **Rollbacks** — Machen Sie Bereitstellungen automatisch rückgängig, wenn Fehler auftreten. Sie können auch Alarme konfigurieren, um Bereitstellungs-Rollbacks zu aktivieren.
+ **Überwachung** — Beobachten Sie Ihre Implementierung, während sie die verschiedenen Phasen Ihres Workflows durchläuft.
+ **Integration mit anderen CodeCatalyst Funktionen** — Speichern Sie den Quellcode und erstellen, testen und implementieren Sie ihn — alles von einer einzigen Anwendung aus.

## Alternativen zur Bereitstellung von Aktionen
<a name="deploy-concepts-alternatives"></a>

Sie müssen keine Bereitstellungsaktionen verwenden, obwohl sie empfohlen werden, da sie die im vorherigen Abschnitt beschriebenen Vorteile bieten. Stattdessen können Sie die folgenden [CodeCatalyst Aktionen](workflows-actions.md#workflows-actions-types-cc) verwenden:
+ Eine **Build-Aktion**.

  In der Regel verwenden Sie Build-Aktionen, wenn Sie eine Bereitstellung auf einem Ziel durchführen möchten, für das es keine entsprechende Bereitstellungsaktion gibt, oder wenn Sie mehr Kontrolle über das Bereitstellungsverfahren haben möchten. Weitere Informationen zur Verwendung von Build-Aktionen zur Bereitstellung von Ressourcen finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).
+ Eine **GitHub Aktion**.

  Sie können eine [GitHub Aktion](workflows-actions.md#workflows-actions-types-github) innerhalb eines CodeCatalyst Workflows verwenden, um Anwendungen und Ressourcen bereitzustellen (anstelle einer CodeCatalyst Aktion). Informationen zur Verwendung von GitHub Aktionen innerhalb eines CodeCatalyst Workflows finden Sie unter [Integration mit GitHub Aktionen](integrations-github-actions.md)

Sie können auch die folgenden AWS Dienste verwenden, um Ihre Anwendung bereitzustellen, wenn Sie dafür keinen CodeCatalyst Workflow verwenden möchten:
+ AWS CodeDeploy — siehe [Was ist CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ AWS CodeBuild und AWS CodePipeline — siehe [Was ist AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) und [Was ist AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ CloudFormation — siehe [Was ist CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)

Verwenden Sie CodeDeploy CodeBuild, CodePipeline, und CloudFormation Services für komplexe Unternehmensbereitstellungen.

**Topics**
+ [

## Wie stelle ich eine Anwendung bereit?
](#deploy-concepts)
+ [

## Liste der Bereitstellungsaktionen
](#deploy-concepts-action-supported)
+ [

## Vorteile von Bereitstellungsaktionen
](#deploy-concepts-why-use)
+ [

## Alternativen zur Bereitstellung von Aktionen
](#deploy-concepts-alternatives)
+ [

# Bereitstellung auf Amazon ECS mit einem Workflow
](deploy-action-ecs.md)
+ [

# Bereitstellung auf Amazon EKS mit einem Workflow
](deploy-action-eks.md)
+ [

# Einen CloudFormation Stack bereitstellen
](deploy-action-cfn.md)
+ [

# Eine AWS CDK App mit einem Workflow bereitstellen
](cdk-dep-action.md)
+ [

# Bootstrapping einer AWS CDK App mit einem Workflow
](cdk-boot-action.md)
+ [

# Veröffentlichen von Dateien in Amazon S3 mit einem Workflow
](s3-pub-action.md)
+ [

# Einsatz in AWS-Konten und VPCs
](deploy-environments.md)
+ [

# Anzeige der App-URL im Workflow-Diagramm
](deploy-app-url.md)
+ [

# Ein Bereitstellungsziel entfernen
](deploy-remove-target.md)
+ [

# Verfolgen des Bereitstellungsstatus nach Commit
](track-changes.md)
+ [

# Bereitstellungsprotokolle anzeigen
](deploy-deployment-logs.md)
+ [

# Bereitstellungsinformationen anzeigen
](deploy-view-deployment-info.md)

# Bereitstellung auf Amazon ECS mit einem Workflow
<a name="deploy-action-ecs"></a>

In diesem Abschnitt wird beschrieben, wie eine containerisierte Anwendung mithilfe eines Workflows in einem Amazon Elastic Container Service-Cluster bereitgestellt wird. CodeCatalyst Um dies zu erreichen, müssen Sie Ihrem Workflow die Aktion **Deploy to Amazon ECS** hinzufügen. Diese Aktion registriert eine von Ihnen bereitgestellte [Aufgabendefinitionsdatei](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions). Nach der Registrierung wird die Aufgabendefinition von Ihrem [Amazon ECS-Service instanziiert, der in Ihrem [Amazon ECS-Cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) ausgeführt wird. Das „Instanziieren einer Aufgabendefinition“ entspricht der Bereitstellung einer Anwendung in Amazon ECS.

Um diese Aktion verwenden zu können, müssen Sie einen Amazon ECS-Cluster, einen Service und eine Aufgabendefinitionsdatei bereit haben.

Weitere Informationen zu Amazon ECS finden Sie im *Amazon Elastic Container Service Developer Guide*.

**Tipp**  
Ein Tutorial, das Ihnen zeigt, wie Sie die Aktion **Deploy to Amazon ECS** verwenden, finden Sie unter[Tutorial: Bereitstellen einer Anwendung in Amazon ECS](deploy-tut-ecs.md).

**Tipp**  
Um ein funktionierendes Beispiel für die Aktion **Deploy to Amazon ECS** zu erhalten, erstellen Sie ein Projekt entweder mit der **Node.js API mit AWS Fargate** oder der **Java-API mit AWS Fargate** Blueprint. Weitere Informationen finden Sie unter [Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template).

**Topics**
+ [

## Runtime-Image, das von der Aktion „In Amazon ECS bereitstellen“ verwendet wird
](#deploy-action-ecs-runtime)
+ [

# Tutorial: Bereitstellen einer Anwendung in Amazon ECS
](deploy-tut-ecs.md)
+ [

# Aktion „In Amazon ECS bereitstellen“ hinzufügen
](deploy-action-ecs-adding.md)
+ [

# Variablen „In Amazon ECS bereitstellen“
](deploy-action-ecs-variables.md)
+ [

# Aktion „In Amazon ECS bereitstellen“ YAML
](deploy-action-ref-ecs.md)

## Runtime-Image, das von der Aktion „In Amazon ECS bereitstellen“ verwendet wird
<a name="deploy-action-ecs-runtime"></a>

Die Aktion **Deploy to Amazon ECS** wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Tutorial: Bereitstellen einer Anwendung in Amazon ECS
<a name="deploy-tut-ecs"></a>

In diesem Tutorial erfahren Sie, wie Sie mithilfe eines Workflows, Amazon ECS und einiger anderer AWS Services eine serverlose Anwendung in Amazon Elastic Container Service (Amazon ECS) bereitstellen. Bei der bereitgestellten Anwendung handelt es sich um eine einfache Hello World-Website, die auf einem Docker-Image des Apache-Webservers basiert. Das Tutorial führt Sie durch die erforderlichen Vorbereitungsarbeiten, z. B. die Einrichtung eines Clusters, und beschreibt anschließend, wie Sie einen Workflow für die Erstellung und Bereitstellung der Anwendung erstellen.

**Tipp**  
Anstatt sich durch dieses Tutorial zu arbeiten, können Sie einen Blueprint verwenden, der ein vollständiges Amazon ECS-Setup für Sie durchführt. Sie müssen entweder die **Node.js API mit AWS Fargate oder die **Java API mit AWS Fargate**** Blueprint verwenden. Weitere Informationen finden Sie unter [Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template).

**Topics**
+ [

## Voraussetzungen
](#deploy-tut-ecs-prereqs)
+ [

## Schritt 1: Richten Sie einen AWS Benutzer ein und AWS CloudShell
](#deploy-tut-ecs-user-cloudshell)
+ [

## Schritt 2: Stellen Sie eine Platzhalteranwendung in Amazon ECS bereit
](#deploy-tut-ecs-placeholder)
+ [

## Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository
](#deploy-tut-ecs-ecr)
+ [

## Schritt 4: AWS Rollen erstellen
](#deploy-tut-ecs-build-deploy-roles)
+ [

## Schritt 5: AWS Rollen hinzufügen CodeCatalyst
](#deploy-tut-ecs-import-roles)
+ [

## Schritt 6: Erstellen Sie ein Quell-Repository
](#deploy-tut-ecs-source-repo)
+ [

## Schritt 7: Quelldateien hinzufügen
](#deploy-tut-ecs-source-files)
+ [

## Schritt 8: Erstellen Sie einen Workflow und führen Sie ihn aus
](#deploy-tut-ecs-workflow)
+ [

## Schritt 9: Nehmen Sie eine Änderung an Ihren Quelldateien vor
](#deploy-tut-ecs-change)
+ [

## Bereinigen
](#deploy-tut-ecs-cleanup)

## Voraussetzungen
<a name="deploy-tut-ecs-prereqs"></a>

Bevor Sie beginnen:
+ Sie benötigen einen CodeCatalyst **Bereich** mit einem verbundenen AWS Konto. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In Ihrem Bereich benötigen Sie ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-ecs-project
  ```

  Verwenden Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).
+ In Ihrem Projekt benötigen Sie eine CodeCatalyst **Umgebung** mit dem Namen:

  ```
  codecatalyst-ecs-environment
  ```

  Konfigurieren Sie diese Umgebung wie folgt:
  + Wählen Sie einen beliebigen Typ aus, z. B. „Keine **Produktion**“.
  + Connect dein AWS Konto damit.
  + Wählen Sie für die **Standard-IAM-Rolle eine** beliebige Rolle aus. Sie werden später eine andere Rolle angeben.

  Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).

## Schritt 1: Richten Sie einen AWS Benutzer ein und AWS CloudShell
<a name="deploy-tut-ecs-user-cloudshell"></a>

Der erste Schritt in diesem Tutorial besteht darin AWS IAM Identity Center, einen Benutzer zu erstellen und eine AWS CloudShell Instanz als dieser Benutzer zu starten. Für die Dauer dieses Tutorials CloudShell ist dies Ihr Entwicklungscomputer, auf dem Sie AWS Ressourcen und Dienste konfigurieren. Löschen Sie diesen Benutzer, nachdem Sie das Tutorial abgeschlossen haben.

**Anmerkung**  
Verwenden Sie für dieses Tutorial nicht Ihren Root-Benutzer. Sie müssen einen separaten Benutzer erstellen, da sonst später Probleme bei der Ausführung von Aktionen in der AWS Command Line Interface (CLI) auftreten können.

Weitere Informationen zu IAM Identity Center-Benutzern finden Sie im *AWS IAM Identity Center Benutzerhandbuch* und im *AWS CloudShell Benutzerhandbuch*. CloudShell 

**So erstellen Sie einen IAM Identity Center-Benutzer**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS IAM Identity Center Konsole unter [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/).
**Anmerkung**  
Stellen Sie sicher, dass Sie sich mit dem anmelden AWS-Konto , der mit Ihrem CodeCatalyst Bereich verbunden ist. Sie können überprüfen, welches Konto verbunden ist, indem Sie zu Ihrem Bereich navigieren und den Tab **AWS-Konten** auswählen. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).

1. Wählen Sie im Navigationsbereich **Users (Benutzer)** und dann **Add User (Benutzer hinzufügen)** aus.

1. Geben Sie im Feld **Nutzername** Folgendes ein:

   ```
   CodeCatalystECSUser
   ```

1. Wählen Sie unter **Passwort** die Option **Einmalpasswort generieren aus, das Sie mit diesem Benutzer teilen können**.

1. Geben Sie in den **Feldern **E-Mail-Adresse** und E-Mail-Adresse bestätigen** eine E-Mail-Adresse ein, die noch nicht in IAM Identity Center existiert.

1. Geben Sie in die Felder **Vorname** und **Nachname** Folgendes ein:

   ```
   CodeCatalystECSUser
   ```

1. Behalten Sie im Feld **Anzeigename** den automatisch generierten Namen bei:

   ```
   CodeCatalystECSUser CodeCatalystECSUser
   ```

1. Wählen Sie **Weiter** aus.

1. Wählen Sie auf der Seite „**Benutzer zu Gruppen hinzufügen**“ die Option **Weiter** aus.

1. Überprüfen Sie auf der Seite **Benutzer überprüfen und hinzufügen** die Informationen und wählen Sie **Benutzer hinzufügen** aus.

   Ein Dialogfeld mit einem **Einmalkennwort** wird angezeigt.

1. Wählen Sie **Kopieren** und fügen Sie dann die Anmeldeinformationen ein, einschließlich der URL des AWS Zugriffsportals und des Einmalkennworts.

1. Klicken Sie auf **Schließen**.

**So erstellen Sie einen Berechtigungssatz**

Sie weisen diesen Berechtigungssatz `CodeCatalystECSUser` später zu.

1. Wählen Sie im Navigationsbereich die Option **Berechtigungssätze** und dann **Berechtigungssatz erstellen** aus.

1. Wählen Sie **Vordefinierter Berechtigungssatz** und dann aus **AdministratorAccess**. Diese Richtlinie gewährt allen volle Berechtigungen AWS-Services. 

1. Wählen Sie **Weiter** aus.

1. Geben Sie im Feld **Name des Berechtigungssatzes** Folgendes ein:

   ```
   CodeCatalystECSPermissionSet
   ```

1. Wählen Sie **Weiter** aus.

1. **Überprüfen Sie auf der Seite Überprüfen und erstellen** die Informationen und wählen Sie **Erstellen** aus.

**Um den Berechtigungssatz zuzuweisen CodeCatalyst ECSUser**

1. Wählen Sie im Navigationsbereich das Kontrollkästchen neben dem aus **AWS-Konten**, bei dem Sie derzeit angemeldet sind AWS-Konto , und aktivieren Sie es anschließend.

1. Wählen Sie **Benutzer oder Gruppen zuweisen** aus.

1. Wählen Sie die Registerkarte **Users**.

1. Aktivieren Sie das Kontrollkästchen neben`CodeCatalystECSUser`.

1. Wählen Sie **Weiter** aus.

1. Aktivieren Sie das Kontrollkästchen neben`CodeCatalystECSPermissionSet`.

1. Wählen Sie **Weiter** aus.

1. Überprüfen Sie die Informationen und wählen Sie **Senden** aus.

   Sie haben sie nun `CodeCatalystECSPermissionSet` zugewiesen `CodeCatalystECSUser` und an Sie AWS-Konto gebunden.

**Um sich abzumelden und wieder anzumelden als CodeCatalyst ECSUser**

1. Bevor Sie sich abmelden, stellen Sie sicher, dass Sie die URL des AWS Zugriffsportals sowie den Benutzernamen und das Einmalpasswort für haben`CodeCatalystECSUser`. Sie hätten diese Informationen früher in einen Texteditor kopieren sollen.
**Anmerkung**  
Wenn Ihnen diese Informationen nicht vorliegen, rufen Sie die `CodeCatalystECSUser` Detailseite im IAM Identity Center auf und wählen Sie **Passwort zurücksetzen**, **Einmalpasswort generieren [...]** , und klicken **Sie erneut auf Passwort zurücksetzen**, um die Informationen auf dem Bildschirm anzuzeigen.

1. Melden Sie sich ab AWS.

1. Fügen Sie die URL des AWS Zugangsportals in die Adressleiste Ihres Browsers ein.

1. Melden Sie sich mit dem Benutzernamen und dem Einmalpasswort für an`CodeCatalystECSUser`.

1. Geben Sie **unter Neues Passwort** ein Passwort ein und wählen Sie **Neues Passwort festlegen** aus.

   Auf dem Bildschirm erscheint ein **AWS-Konto**Feld.

1. Wählen Sie **AWS-Konto**und wählen Sie dann den Namen des Benutzers und des AWS-Konto Berechtigungssatzes aus, dem Sie den `CodeCatalystECSUser` Benutzer zugewiesen haben.

1. Wählen Sie neben dem `CodeCatalystECSPermissionSet` die Option **Verwaltungskonsole** aus.

   Das AWS-Managementkonsole erscheint. Sie sind jetzt `CodeCatalystECSUser` mit den entsprechenden Berechtigungen angemeldet.

**Um eine AWS CloudShell Instance zu starten**

1. Wählen Sie wie `CodeCatalystECSUser` in der oberen Navigationsleiste das AWS Symbol (![\[AWS icon\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/deploy/aws-logo.png)).

   Die Hauptseite von wird AWS-Managementkonsole angezeigt.

1. Wählen Sie in der oberen Navigationsleiste das AWS CloudShell Symbol (![\[CloudShell icon\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/deploy/CloudShell.png)).

   CloudShell öffnet. Warten Sie, bis die CloudShell Umgebung erstellt ist.
**Anmerkung**  
Wenn Sie das CloudShell Symbol nicht sehen, vergewissern Sie sich, dass Sie sich in einer [Region befinden, die von unterstützt wird CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/faq-list.html#regions-available). In diesem Tutorial wird davon ausgegangen, dass Sie sich in der Region USA West (Oregon) befinden.

**Um zu überprüfen, ob der installiert AWS CLI ist**

1. Geben Sie im CloudShell Terminal Folgendes ein:

   ```
   aws --version
   ```

1. Vergewissern Sie sich, dass eine Version angezeigt wird.

   Der AWS CLI ist bereits für den aktuellen Benutzer konfiguriert`CodeCatalystECSUser`, sodass keine AWS CLI Schlüssel und Anmeldeinformationen konfiguriert werden müssen, wie dies normalerweise der Fall ist.

## Schritt 2: Stellen Sie eine Platzhalteranwendung in Amazon ECS bereit
<a name="deploy-tut-ecs-placeholder"></a>

In diesem Abschnitt stellen Sie manuell eine Platzhalteranwendung in Amazon ECS bereit. Diese Platzhalteranwendung wird durch die Hello World-Anwendung ersetzt, die in Ihrem Workflow bereitgestellt wird. Die Platzhalteranwendung ist Apache Web Server.

Weitere Informationen zu Amazon ECS finden Sie im *Amazon Elastic Container Service Developer Guide*.

Führen Sie die folgenden Schritte durch, um die Platzhalteranwendung bereitzustellen.<a name="deploy-tut-ecs-create-task-execution-role"></a>

**Um die Rolle zur Aufgabenausführung zu erstellen**

Diese Rolle gewährt Amazon ECS die AWS Fargate Erlaubnis, API-Aufrufe in Ihrem Namen durchzuführen. 

1. Erstellen Sie eine Vertrauensrichtlinie:

   1. Geben Sie in AWS CloudShell den folgenden Befehl ein:

      ```
      cat > codecatalyst-ecs-trust-policy.json
      ```

      Im CloudShell Terminal erscheint eine blinkende Aufforderung.

   1. Geben Sie an der Eingabeaufforderung den folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

------

   1. Platzieren Sie den Cursor hinter der letzten geschweiften Klammer (`}`).

   1. Drücken Sie dann **Enter** und**Ctrl\$1d**, um die Datei zu speichern und cat zu beenden.

1. Erstellen Sie eine Rolle zur Aufgabenausführung:

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-task-execution-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1. Hängen Sie die AWS verwaltete `AmazonECSTaskExecutionRolePolicy` Richtlinie an die Rolle an:

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-task-execution-role \
         --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
   ```

1. Zeigen Sie die Details der Rolle an:

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-task-execution-role
   ```

1. Notieren Sie sich den `"Arn":` Wert der Rolle, zum Beispiel`arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role`. Sie benötigen diesen Amazon-Ressourcennamen (ARN) später.

**Erstellen eines Amazon ECS-Clusters**

Dieser Cluster wird die Apache-Platzhalteranwendung und später die Hello World-Anwendung enthalten. 

1. Wie in `CodeCatalystECSUser` AWS CloudShell, erstellen Sie einen leeren Cluster:

   ```
   aws ecs create-cluster --cluster-name codecatalyst-ecs-cluster
   ```

1. (Optional) Stellen Sie sicher, dass der Cluster erfolgreich erstellt wurde:

   ```
   aws ecs list-clusters
   ```

   Der ARN des `codecatalyst-ecs-cluster` Clusters sollte in der Liste erscheinen, was auf eine erfolgreiche Erstellung hinweist.

**Um eine Aufgabendefinitionsdatei zu erstellen**

Die Aufgabendefinitionsdatei gibt an, dass das Docker-Image (`httpd:2.4`) des [Apache 2.4-Webservers](https://hub.docker.com/_/httpd) ausgeführt werden soll, von DockerHub dem abgerufen wird.

1. Wie in `CodeCatalystECSUser` AWS CloudShell, erstellen Sie eine Aufgabendefinitionsdatei:

   ```
   cat > taskdef.json
   ```

1. Fügen Sie den folgenden Code an der Eingabeaufforderung ein:

   ```
   {
       "executionRoleArn": "arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role",
       "containerDefinitions": [
           {
               "name": "codecatalyst-ecs-container",
               "image": "httpd:2.4",
               "essential": true,
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ]
           }
       ],
       "requiresCompatibilities": [
           "FARGATE"
       ],
       "cpu": "256",
       "family": "codecatalyst-ecs-task-def",
       "memory": "512",
       "networkMode": "awsvpc"
   }
   ```

   Ersetzen Sie im vorherigen Code *arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role*

   mit dem ARN der Aufgabenausführungsrolle, die Sie notiert haben[Um die Rolle zur Aufgabenausführung zu erstellen](#deploy-tut-ecs-create-task-execution-role).

1. Platzieren Sie den Cursor hinter der letzten geschweiften Klammer (`}`).

1. Drücken Sie dann **Enter** und**Ctrl\$1d**, um die Datei zu speichern und cat zu beenden.

**Um die Aufgabendefinitionsdatei bei Amazon ECS zu registrieren**

1. Wie in `CodeCatalystECSUser` AWS CloudShell, registrieren Sie die Aufgabendefinition:

   ```
   aws ecs register-task-definition \
       --cli-input-json file://taskdef.json
   ```

1. (Optional) Stellen Sie sicher, dass die Aufgabendefinition registriert wurde:

   ```
   aws ecs list-task-definitions
   ```

   Die `codecatalyst-ecs-task-def` Aufgabendefinition sollte in der Liste erscheinen.

**Um den Amazon ECS-Service zu erstellen**

Der Amazon ECS-Service führt die Aufgaben (und die zugehörigen Docker-Container) der Apache-Platzhalteranwendung und später der Hello World-Anwendung aus.

1. Wechseln Sie außerdem zur Amazon Elastic Container Service-Konsole, falls Sie dies noch nicht getan haben. `CodeCatalystECSUser`

1. Wählen Sie den Cluster aus, den Sie zuvor erstellt haben,`codecatalyst-ecs-cluster`.

1. Wählen Sie auf der Registerkarte **Dienste** die Option **Erstellen** aus.

1. Gehen Sie auf der Seite **Erstellen** wie folgt vor:

   1. Behalten Sie alle Standardeinstellungen mit Ausnahme der im Folgenden aufgeführten bei.

   1. Wählen Sie unter **Launch type (Starttyp)** **FARGATE** aus.

   1. Wählen Sie unter **Aufgabendefinition** in der Dropdownliste **Familie** die folgenden Optionen aus:

      `codecatalyst-ecs-task-def`

   1. Geben Sie als **Dienstname** Folgendes ein:

      ```
      codecatalyst-ecs-service
      ```

   1. Geben Sie für **Gewünschte Aufgaben** Folgendes ein:

      ```
      3
      ```

      In diesem Tutorial startet jede Aufgabe einen einzelnen Docker-Container.

   1. Erweitern Sie den Bereich **Netzwerk**.

   1. Wählen Sie für **VPC** eine beliebige VPC aus.

   1. Wählen Sie für **Subnetze** ein beliebiges Subnetz aus.
**Anmerkung**  
Geben Sie nur ein Subnetz an. Das ist alles, was für dieses Tutorial benötigt wird.
**Anmerkung**  
Wenn Sie keine VPC und kein Subnetz haben, erstellen Sie sie. Weitere Informationen finden [Sie unter Erstellen einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) und [Erstellen eines Subnetzes in Ihrer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet) im *Amazon VPC-Benutzerhandbuch*.

   1. Wählen Sie für **Sicherheitsgruppe** die Option **Create a new security group** aus und gehen Sie dann wie folgt vor:

      1. Geben Sie als **Namen der Sicherheitsgruppe** Folgendes ein:

         ```
         codecatalyst-ecs-security-group
         ```

      1. Geben Sie als **Beschreibung der Sicherheitsgruppe** Folgendes ein:

         ```
         CodeCatalyst ECS security group
         ```

      1. Wählen Sie **Regel hinzufügen** aus. Wählen Sie für **Typ** die Option **HTTP** und für **Quelle** die Option **Anywhere** aus.

   1. Wählen Sie unten **Create** aus.

   1. Warten Sie, bis der Dienst erstellt wurde. Dies kann einige Minuten dauern.

1. Wählen Sie die Registerkarte **Aufgaben** und dann die Schaltfläche „Aktualisieren“. Vergewissern Sie sich, dass die Spalte **Letzter Status** für alle drei Aufgaben auf Wird **ausgeführt** gesetzt ist.

**(Optional) Um zu überprüfen, ob Ihre Apache-Platzhalteranwendung ausgeführt wird**

1. Wählen Sie auf der Registerkarte **Aufgaben** eine der drei Aufgaben aus.

1. Wählen Sie im Feld **Öffentliche IP** die Option **Open Address** aus.

   Eine `It Works!` Seite wird angezeigt. Dies weist darauf hin, dass der Amazon ECS-Service erfolgreich eine Aufgabe gestartet hat, die einen Docker-Container mit dem Apache-Image gestartet hat.

   An dieser Stelle des Tutorials haben Sie manuell einen Amazon ECS-Cluster, eine Service- und Aufgabendefinition sowie eine Apache-Platzhalteranwendung bereitgestellt. Nachdem Sie all diese Elemente eingerichtet haben, sind Sie nun bereit, einen Workflow zu erstellen, der die Apache-Platzhalteranwendung durch die Hello World-Anwendung des Tutorials ersetzt.

## Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository
<a name="deploy-tut-ecs-ecr"></a>

In diesem Abschnitt erstellen Sie ein privates Image-Repository in Amazon Elastic Container Registry (Amazon ECR). In diesem Repository wird das Docker-Image des Tutorials gespeichert, das das zuvor bereitgestellte Apache-Platzhalter-Image ersetzt. 

Weitere Informationen zu Amazon ECR finden Sie im *Amazon Elastic Container Registry User Guide*.

**Um ein Bild-Repository in Amazon ECR zu erstellen**

1. Wie in `CodeCatalystECSUser` AWS CloudShell, ein leeres Repository in Amazon ECR erstellen:

   ```
   aws ecr create-repository --repository-name codecatalyst-ecs-image-repo
   ```

1. Zeigen Sie die Details des Amazon ECR-Repositorys an:

   ```
   aws ecr describe-repositories \
         --repository-names codecatalyst-ecs-image-repo
   ```

1. Notieren Sie sich den `“repositoryUri”:` Wert, zum Beispiel. `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`

   Sie benötigen ihn später, wenn Sie das Repository zu Ihrem Workflow hinzufügen. 

## Schritt 4: AWS Rollen erstellen
<a name="deploy-tut-ecs-build-deploy-roles"></a>

In diesem Abschnitt erstellen Sie AWS IAM-Rollen, die Ihr CodeCatalyst Workflow benötigt, um zu funktionieren. Diese Rollen sind:
+ **Build-Rolle** — Erteilt der CodeCatalyst Build-Aktion (im Workflow) die Berechtigung, auf Ihr AWS Konto zuzugreifen und in Amazon ECR und Amazon EC2 zu schreiben.
+ **Rolle bereitstellen** — Erteilt der Aktion CodeCatalyst **Deploy to ECS** (im Workflow) die Berechtigung, auf Ihr AWS Konto, Amazon ECS und einige andere AWS Services zuzugreifen.

Weitere Informationen zu IAM-Rollen finden Sie unter [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) im *AWS Identity and Access Management Benutzerhandbuch*.

**Anmerkung**  
Um Zeit zu sparen, können Sie anstelle der beiden zuvor aufgeführten Rollen eine einzelne `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle, die so genannte Rolle, erstellen. Weitere Informationen finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über sehr umfangreiche Berechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. In diesem Tutorial wird davon ausgegangen, dass Sie die beiden zuvor aufgeführten Rollen erstellen.

Um die Build- und Deploy-Rollen zu erstellen, können Sie entweder die AWS-Managementkonsole oder die verwenden AWS CLI.

------
#### [ AWS-Managementkonsole ]

Gehen Sie wie folgt vor, um die Build- und Deploy-Rollen zu erstellen.

**Um eine Build-Rolle zu erstellen**

1. Erstellen Sie wie folgt eine Richtlinie für die Rolle:

   1. Melden Sie sich an bei AWS.

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Wählen Sie im Navigationsbereich **Richtlinien**.

   1. Wählen Sie **Richtlinie erstellen** aus.

   1. Wählen Sie den Tab **JSON**.

   1. Löschen Sie den vorhandenen Code.

   1. Fügen Sie folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ecr:*",
                      "ec2:*"
                  ],
                  "Resource": "*"
              }
          ]
      }
      ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.

   1. Klicken Sie auf **Weiter: Prüfen**.

   1. Geben Sie im Feld **Name** Folgendes ein:

      ```
      codecatalyst-ecs-build-policy
      ```

   1. Wählen Sie **Richtlinie erstellen** aus.

      Sie haben jetzt eine Berechtigungsrichtlinie erstellt.

1. Erstellen Sie die Build-Rolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.

   1. Wählen Sie **Benutzerdefinierte Vertrauensrichtlinie**.

   1. Löschen Sie die bestehende benutzerdefinierte Vertrauensrichtlinie.

   1. Fügen Sie die folgende benutzerdefinierte Vertrauensrichtlinie hinzu:

   1. Wählen Sie **Weiter** aus.

   1. Suchen Sie **unter Berechtigungsrichtlinien** nach `codecatalyst-ecs-build-policy` und aktivieren Sie das entsprechende Kontrollkästchen.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-ecs-build-role
      ```

   1. Geben Sie **als Rollenbeschreibung** Folgendes ein:

      ```
      CodeCatalyst ECS build role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

   Sie haben jetzt eine Build-Rolle mit einer Berechtigungsrichtlinie und einer Vertrauensrichtlinie erstellt.

1. Rufen Sie den ARN für die Build-Rolle wie folgt ab:

   1. Wählen Sie im Navigationsbereich **Rollen**.

   1. Geben Sie im Suchfeld den Namen der Rolle ein, die Sie gerade erstellt haben (`codecatalyst-ecs-build-role`).

   1. Wählen Sie die Rolle aus der Liste aus.

      Die **Übersichtsseite** der Rolle wird angezeigt.

   1. Kopieren Sie oben den **ARN-Wert**. Sie benötigen sie später.

**Um eine Bereitstellungsrolle zu erstellen**

1. Erstellen Sie wie folgt eine Richtlinie für die Rolle:

   1. Melden Sie sich an bei AWS.

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Wählen Sie im Navigationsbereich **Richtlinien**.

   1. Wählen Sie **Richtlinie erstellen** aus.

   1. Wählen Sie den Tab **JSON**.

   1. Löschen Sie den vorhandenen Code.

   1. Fügen Sie folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [{
          "Action":[
            "ecs:DescribeServices",
            "ecs:CreateTaskSet",
            "ecs:DeleteTaskSet",
            "ecs:ListClusters",
            "ecs:RegisterTaskDefinition",
            "ecs:UpdateServicePrimaryTaskSet",
            "ecs:UpdateService",
            "elasticloadbalancing:DescribeTargetGroups",
            "elasticloadbalancing:DescribeListeners",
            "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:DescribeRules",
            "elasticloadbalancing:ModifyRule",
            "lambda:InvokeFunction",
            "lambda:ListFunctions",
            "cloudwatch:DescribeAlarms",
            "sns:Publish",
            "sns:ListTopics", 
            "s3:GetObject",
            "s3:GetObjectVersion",
            "codedeploy:CreateApplication", 
            "codedeploy:CreateDeployment", 
            "codedeploy:CreateDeploymentGroup", 
            "codedeploy:GetApplication", 
            "codedeploy:GetDeployment", 
            "codedeploy:GetDeploymentGroup", 
            "codedeploy:ListApplications", 
            "codedeploy:ListDeploymentGroups", 
            "codedeploy:ListDeployments", 
            "codedeploy:StopDeployment", 
            "codedeploy:GetDeploymentTarget", 
            "codedeploy:ListDeploymentTargets", 
            "codedeploy:GetDeploymentConfig", 
            "codedeploy:GetApplicationRevision", 
            "codedeploy:RegisterApplicationRevision", 
            "codedeploy:BatchGetApplicationRevisions", 
            "codedeploy:BatchGetDeploymentGroups", 
            "codedeploy:BatchGetDeployments", 
            "codedeploy:BatchGetApplications", 
            "codedeploy:ListApplicationRevisions", 
            "codedeploy:ListDeploymentConfigs", 
            "codedeploy:ContinueDeployment"           
         ],
         "Resource":"*",
         "Effect":"Allow"
      },{"Action":[
            "iam:PassRole"
         ],
         "Effect":"Allow",
         "Resource":"*",
         "Condition":{"StringLike":{"iam:PassedToService":[
                  "ecs-tasks.amazonaws.com",
                  "codedeploy.amazonaws.com"
               ]
            }
         }
      }]
      }
      ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung. Sie können die Richtlinie dann anhand des Ressourcennamens einschränken, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.

   1. Klicken Sie auf **Weiter: Prüfen**.

   1. Geben Sie im Feld **Name** Folgendes ein:

      ```
      codecatalyst-ecs-deploy-policy
      ```

   1. Wählen Sie **Richtlinie erstellen** aus.

      Sie haben jetzt eine Berechtigungsrichtlinie erstellt.

1. Erstellen Sie die Bereitstellungsrolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.

   1. Wählen Sie **Benutzerdefinierte Vertrauensrichtlinie**.

   1. Löschen Sie die bestehende benutzerdefinierte Vertrauensrichtlinie.

   1. Fügen Sie die folgende benutzerdefinierte Vertrauensrichtlinie hinzu:

   1. Wählen Sie **Weiter** aus.

   1. Suchen Sie **unter Berechtigungsrichtlinien** nach `codecatalyst-ecs-deploy-policy` und aktivieren Sie das entsprechende Kontrollkästchen.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-ecs-deploy-role
      ```

   1. Geben Sie **als Rollenbeschreibung** Folgendes ein:

      ```
      CodeCatalyst ECS deploy role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

   Sie haben jetzt eine Bereitstellungsrolle mit einer Vertrauensrichtlinie erstellt.

1. Rufen Sie den ARN für die Bereitstellungsrolle wie folgt ab:

   1. Wählen Sie im Navigationsbereich **Rollen**.

   1. Geben Sie im Suchfeld den Namen der Rolle ein, die Sie gerade erstellt haben (`codecatalyst-ecs-deploy-role`).

   1. Wählen Sie die Rolle aus der Liste aus.

      Die **Übersichtsseite** der Rolle wird angezeigt.

   1. Kopieren Sie oben den **ARN-Wert**. Sie benötigen sie später.

------
#### [ AWS CLI ]

Führen Sie die folgenden Verfahren aus, um die Build- und Deploy-Rollen zu erstellen.

**Um eine Vertrauensrichtlinie für beide Rollen zu erstellen**

Wie in `CodeCatalystECSUser` AWS CloudShell, erstellen Sie eine Vertrauensrichtliniendatei:

1. Erstellen Sie die Datei:

   ```
   cat > codecatalyst-ecs-trust-policy.json
   ```

1. Fügen Sie an der Terminal-Eingabeaufforderung den folgenden Code ein:

1. Platzieren Sie den Cursor hinter der letzten geschweiften Klammer (`}`).

1. Drücken Sie dann **Enter** und**Ctrl\$1d**, um die Datei zu speichern und cat zu beenden.

**Um die Build-Richtlinie und die Build-Rolle zu erstellen**

1. Erstellen Sie die Build-Richtlinie:

   1. Wie in `CodeCatalystECSUser` AWS CloudShell, erstellen Sie eine Build-Richtliniendatei:

      ```
      cat > codecatalyst-ecs-build-policy.json
      ```

   1. Geben Sie an der Eingabeaufforderung den folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ecr:*",
                      "ec2:*"
                  ],
                  "Resource": "*"
              }
          ]
      }
      ```

------

   1. Platzieren Sie den Cursor hinter der letzten geschweiften Klammer (`}`).

   1. Drücken Sie dann **Enter** und**Ctrl\$1d**, um die Datei zu speichern und cat zu beenden.

1. Fügen Sie die Build-Richtlinie hinzu zu AWS:

   ```
   aws iam create-policy \
       --policy-name codecatalyst-ecs-build-policy \
       --policy-document file://codecatalyst-ecs-build-policy.json
   ```

1. Notieren Sie sich in der Befehlsausgabe den `"arn":` Wert, zum Beispiel`arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy`. Sie benötigen diesen ARN später.

1. Erstellen Sie die Build-Rolle und fügen Sie ihr die Vertrauensrichtlinie hinzu:

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-build-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1. Hängen Sie die Build-Richtlinie an die Build-Rolle an:

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-build-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy
   ```

   Wo *arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy* wird durch den ARN der Build-Richtlinie ersetzt, die Sie zuvor notiert haben.

1. Zeigen Sie die Details der Build-Rolle an:

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-build-role
   ```

1. Notieren Sie sich den `"Arn":` Wert der Rolle, zum Beispiel`arn:aws:iam::111122223333:role/codecatalyst-ecs-build-role`. Sie benötigen diesen ARN später.

**Um die Bereitstellungsrichtlinie und die Bereitstellungsrolle zu erstellen**

1. Erstellen Sie eine Bereitstellungsrichtlinie:

   1. Erstellen Sie AWS CloudShell unter eine Bereitstellungsrichtliniendatei:

      ```
      cat > codecatalyst-ecs-deploy-policy.json
      ```

   1. Geben Sie an der Eingabeaufforderung den folgenden Code ein:

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [{
          "Action":[
            "ecs:DescribeServices",
            "ecs:CreateTaskSet",
            "ecs:DeleteTaskSet",
            "ecs:ListClusters",
            "ecs:RegisterTaskDefinition",
            "ecs:UpdateServicePrimaryTaskSet",
            "ecs:UpdateService",
            "elasticloadbalancing:DescribeTargetGroups",
            "elasticloadbalancing:DescribeListeners",
            "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:DescribeRules",
            "elasticloadbalancing:ModifyRule",
            "lambda:InvokeFunction",
            "lambda:ListFunctions",
            "cloudwatch:DescribeAlarms",
            "sns:Publish",
            "sns:ListTopics", 
            "s3:GetObject",
            "s3:GetObjectVersion",
            "codedeploy:CreateApplication", 
            "codedeploy:CreateDeployment", 
            "codedeploy:CreateDeploymentGroup", 
            "codedeploy:GetApplication", 
            "codedeploy:GetDeployment", 
            "codedeploy:GetDeploymentGroup", 
            "codedeploy:ListApplications", 
            "codedeploy:ListDeploymentGroups", 
            "codedeploy:ListDeployments", 
            "codedeploy:StopDeployment", 
            "codedeploy:GetDeploymentTarget", 
            "codedeploy:ListDeploymentTargets", 
            "codedeploy:GetDeploymentConfig", 
            "codedeploy:GetApplicationRevision", 
            "codedeploy:RegisterApplicationRevision", 
            "codedeploy:BatchGetApplicationRevisions", 
            "codedeploy:BatchGetDeploymentGroups", 
            "codedeploy:BatchGetDeployments", 
            "codedeploy:BatchGetApplications", 
            "codedeploy:ListApplicationRevisions", 
            "codedeploy:ListDeploymentConfigs", 
            "codedeploy:ContinueDeployment"           
         ],
         "Resource":"*",
         "Effect":"Allow"
      },{"Action":[
            "iam:PassRole"
         ],
         "Effect":"Allow",
         "Resource":"*",
         "Condition":{"StringLike":{"iam:PassedToService":[
                  "ecs-tasks.amazonaws.com",
                  "codedeploy.amazonaws.com"
               ]
            }
         }
      }]
      }
      ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Platzieren Sie den Cursor hinter der letzten geschweiften Klammer ()`}`.

   1. Drücken Sie dann **Enter** und**Ctrl\$1d**, um die Datei zu speichern und cat zu beenden.

1. Fügen Sie die Bereitstellungsrichtlinie hinzu zu AWS:

   ```
   aws iam create-policy \
       --policy-name codecatalyst-ecs-deploy-policy \
       --policy-document file://codecatalyst-ecs-deploy-policy.json
   ```

1. Notieren Sie sich in der Befehlsausgabe den `"arn":` Wert der Bereitstellungsrichtlinie, `arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy` z. B. Sie benötigen diesen ARN später.

1. Erstellen Sie die Bereitstellungsrolle und fügen Sie ihr die Vertrauensrichtlinie hinzu:

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-deploy-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1. Hängen Sie die Bereitstellungsrichtlinie an die Bereitstellungsrolle an, wo sie durch den ARN der Bereitstellungsrichtlinie ersetzt *arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy* wird, die Sie zuvor notiert haben.

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-deploy-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy
   ```

1. Zeigen Sie die Details der Bereitstellungsrolle an:

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-deploy-role
   ```

1. Notieren Sie sich den `"Arn":` Wert der Rolle, zum Beispiel`arn:aws:iam::111122223333:role/codecatalyst-ecs-deploy-role`. Sie benötigen diesen ARN später.

------

## Schritt 5: AWS Rollen hinzufügen CodeCatalyst
<a name="deploy-tut-ecs-import-roles"></a>

In diesem Schritt fügen Sie der CodeCatalyst Kontoverbindung in Ihrem Bereich die Build-Rolle (`codecatalyst-ecs-build-role``codecatalyst-ecs-deploy-role`) und die Bereitstellungsrolle () hinzu.

**Um deiner Kontoverbindung Rollen zum Erstellen und Bereitstellen hinzuzufügen**

1. Navigieren CodeCatalyst Sie darin zu Ihrem Bereich.

1. Wählen Sie **AWS accounts (-Konten)**. Eine Liste der Kontoverbindungen wird angezeigt.

1. Wählen Sie die Kontoverbindung aus, die dem AWS Konto entspricht, in dem Sie Ihre Build- und Deploy-Rollen erstellt haben.

1. Wählen Sie in der ** AWS Managementkonsole die Option Rollen verwalten aus**.

   Die Seite „**IAM-Rolle zu Amazon CodeCatalyst Space hinzufügen**“ wird angezeigt. Möglicherweise müssen Sie sich anmelden, um auf die Seite zuzugreifen.

1. Wählen Sie **Eine bestehende Rolle hinzufügen, die Sie in IAM erstellt haben**.

   Eine Dropdownliste wird angezeigt. In der Liste werden alle IAM-Rollen mit einer Vertrauensrichtlinie angezeigt, die die Dienstprinzipale `codecatalyst-runner.amazonaws.com` und die `codecatalyst.amazonaws.com` Dienstprinzipale umfasst.

1. Wählen Sie `codecatalyst-ecs-build-role` in der Dropdownliste die Option Rolle **hinzufügen** aus.
**Anmerkung**  
Wenn Sie das sehen`The security token included in the request is invalid`, liegt es möglicherweise daran, dass Sie nicht über die richtigen Berechtigungen verfügen. Um dieses Problem zu beheben, melden Sie sich ab und melden Sie sich mit dem AWS Konto wieder an, das Sie bei der Erstellung Ihres CodeCatalyst Bereichs verwendet haben. AWS 

1. Wählen Sie „**IAM-Rolle hinzufügen**“, wählen Sie „**Eine bestehende Rolle hinzufügen, die Sie in IAM erstellt haben**“ und wählen Sie in der Drop-down-Liste die Option aus. `codecatalyst-ecs-deploy-role` Wählen Sie **Rolle hinzufügen** aus.

   Sie haben jetzt die Build- und Deploy-Rollen zu Ihrem Bereich hinzugefügt.

1. Kopieren Sie den Wert des ** CodeCatalyst Amazon-Anzeigenamens**. Sie benötigen diesen Wert später, wenn Sie Ihren Workflow erstellen.

## Schritt 6: Erstellen Sie ein Quell-Repository
<a name="deploy-tut-ecs-source-repo"></a>

In diesem Schritt erstellen Sie ein Quell-Repository in CodeCatalyst. In diesem Repository werden die Quelldateien des Tutorials gespeichert, z. B. die Aufgabendefinitionsdatei.

Weitere Informationen zu Quell-Repositorys finden Sie unter[Erstellen eines Quell-Repositorys](source-repositories-create.md).

**Um ein Quell-Repository zu erstellen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Navigieren Sie zu Ihrem Projekt,`codecatalyst-ecs-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus. 

1. Wählen **Sie Repository hinzufügen** und anschließend **Repository erstellen** aus.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   codecatalyst-ecs-source-repository
   ```

1. Wählen Sie **Erstellen** aus.

## Schritt 7: Quelldateien hinzufügen
<a name="deploy-tut-ecs-source-files"></a>

In diesem Abschnitt fügen Sie die Hello World-Quelldateien zu Ihrem CodeCatalyst Repository hinzu. `codecatalyst-ecs-source-repository` Sie bestehen aus:
+ Eine `index.html` Datei — Zeigt eine Hello World-Nachricht im Browser an. 
+ Ein Dockerfile — Beschreibt das Basis-Image, das für Ihr Docker-Image verwendet werden soll, und die Docker-Befehle, die darauf angewendet werden sollen. 
+ Eine `taskdef.json` Datei — Definiert das Docker-Image, das beim Starten von Aufgaben in Ihrem Cluster verwendet werden soll.

Die Ordnerstruktur sieht wie folgt aus:

```
.
|— public-html
|  |— index.html
|— Dockerfile
|— taskdef.json
```

**Anmerkung**  
Die folgenden Anweisungen zeigen Ihnen, wie Sie die Dateien mithilfe der CodeCatalyst Konsole hinzufügen. Sie können jedoch auch Git verwenden, wenn Sie dies bevorzugen. Details hierzu finden Sie unter [Klonen eines Quell-Repositorys](source-repositories-clone.md). 

**Topics**
+ [

### index.html
](#deploy-tut-ecs-source-files-index)
+ [

### Dockerfile
](#deploy-tut-ecs-source-files-dockerfile)
+ [

### taskdef.json
](#deploy-tut-ecs-source-files-taskdef)

### index.html
<a name="deploy-tut-ecs-source-files-index"></a>

Die `index.html` Datei zeigt im Browser eine Hello World-Nachricht an. 

**Um die Datei index.html hinzuzufügen**

1. Gehen Sie in der CodeCatalyst Konsole zu Ihrem Quell-Repository,`codecatalyst-ecs-source-repository`.

1. Wählen Sie **unter Dateien** die Option **Datei erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   public-html/index.html
   ```
**Wichtig**  
Stellen Sie sicher, dass Sie das `public-html/` Präfix angeben, um einen Ordner mit demselben Namen zu erstellen. Das `index.html` wird sich voraussichtlich in diesem Ordner befinden.

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   <html>
     <head>
       <title>Hello World</title>
       <style>
         body {
         background-color: black;
         text-align: center;
         color: white;
         font-family: Arial, Helvetica, sans-serif;
         }  
       </style>
     </head>
     <body>
       <h1>Hello World</h1>
     </body>
   </html>
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Das `index.html` wird Ihrem Repository in einem `public-html` Ordner hinzugefügt. 

### Dockerfile
<a name="deploy-tut-ecs-source-files-dockerfile"></a>

Das Dockerfile beschreibt das zu verwendende Basis-Decker-Image und die darauf anzuwendenden Docker-Befehle. [Weitere Informationen zum Dockerfile finden Sie in der Dockerfile-Referenz.](https://docs.docker.com/engine/reference/builder/)

Das hier angegebene Dockerfile gibt an, das Apache 2.4-Basisimage () zu verwenden. `httpd` Es enthält auch Anweisungen zum Kopieren einer `index.html` aufgerufenen Quelldatei in einen Ordner auf dem Apache-Server, der Webseiten bereitstellt. Die `EXPOSE` Anweisung in der Dockerfile teilt Docker mit, dass der Container auf Port 80 lauscht.

**Um das Dockerfile hinzuzufügen**

1. Wählen Sie in Ihrem Quell-Repository die Option Datei **erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   Dockerfile
   ```

   Geben Sie keine Dateierweiterung an.
**Wichtig**  
Das Dockerfile muss sich im Stammordner Ihres Repositorys befinden. Der `Docker build` Befehl des Workflows erwartet, dass es dort vorhanden ist.

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   FROM httpd:2.4
   COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
   EXPOSE 80
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Das Dockerfile wird Ihrem Repository hinzugefügt. 

### taskdef.json
<a name="deploy-tut-ecs-source-files-taskdef"></a>

Die `taskdef.json` Datei, die Sie in diesem Schritt hinzufügen, ist dieselbe wie die, in der Sie bereits angegeben haben, [Schritt 2: Stellen Sie eine Platzhalteranwendung in Amazon ECS bereit](#deploy-tut-ecs-placeholder) mit dem folgenden Unterschied:

Anstatt einen fest codierten Docker-Imagenamen im `image:` Feld (`httpd:2.4`) anzugeben, verwendet die Aufgabendefinition hier einige Variablen, um das Bild zu bezeichnen: und. `$REPOSITORY_URI` `$IMAGE_TAG` Diese Variablen werden durch echte Werte ersetzt, die durch die Build-Aktion des Workflows generiert wurden, wenn Sie den Workflow in einem späteren Schritt ausführen.

Einzelheiten zu den Aufgabendefinitionsparametern finden Sie unter [Aufgabendefinitionsparameter](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) im *Amazon Elastic Container Service Developer Guide*.

**Um die Datei taskdef.json hinzuzufügen**

1. **Wählen Sie in Ihrem Quell-Repository die Option Datei erstellen aus.**

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   taskdef.json
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   {
       "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
       "containerDefinitions": [
           {
               "name": "codecatalyst-ecs-container",
               # The $REPOSITORY_URI and $IMAGE_TAG variables will be replaced 
               # by the workflow at build time (see the build action in the 
               # workflow)
               "image": $REPOSITORY_URI:$IMAGE_TAG,
               "essential": true,
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ]
           }
       ],
       "requiresCompatibilities": [
           "FARGATE"
       ],
       "networkMode": "awsvpc",
       "cpu": "256",
       "memory": "512",
       "family": "codecatalyst-ecs-task-def"
   }
   ```

   Ersetzen Sie im vorherigen Code

   *arn:aws:iam::account\$1ID:role/codecatalyst-ecs-task-execution-role*

   mit dem ARN der Aufgabenausführungsrolle, die Sie notiert haben[Um die Rolle zur Aufgabenausführung zu erstellen](#deploy-tut-ecs-create-task-execution-role).

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Die `taskdef.json` Datei wird Ihrem Repository hinzugefügt. 

## Schritt 8: Erstellen Sie einen Workflow und führen Sie ihn aus
<a name="deploy-tut-ecs-workflow"></a>

In diesem Schritt erstellen Sie einen Workflow, der Ihre Quelldateien zu einem Docker-Image zusammenbaut und das Image dann in Ihrem Amazon ECS-Cluster bereitstellt. Diese Bereitstellung ersetzt die bestehende Apache-Platzhalteranwendung.

Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein Trigger — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine Build-Aktion (`BuildBackend`) — Beim Auslösen erstellt die Aktion das Docker-Image mithilfe der Dockerfile und überträgt das Image an Amazon ECR. Die Build-Aktion aktualisiert auch das `taskdef.json` mit dem richtigen `image` Feldwert und erstellt dann ein Ausgabeartefakt dieser Datei. Dieses Artefakt wird als Eingabe für die Bereitstellungsaktion verwendet, die als Nächstes folgt.

  Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).
+ Eine Bereitstellungsaktion (`DeployToECS`) — Nach Abschluss der Build-Aktion sucht die Bereitstellungsaktion nach dem von der Build-Aktion (`TaskDefArtifact`) generierten Ausgabeartefakt, findet dessen Inhalt und registriert es bei Ihrem Amazon ECS-Service. `taskdef.json` Der Service folgt dann den Anweisungen in der `taskdef.json` Datei, um drei Amazon ECS-Aufgaben — und zugehörige Hello World Docker-Container — in Ihrem Amazon ECS-Cluster auszuführen. 

**So erstellen Sie ein Workflow**

1. **Wählen Sie in der CodeCatalyst Konsole im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

1. Wählen Sie für **Quell-Repository** die Option`codecatalyst-ecs-source-repository`.

1. Wählen Sie für **Branch** die Option`main`.

1. Wählen Sie **Erstellen** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie den folgenden YAML-Code hinzu:
**Anmerkung**  
Im folgenden YAML-Code können Sie die `Connections:` Abschnitte weglassen, wenn Sie möchten. Wenn Sie diese Abschnitte weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle angegebene Rolle** in Ihrer Umgebung die Berechtigungen und Vertrauensrichtlinien beider Rollen enthält, die unter beschrieben sind. [Schritt 5: AWS Rollen hinzufügen CodeCatalyst](#deploy-tut-ecs-import-roles) Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)

   ```
   Name: codecatalyst-ecs-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     BuildBackend:
       Identifier: aws/build@v1
       Environment:
         Name: codecatalyst-ecs-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-ecs-build-role
       Inputs:
         Sources:
           - WorkflowSource
         Variables:
           - Name: REPOSITORY_URI
             Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo
           - Name: IMAGE_TAG
             Value: ${WorkflowSource.CommitId}
       Configuration:
         Steps:
           #pre_build:
           - Run: echo Logging in to Amazon ECR...
           - Run: aws --version
           - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
           #build:
           - Run: echo Build started on `date`
           - Run: echo Building the Docker image...
           - Run: docker build -t $REPOSITORY_URI:latest .
           - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
           #post_build:
           - Run: echo Build completed on `date`
           - Run: echo Pushing the Docker images...
           - Run: docker push $REPOSITORY_URI:latest
           - Run: docker push $REPOSITORY_URI:$IMAGE_TAG
           # Replace the variables in taskdef.json
           - Run: find taskdef.json -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
           - Run: find taskdef.json -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
           - Run: cat taskdef.json
           # The output artifact will be a zip file that contains a task definition file.
       Outputs:
         Artifacts:
           - Name: TaskDefArtifact
             Files: 
               - taskdef.json
     DeployToECS:
       DependsOn: 
         - BuildBackend
       Identifier: aws/ecs-deploy@v1
       Environment:
         Name: codecatalyst-ecs-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-ecs-deploy-role
       Inputs:
         Sources: []
         Artifacts:
           - TaskDefArtifact
       Configuration:
         region: us-west-2
         cluster: codecatalyst-ecs-cluster
         service: codecatalyst-ecs-service
         task-definition: taskdef.json
   ```

   Ersetzen Sie im vorherigen Code:
   + Beide Instanzen von *codecatalyst-ecs-environment* mit dem Namen der Umgebung, in der Sie erstellt haben[Voraussetzungen](#deploy-tut-ecs-prereqs).
   + Beide Instanzen von *codecatalyst-account-connection* mit dem Anzeigenamen Ihrer Kontoverbindung. Der Anzeigename kann eine Zahl sein. Weitere Informationen finden Sie unter [Schritt 5: AWS Rollen hinzufügen CodeCatalyst](#deploy-tut-ecs-import-roles).
   + *codecatalyst-ecs-build-role*mit dem Namen der Build-Rolle, in der Sie sie erstellt haben[Schritt 4: AWS Rollen erstellen](#deploy-tut-ecs-build-deploy-roles).
   + *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo*(in der `Value:` Eigenschaft) mit der URI des Amazon ECR-Repositorys, in [Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository](#deploy-tut-ecs-ecr) dem Sie es erstellt haben.
   + *111122223333.dkr.ecr.us-west-2.amazonaws.com*(im `Run: aws ecr` Befehl) mit der URI des Amazon ECR-Repositorys ohne das Bildsuffix ()`/codecatalyst-ecs-image-repo`.
   + *codecatalyst-ecs-deploy-role*mit dem Namen der Bereitstellungsrolle, in der Sie sie erstellt haben. [Schritt 4: AWS Rollen erstellen](#deploy-tut-ecs-build-deploy-roles)
   + Beide Instanzen von *us-west-2* mit Ihrem AWS Regionalcode. Eine Liste der Regionalcodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) in der *Allgemeine AWS-Referenz*.
**Anmerkung**  
Wenn Sie sich entschieden haben, keine Build- und Deploy-Rollen zu erstellen, ersetzen Sie *codecatalyst-ecs-build-role* und *codecatalyst-ecs-deploy-role* durch den Namen der `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle. Weitere Informationen über diese Rolle finden Sie unter [Schritt 4: AWS Rollen erstellen](#deploy-tut-ecs-build-deploy-roles).
**Tipp**  
Anstatt die `sed` Befehle `find` und und zu verwenden, die im vorherigen Workflow-Code gezeigt wurden, um das Repository und den Namen des Images zu aktualisieren, können Sie zu diesem Zweck die **Amazon ECS-Aufgabendefinitionsaktion rendern** verwenden. Weitere Informationen finden Sie unter [Ändern einer Amazon ECS-Aufgabendefinition](render-ecs-action.md).

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im Dialogfeld „**Workflow bestätigen**“ Folgendes ein:

   1. Entfernen Sie **bei Nachricht bestätigen** den Text und geben Sie Folgendes ein:

      ```
      Add first workflow
      ```

   1. Wählen Sie für **Repository**`codecatalyst-ecs-source-repository`.

   1. Wählen Sie als **Branch-Name** die Option main aus.

   1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt einen Workflow erstellt. Eine Workflow-Ausführung wird aufgrund des oben im Workflow definierten Triggers automatisch gestartet. Insbesondere, als Sie die `workflow.yaml` Datei in Ihr Quell-Repository übernommen (und per Push übertragen) haben, hat der Trigger die Workflow-Ausführung gestartet.

**Um den Fortschritt der Workflow-Ausführung zu sehen**

1. **Wählen Sie im Navigationsbereich der CodeCatalyst Konsole **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Workflow aus, den Sie gerade erstellt haben,. `codecatalyst-ecs-workflow`

1. Wählen Sie **BuildBackend**, ob Sie den Baufortschritt sehen möchten.

1. Wählen Sie **DeployToECS**, um den Fortschritt der Bereitstellung zu sehen.

   Weitere Informationen zum Anzeigen von Ausführungsdetails finden Sie unter[Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

**Um die Bereitstellung zu überprüfen**

1. Öffnen Sie die Amazon ECS Classic-Konsole unter [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/).

1. Wählen Sie Ihren Cluster,`codecatalyst-ecs-cluster`.

1. Wählen Sie die Registerkarte **Tasks** aus. 

1. Wählen Sie eine der drei Aufgaben.

1. Wählen Sie im Feld **Öffentliche IP** die Option **Open Address** aus.

   Im Browser wird eine Seite „Hello World“ angezeigt, die darauf hinweist, dass der Amazon ECS-Service Ihre Anwendung erfolgreich bereitgestellt hat.

## Schritt 9: Nehmen Sie eine Änderung an Ihren Quelldateien vor
<a name="deploy-tut-ecs-change"></a>

In diesem Abschnitt nehmen Sie eine Änderung an der `index.html` Datei in Ihrem Quell-Repository vor. Diese Änderung veranlasst den Workflow, ein neues Docker-Image zu erstellen, es mit einer Commit-ID zu kennzeichnen, es an Amazon ECR weiterzuleiten und es in Amazon ECS bereitzustellen. 

**Um die Datei index.html zu ändern**

1. Wählen Sie in der CodeCatalyst Konsole im Navigationsbereich **Code**, dann **Quell-Repositories** und anschließend Ihr Repository aus. `codecatalyst-ecs-source-repository`

1. Klicken Sie auf `public-html` und danach auf `index.html`.

   Der Inhalt von `index.html` wird angezeigt.

1. Wählen Sie **Bearbeiten** aus. 

1. Ändern Sie in Zeile 14 den `Hello World` Text in`Tutorial complete!`.

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Durch den Commit wird ein neuer Workflow-Lauf gestartet. 

1. (Optional) Gehen Sie zur Hauptseite Ihres Quell-Repositorys, wählen Sie **Commits anzeigen** und notieren Sie sich die Commit-ID für die `index.html` Änderung.

1. Beobachten Sie den Fortschritt der Bereitstellung:

   1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

   1. Wählen Sie`codecatalyst-ecs-workflow`, ob Sie die letzte Ausführung anzeigen möchten.

   1. Wählen Sie und **DeployToECS **BuildBackend****, um den Fortschritt der Workflow-Ausführung zu sehen.

1. Stellen Sie wie folgt sicher, dass Ihre Anwendung aktualisiert wurde:

   1. Öffnen Sie die Amazon ECS Classic-Konsole unter [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/).

   1. Wählen Sie Ihren Cluster,`codecatalyst-ecs-cluster`.

   1. Wählen Sie die Registerkarte **Tasks** aus. 

   1. Wählen Sie eine der drei Aufgaben.

   1. Wählen Sie im Feld **Öffentliche IP** die Option **Open Address** aus.

      Eine `Tutorial complete!` Seite wird angezeigt.

1. (Optional) Wechseln Sie in AWS zur Amazon ECR-Konsole und überprüfen Sie, ob das neue Docker-Image mit der Commit-ID aus Schritt 6 gekennzeichnet wurde.

## Bereinigen
<a name="deploy-tut-ecs-cleanup"></a>

Bereinigen Sie die in diesem Tutorial verwendeten Dateien und Dienste, um zu vermeiden, dass dafür Gebühren anfallen.

Im AWS-Managementkonsole, bereinigen Sie in dieser Reihenfolge:

1. Gehen Sie in Amazon ECS wie folgt vor:

   1. Löschen`codecatalyst-ecs-service`.

   1. Löschen`codecatalyst-ecs-cluster`.

   1. Abmelden`codecatalyst-ecs-task-definition`.

1. Löschen `codecatalyst-ecs-image-repo` Sie in Amazon ECR.

1. Löschen `codecatalyst-ecs-security-group` Sie in Amazon EC2.

1. Löschen Sie im IAM Identity Center:

   1. `CodeCatalystECSUser`

   1. `CodeCatalystECSPermissionSet`

Bereinigen Sie in der CodeCatalyst Konsole wie folgt:

1. Löschen`codecatalyst-ecs-workflow`.

1. Löschen`codecatalyst-ecs-environment`.

1. Löschen`codecatalyst-ecs-source-repository`.

1. Löschen`codecatalyst-ecs-project`.

In diesem Tutorial haben Sie gelernt, wie Sie mithilfe eines CodeCatalyst Workflows und einer Aktion „In Amazon ECS bereitstellen“ eine Anwendung für einen **Amazon ECS-Service bereitstellen**.

# Aktion „In Amazon ECS bereitstellen“ hinzufügen
<a name="deploy-action-ecs-adding"></a>

Verwenden Sie die folgenden Anweisungen, um die Aktion **Deploy to Amazon ECS** zu Ihrem Workflow hinzuzufügen. 

------
#### [ Visual ]

**Um die Aktion „In Amazon ECS bereitstellen“ mit dem visuellen 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion **Deploy to Amazon ECS** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **Deploy to Amazon ECS**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion „In Amazon ECS bereitstellen“ YAML](deploy-action-ref-ecs.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „In Amazon ECS bereitstellen“ 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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion **Deploy to Amazon ECS** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **Deploy to Amazon ECS**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion „In Amazon ECS bereitstellen“ YAML](deploy-action-ref-ecs.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.

------

# Variablen „In Amazon ECS bereitstellen“
<a name="deploy-action-ecs-variables"></a>

Die Aktion **Deploy to Amazon ECS** erzeugt und setzt zur Laufzeit die folgenden Variablen. Diese werden als *vordefinierte Variablen* bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Cluster  |  Der Name des Amazon ECS-Clusters, auf dem während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `codecatalyst-ecs-cluster`  | 
|  Bereitstellungsplattform  |  Der Name der Bereitstellungsplattform. Fest codiert auf. `AWS:ECS`  | 
|  Service nicht zulässig  |  Der Name des Amazon ECS-Service, für den während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `codecatalyst-ecs-service`  | 
|  task-definition-arn  |  Der Amazon-Ressourcenname (ARN) der Aufgabendefinition, die während der Workflow-Ausführung registriert wurde. Beispiel: `arn:aws:ecs:us-west-2:111122223333:task-definition/codecatalyst-task-def:8`Der Wert `:8` im vorherigen Beispiel gibt die Revision an, die registriert wurde.  | 
|  Bereitstellungs-URL  |  Ein Link zur Registerkarte **Ereignisse** der Amazon ECS-Konsole, auf der Sie Details zur Amazon ECS-Bereitstellung im Zusammenhang mit der Workflow-Ausführung einsehen können. Beispiel: `https://console.aws.amazon.com/ecs/home?region=us-west-2#/clusters/codecatalyst-ecs-cluster/services/codecatalyst-ecs-service/events`  | 
|  Region  |  Der Regionalcode von AWS-Region , für den während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `us-west-2`  | 

# Aktion „In Amazon ECS bereitstellen“ YAML
<a name="deploy-action-ref-ecs"></a>

Im Folgenden finden Sie die YAML-Definition der Aktion **Deploy to Amazon ECS**. Informationen zur Verwendung dieser Aktion finden Sie unter[Bereitstellung auf Amazon ECS mit einem Workflow](deploy-action-ecs.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 action definition starts here.   
  ECSDeployAction\$1nn: 
    Identifier: aws/ecs-deploy@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - task-definition-artifact
    Configuration: 
      region: us-east-1 
      cluster: ecs-cluster
      service: ecs-service
      task-definition: task-definition-path
      force-new-deployment: false|true
      codedeploy-appspec: app-spec-file-path
      codedeploy-application: application-name
      codedeploy-deployment-group: deployment-group-name
      codedeploy-deployment-description: deployment-description
```

## ECSDeployAction
<a name="deploy.action.ecs.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `ECSDeployAction_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Anzeigename der Aktion**

## Identifier
<a name="deploy.action.ecs.identifier"></a>

(*ECSDeployAction*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nicht, es sei denn, Sie möchten die Version ändern. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/ecs-deploy@v1`.

**Entsprechende Benutzeroberfläche: ECSDeploy Workflow-Diagram/action\$1nn/ aws/ecs-deploy @v1 label**

## DependsOn
<a name="deploy.action.ecs.dependson"></a>

(*ECSDeployAction*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="deploy.action.ecs.computename"></a>

(*ECSDeployAction*/**Compute**)

(Optional)

Die Rechen-Engine, die zur Ausführung Ihrer Workflow-Aktionen verwendet wurde. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="deploy.action.ecs.computetype"></a>

(*ECSDeployAction*/Compute/**Type**)

(Erforderlich, wenn [Compute](#deploy.action.ecs.computename) es enthalten ist)

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: Konfiguration tab/Advanced — optional/ Berechnungstyp**

## Fleet
<a name="deploy.action.ecs.computefleet"></a>

(*ECSDeployAction*/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 können sofort Aktionen ausführen. 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`

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Compute Fleet**

## Timeout
<a name="deploy.action.ecs.timeout"></a>

(*ECSDeployAction*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Environment
<a name="deploy.action.ecs.environment"></a>

(*ECSDeployAction*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="deploy.action.ecs.environment.name"></a>

(*ECSDeployAction*/Environment/**Name**)

(Erforderlich, wenn [Environment](#deploy.action.ecs.environment) es enthalten ist)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="deploy.action.ecs.environment.connections"></a>

(*ECSDeployAction*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="deploy.action.ecs.environment.connections.name"></a>

(*ECSDeployAction*/Environment/Connections/**Name**)

(Erforderlich, wenn [Connections](#deploy.action.ecs.environment.connections) es enthalten ist)

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="deploy.action.ecs.environment.connections.role"></a>

(*ECSDeployAction*/Environment/Connections/**Role**)

(Erforderlich, wenn [Connections](#deploy.action.ecs.environment.connections) es enthalten ist)

Geben Sie den Namen der IAM-Rolle an, auf die die Aktion **Deploy to Amazon ECS** für den Zugriff AWS verwendet. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf diejenigen, die in der folgenden Richtlinie aufgeführt sind. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [{
      "Action":[
        "ecs:DescribeServices",
        "ecs:CreateTaskSet",
        "ecs:DeleteTaskSet",
        "ecs:ListClusters",
        "ecs:RegisterTaskDefinition",
        "ecs:UpdateServicePrimaryTaskSet",
        "ecs:UpdateService",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:DescribeRules",
        "elasticloadbalancing:ModifyRule",
        "lambda:InvokeFunction",
        "lambda:ListFunctions",
        "cloudwatch:DescribeAlarms",
        "sns:Publish",
        "sns:ListTopics", 
        "s3:GetObject",
        "s3:GetObjectVersion",
        "codedeploy:CreateApplication", 
        "codedeploy:CreateDeployment", 
        "codedeploy:CreateDeploymentGroup", 
        "codedeploy:GetApplication", 
        "codedeploy:GetDeployment", 
        "codedeploy:GetDeploymentGroup", 
        "codedeploy:ListApplications", 
        "codedeploy:ListDeploymentGroups", 
        "codedeploy:ListDeployments", 
        "codedeploy:StopDeployment", 
        "codedeploy:GetDeploymentTarget", 
        "codedeploy:ListDeploymentTargets", 
        "codedeploy:GetDeploymentConfig", 
        "codedeploy:GetApplicationRevision", 
        "codedeploy:RegisterApplicationRevision", 
        "codedeploy:BatchGetApplicationRevisions", 
        "codedeploy:BatchGetDeploymentGroups", 
        "codedeploy:BatchGetDeployments", 
        "codedeploy:BatchGetApplications", 
        "codedeploy:ListApplicationRevisions", 
        "codedeploy:ListDeploymentConfigs", 
        "codedeploy:ContinueDeployment"           
     ],
     "Resource":"*",
     "Effect":"Allow"
  },{"Action":[
        "iam:PassRole"
     ],
     "Effect":"Allow",
     "Resource":"*",
     "Condition":{"StringLike":{"iam:PassedToService":[
              "ecs-tasks.amazonaws.com",
              "codedeploy.amazonaws.com"
           ]
        }
     }
  }]
  }
  ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal verwendet wird, verwenden Sie den folgenden Platzhalter in der Ressourcenrichtlinienanweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

  ```
  "Resource": "*"
  ```
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Inputs
<a name="deploy.action.ecs.inputs"></a>

(*ECSDeployAction*/**Inputs**)

(Optional)

`Inputs`In diesem Abschnitt werden die Daten definiert, die während einer `ECSDeployAction` Workflow-Ausführung benötigt werden.

**Anmerkung**  
Pro Aktion „**Deploy to Amazon ECS**“ ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

## Sources
<a name="deploy.action.ecs.inputs.sources"></a>

(*ECSDeployAction*/Inputs/**Sources**)

(Erforderlich, wenn Ihre Aufgabendefinitionsdatei in einem Quell-Repository gespeichert ist)

Wenn Ihre Aufgabendefinitionsdatei in einem Quell-Repository gespeichert ist, geben Sie die Bezeichnung dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label`WorkflowSource`.

Wenn Ihre Aufgabendefinitionsdatei nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="deploy.action.ecs.inputs.artifacts"></a>

(*ECSDeployAction*/Inputs/**Artifacts**)

(Erforderlich, wenn Ihre Aufgabendefinitionsdatei in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer vorherigen Aktion gespeichert ist)

Wenn die Aufgabendefinitionsdatei, die Sie bereitstellen möchten, in einem Artefakt enthalten ist, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Wenn Ihre Aufgabendefinitionsdatei nicht in einem Artefakt enthalten ist, muss sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Configuration
<a name="deploy.action.ecs.configuration"></a>

(*ECSDeployAction*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## region
<a name="deploy.action.ecs.region"></a>

(Configuration/**region**)

(Erforderlich)

Geben Sie die AWS Region an, in der sich Ihr Amazon ECS-Cluster und -Service befinden. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) in der. *Allgemeine AWS-Referenz*

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Region“**

## cluster
<a name="deploy.action.ecs.cluster"></a>

(*ECSDeployAction*/Configuration/**cluster**)

(Erforderlich)

Geben Sie den Namen eines vorhandenen Amazon ECS-Clusters an. Mit der Aktion **Deploy to Amazon ECS** wird Ihre containerisierte Anwendung als Aufgabe in diesem Cluster bereitgestellt. Weitere Informationen zu Amazon ECS-Clustern finden Sie unter [Clusters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters) im *Amazon Elastic Container Service Developer Guide*.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Cluster“**

## service
<a name="deploy.action.ecs.service"></a>

(*ECSDeployAction*/Configuration/**service**)

(Erforderlich)

Geben Sie den Namen eines vorhandenen Amazon ECS-Service an, der die Aufgabendefinitionsdatei instanziieren wird. Dieser Service muss sich unter dem im Feld angegebenen Cluster befinden. `cluster` Weitere Informationen zu Amazon ECS-Services finden Sie unter [Amazon ECS-Services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) im *Amazon Elastic Container Service Developer Guide*.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Service“**

## task-definition
<a name="deploy.action.ecs.task.definition"></a>

(*ECSDeployAction*/Configuration/**task-definition**)

(Erforderlich)

Geben Sie den Pfad zu einer vorhandenen Aufgabendefinitionsdatei an. Wenn sich die Datei in Ihrem Quell-Repository befindet, ist der Pfad relativ zum Stammordner des Quell-Repositorys. Wenn sich Ihre Datei in einem Artefakt aus einer früheren Workflow-Aktion befindet, ist der Pfad relativ zum Artefakt-Stammordner. Weitere Informationen zu Aufgabendefinitionsdateien finden Sie unter [Aufgabendefinitionen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) im *Amazon Elastic Container Service Developer Guide*.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aufgabendefinition**“

## force-new-deployment
<a name="deploy.action.ecs.forcenewdeployment"></a>

(*ECSDeployAction*/Configuration/**force-new-deployment**)

(Erforderlich)

Wenn diese Option aktiviert ist, kann der Amazon ECS-Service neue Bereitstellungen ohne Änderungen der Servicedefinition starten. Wenn eine Bereitstellung erzwungen wird, stoppt der Service alle aktuell ausgeführten Aufgaben und startet neue Aufgaben. Weitere Informationen zum Erzwingen neuer Bereitstellungen finden Sie unter [Aktualisieren eines Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html) im *Amazon Elastic Container Service Developer Guide*.

Standard: `false`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Neue Bereitstellung des Dienstes erzwingen**

## codedeploy-appspec
<a name="deploy.action.ecs.codedeploy.appspec"></a>

(*ECSDeployAction*/Configuration/**codedeploy-appspec**)

(Erforderlich, wenn Sie Ihren Amazon ECS-Service für die Verwendung von blue/green Bereitstellungen konfiguriert haben, andernfalls weglassen)

Geben Sie den Namen und den Pfad zu einer vorhandenen CodeDeploy Anwendungsspezifikationsdatei (AppSpec) an. Diese Datei muss sich im Stammverzeichnis Ihres CodeCatalyst Quell-Repositorys befinden. Weitere Informationen zu AppSpec Dateien finden Sie unter [CodeDeploy Anwendungsspezifikationsdateien (AppSpec)](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) im *AWS CodeDeploy Benutzerhandbuch*.

**Anmerkung**  
Geben Sie nur CodeDeploy Informationen an, wenn Sie Ihren Amazon ECS-Service für die Durchführung von blue/green Bereitstellungen konfiguriert haben. Lassen Sie bei fortlaufenden Update-Bereitstellungen (Standard) die Informationen weg. CodeDeploy Weitere Informationen zu Amazon ECS-Bereitstellungen finden Sie unter [Amazon ECS-Bereitstellungstypen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html) im *Amazon Elastic Container Service Developer Guide*.

**Anmerkung**  
Die **CodeDeploy**Felder sind möglicherweise im visuellen Editor ausgeblendet. Informationen dazu, wie sie angezeigt werden, finden Sie unter[Warum fehlen CodeDeploy Felder im visuellen Editor?](troubleshooting-workflows.md#troubleshooting-workflows-codedeploy).

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**CodeDeploy AppSpec**

## codedeploy-application
<a name="deploy.action.ecs.codedeploy.application"></a>

(*ECSDeployAction*/Configuration/**codedeploy-application**)

(Erforderlich, wenn `codedeploy-appspec` es enthalten ist)

Geben Sie den Namen einer vorhandenen CodeDeploy Anwendung an. Weitere Informationen zu CodeDeploy Anwendungen finden Sie [ CodeDeployim *AWS CodeDeploy Benutzerhandbuch* unter Arbeiten mit Anwendungen](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/AnwendungCodeDeploy “**

## codedeploy-deployment-group
<a name="deploy.action.ecs.codedeploy.deploymentgroup"></a>

(*ECSDeployAction*/Configuration/**codedeploy-deployment-group**)

(Erforderlich, wenn `codedeploy-appspec` es enthalten ist)

Geben Sie den Namen einer vorhandenen CodeDeploy Bereitstellungsgruppe an. Weitere Informationen zu CodeDeploy Bereitstellungsgruppen finden Sie [ CodeDeployim *AWS CodeDeploy Benutzerhandbuch* unter Arbeiten mit Bereitstellungsgruppen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html).

Entsprechende Benutzeroberfläche: Registerkarte „**CodeDeploy Konfiguration/Bereitstellungsgruppe**“

## codedeploy-deployment-description
<a name="deploy.action.ecs.codedeploy.deploymentdescription"></a>

(*ECSDeployAction*/Configuration/**codedeploy-deployment-description**)

(Optional)

Geben Sie eine Beschreibung der Bereitstellung an, die durch diese Aktion erstellt wird. Weitere Informationen finden Sie [ CodeDeployim *AWS CodeDeploy Benutzerhandbuch* unter Arbeiten mit Bereitstellungen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ und Beschreibung der Bereitstellung CodeDeploy **

# Bereitstellung auf Amazon EKS mit einem Workflow
<a name="deploy-action-eks"></a>

**Tipp**  
Ein Tutorial, das Ihnen zeigt, wie Sie die **Cluster-Aktion Deploy to Kubernetes** verwenden, finden Sie unter. [Tutorial: Bereitstellen einer Anwendung in Amazon EKS](deploy-tut-eks.md)

In diesem Abschnitt wird beschrieben, wie Sie eine containerisierte Anwendung mithilfe eines Workflows in einem Kubernetes-Cluster bereitstellen. CodeCatalyst Um dies zu erreichen, müssen Sie Ihrem Workflow die Aktion Auf **Kubernetes-Cluster bereitstellen** hinzufügen. Diese Aktion stellt Ihre Anwendung in einem Kubernetes-Cluster bereit, den Sie in Amazon Elastic Kubernetes Service (EKS) mithilfe einer oder mehrerer Kubernetes-Manifestdateien eingerichtet haben. Ein Beispielmanifest finden Sie unter. [deployment.yaml](deploy-tut-eks.md#deploy-tut-eks-source-files-deployment-yml) [Tutorial: Bereitstellen einer Anwendung in Amazon EKS](deploy-tut-eks.md)

Weitere Informationen zu Kubernetes finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/home/).

Weitere Informationen zu Amazon EKS finden Sie unter [Was ist Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) im *Amazon EKS-Benutzerhandbuch*.

**Topics**
+ [

## So funktioniert die Aktion „Im Kubernetes-Cluster bereitstellen“
](#deploy-action-eks-howitworks)
+ [

## Runtime-Image, das von der Aktion „In Amazon EKS bereitstellen“ verwendet wird
](#deploy-action-eks-runtime)
+ [

# Tutorial: Bereitstellen einer Anwendung in Amazon EKS
](deploy-tut-eks.md)
+ [

# Aktion „Im Kubernetes-Cluster bereitstellen“ hinzufügen
](deploy-action-eks-adding.md)
+ [

# Variablen „Im Kubernetes-Cluster bereitstellen“
](deploy-action-eks-variables.md)
+ [

# Aktion „Im Kubernetes-Cluster bereitstellen“ YAML
](deploy-action-ref-eks.md)

## So funktioniert die Aktion „Im Kubernetes-Cluster bereitstellen“
<a name="deploy-action-eks-howitworks"></a>

Der **Cluster „Auf Kubernetes bereitstellen**“ funktioniert wie folgt:

1. Zur Laufzeit installiert die Aktion das `kubectl` Kubernetes-Hilfsprogramm auf dem CodeCatalyst Computer, auf dem die Aktion ausgeführt wird. Die Aktion ist so konfiguriert`kubectl`, dass sie auf den Amazon EKS-Cluster verweist, den Sie bei der Konfiguration der Aktion angegeben haben. Das `kubectl` Hilfsprogramm ist erforderlich, um den `kubectl apply` Befehl als Nächstes auszuführen.

1. Die Aktion führt den `kubectl apply -f my-manifest.yaml` Befehl aus, der die Anweisungen *my-manifest.yaml* zur Bereitstellung Ihrer Anwendung als Satz von Containern und Pods im konfigurierten Cluster ausführt. Weitere Informationen zu diesem Befehl finden Sie im Thema [kubectl apply in der *Kubernetes-Referenzdokumentation*](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply).

## Runtime-Image, das von der Aktion „In Amazon EKS bereitstellen“ verwendet wird
<a name="deploy-action-eks-runtime"></a>

Die Aktion In **Amazon EKS bereitstellen** wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Tutorial: Bereitstellen einer Anwendung in Amazon EKS
<a name="deploy-tut-eks"></a>

In diesem Tutorial erfahren Sie, wie Sie mithilfe eines CodeCatalyst Amazon-Workflows, Amazon EKS und einiger anderer Services eine containerisierte Anwendung in Amazon Elastic Kubernetes Service bereitstellen. AWS Bei der bereitgestellten Anwendung handelt es sich um ein einfaches „Hello, World\$1“ Website, die auf einem Docker-Image des Apache-Webservers basiert. Das Tutorial führt Sie durch die erforderlichen Vorbereitungsarbeiten wie das Einrichten einer Entwicklungsmaschine und eines Amazon EKS-Clusters und beschreibt anschließend, wie Sie einen Workflow erstellen, um die Anwendung zu erstellen und sie im Cluster bereitzustellen.

Nach Abschluss der ersten Bereitstellung werden Sie im Tutorial angewiesen, eine Änderung an Ihrer Anwendungsquelle vorzunehmen. Diese Änderung führt dazu, dass ein neues Docker-Image erstellt und mit neuen Revisionsinformationen in Ihr Docker-Image-Repository übertragen wird. Die neue Version des Docker-Images wird dann in Amazon EKS bereitgestellt.

**Tipp**  
Anstatt sich durch dieses Tutorial zu arbeiten, können Sie einen Blueprint verwenden, der ein vollständiges Amazon EKS-Setup für Sie durchführt. Sie müssen den **EKS App Deployment** Blueprint verwenden. Weitere Informationen finden Sie unter [Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template).

**Topics**
+ [

## Voraussetzungen
](#deploy-tut-eks-prereqs)
+ [

## Schritt 1: Richten Sie Ihren Entwicklungscomputer ein
](#deploy-tut-eks-dev-env-create)
+ [

## Schritt 2: Erstellen Sie einen Amazon EKS-Cluster
](#deploy-tut-eks-cluster)
+ [

## Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository
](#deploy-tut-eks-ecr)
+ [

## Schritt 4: Quelldateien hinzufügen
](#deploy-tut-eks-source-files)
+ [

## Schritt 5: AWS Rollen erstellen
](#deploy-tut-eks-roles)
+ [

## Schritt 6: AWS Rollen hinzufügen zu CodeCatalyst
](#deploy-tut-eks-import-roles)
+ [

## Schritt 7: Aktualisieren Sie das ConfigMap
](#deploy-tut-eks-configmap)
+ [

## Schritt 8: Erstellen Sie einen Workflow und führen Sie ihn aus
](#deploy-tut-eks-workflow)
+ [

## Schritt 9: Nehmen Sie eine Änderung an Ihren Quelldateien vor
](#deploy-tut-eks-change)
+ [

## Bereinigen
](#deploy-tut-eks-cleanup)

## Voraussetzungen
<a name="deploy-tut-eks-prereqs"></a>

Bevor Sie mit diesem Tutorial beginnen:
+ Sie benötigen einen CodeCatalyst **Amazon-Bereich** mit einem verbundenen AWS Konto. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In Ihrem Bereich benötigen Sie ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-eks-project
  ```

  Verwenden Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).
+ In Ihrem Projekt benötigen Sie ein leeres CodeCatalyst **Quell-Repository** mit dem Namen:

  ```
  codecatalyst-eks-source-repository
  ```

  Weitere Informationen finden Sie unter [Speichern Sie Code mit Quell-Repositorys in und arbeiten Sie gemeinsam daran CodeCatalystSpeichern Sie Code mit Quell-Repositorys und arbeiten Sie gemeinsam daran](source.md).
+ In Ihrem Projekt benötigen Sie eine CodeCatalyst **CI/CD-Umgebung** (keine Entwicklungsumgebung) namens:

  ```
  codecatalyst-eks-environment
  ```

  Konfigurieren Sie diese Umgebung wie folgt:
  + Wählen Sie einen beliebigen Typ aus, z. B. „Keine **Produktion**“.
  + Connect dein AWS Konto damit. 
  + Wählen Sie für die **Standard-IAM-Rolle eine** beliebige Rolle aus. Sie werden später eine andere Rolle angeben.

  Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).

## Schritt 1: Richten Sie Ihren Entwicklungscomputer ein
<a name="deploy-tut-eks-dev-env-create"></a>

Der erste Schritt in diesem Tutorial besteht darin, einen Entwicklungscomputer mit einigen Tools zu konfigurieren, die Sie in diesem Tutorial verwenden werden. Diese Tools sind:
+ das `eksctl` Hilfsprogramm — für die Cluster-Erstellung
+ das `kubectl` Hilfsprogramm — eine Voraussetzung für `eksctl`
+ das AWS CLI — auch eine Voraussetzung für `eksctl`

Sie können diese Tools auf Ihrem vorhandenen Entwicklungscomputer installieren, falls Sie einen haben, oder Sie können eine CodeCatalyst Entwicklungsumgebung verwenden, die cloudbasiert ist. Der Vorteil einer CodeCatalyst Entwicklungsumgebung besteht darin, dass sie einfach hoch- und heruntergefahren werden kann und in andere CodeCatalyst Dienste integriert ist, sodass Sie dieses Tutorial in weniger Schritten durcharbeiten können.

In diesem Tutorial wird davon ausgegangen, dass Sie eine CodeCatalyst Entwicklungsumgebung verwenden.

Die folgenden Anweisungen beschreiben eine schnelle Methode, um eine CodeCatalyst Entwicklungsumgebung zu starten und sie mit den erforderlichen Tools zu konfigurieren. Eine ausführliche Anleitung finden Sie unter:
+ [Erstellen einer Entwicklungsumgebung](devenvironment-create.md) in dieser Anleitung.
+ [Installation von kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) im **Amazon EKS-Benutzerhandbuch**.
+ [Installation oder Aktualisierung von eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) im **Amazon EKS-Benutzerhandbuch**.
+ [Installation oder Aktualisierung der neuesten Version von, die AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im *AWS Command Line Interface Benutzerhandbuch* beschrieben ist.

**Um eine Entwicklungsumgebung zu starten**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Navigieren Sie zu Ihrem Projekt,`codecatalyst-eks-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus. 

1. Wählen Sie den Namen Ihres Quell-Repositorys,`codecatalyst-eks-source-repository`.

1. Wählen Sie oben **Create Dev Environment** und dann **AWS Cloud9 (im Browser)** aus.

1. Vergewissern Sie sich, dass **In vorhandenem Zweig und **Hauptbereich** arbeiten** ausgewählt sind, und wählen Sie dann **Create** aus.

   Ihre Entwicklungsumgebung wird in einem neuen Browser-Tab gestartet, in den Ihr Repository (`codecatalyst-eks-source-repository`) geklont wird.

**Um kubectl zu installieren und zu konfigurieren**

1. Geben Sie im Dev Environment-Terminal Folgendes ein:

   ```
   curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl
   ```

1. Geben Sie ein:

   ```
   chmod +x ./kubectl
   ```

1. Geben Sie ein:

   ```
   mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
   ```

1. Geben Sie ein:

   ```
   echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
   ```

1. Geben Sie ein:

   ```
   kubectl version --short --client
   ```

1. Vergewissern Sie sich, dass eine Version angezeigt wird.

   Sie haben es jetzt installiert`kubectl`.

**Um eksctl zu installieren und zu konfigurieren**
**Anmerkung**  
`eksctl`ist nicht unbedingt erforderlich, da Sie stattdessen verwenden `kubectl` können. `eksctl`Hat jedoch den Vorteil, dass ein Großteil der Clusterkonfiguration automatisiert wird, und ist daher das für dieses Tutorial empfohlene Tool.

1. Geben Sie im Dev Environment-Terminal Folgendes ein:

   ```
   curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
   ```

1. Geben Sie ein:

   ```
   sudo cp /tmp/eksctl /usr/bin
   ```

1. Geben Sie ein:

   ```
   eksctl version
   ```

1. Vergewissern Sie sich, dass eine Version angezeigt wird.

   Sie haben es jetzt installiert`eksctl`.

**Um zu überprüfen, ob das installiert AWS CLI ist**

1. Geben Sie im Dev Environment-Terminal Folgendes ein:

   ```
   aws --version
   ```

1. Überprüfen Sie, ob eine Version angezeigt wird, um zu überprüfen, ob die installiert AWS CLI ist.

   Führen Sie die verbleibenden Verfahren aus, um die AWS CLI mit den erforderlichen Zugriffsberechtigungen zu konfigurieren AWS.

**Um das zu konfigurieren AWS CLI**

Sie müssen das AWS CLI mit Zugriffsschlüsseln und einem Sitzungstoken konfigurieren, um ihm Zugriff auf AWS Dienste zu gewähren. Die folgenden Anweisungen bieten eine schnelle Möglichkeit, die Schlüssel und das Token zu konfigurieren. Wenn Sie jedoch detaillierte Anweisungen wünschen, finden Sie [AWS CLI im *AWS Command Line Interface Benutzerhandbuch* unter Konfiguration von](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).

1. Erstellen Sie wie folgt einen IAM Identity Center-Benutzer:

   1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS IAM Identity Center Konsole unter [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/).

      (Möglicherweise müssen Sie **Aktivieren** auswählen, wenn Sie sich noch nie bei IAM Identity Center angemeldet haben.)
**Anmerkung**  
Stellen Sie sicher, dass Sie sich mit dem anmelden AWS-Konto , der mit Ihrem CodeCatalyst Bereich verbunden ist. Sie können überprüfen, welches Konto verbunden ist, indem Sie zu Ihrem Bereich navigieren und den Tab **AWS-Konten** auswählen. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).

   1. Wählen Sie im Navigationsbereich **Users (Benutzer)** und dann **Add User (Benutzer hinzufügen)** aus.

   1. Geben Sie im Feld **Nutzername** Folgendes ein:

      ```
      codecatalyst-eks-user
      ```

   1. Wählen Sie unter **Passwort** die Option **Einmalpasswort generieren aus, das Sie mit diesem Benutzer teilen können**.

   1. Geben Sie in den **Feldern **E-Mail-Adresse** und E-Mail-Adresse bestätigen** eine E-Mail-Adresse ein, die noch nicht in IAM Identity Center existiert.

   1. Geben Sie im Feld **Vorname** Folgendes ein:

      ```
      codecatalyst-eks-user
      ```

   1. Geben Sie im Feld **Nachname** Folgendes ein:

      ```
      codecatalyst-eks-user
      ```

   1. Behalten **Sie im Feld Anzeigename** Folgendes bei:

      ```
      codecatalyst-eks-user codecatalyst-eks-user
      ```

   1. Wählen Sie **Weiter** aus.

   1. Wählen Sie auf der Seite „**Benutzer zu Gruppen hinzufügen**“ die Option **Weiter** aus.

   1. Überprüfen Sie auf der Seite **Benutzer überprüfen und hinzufügen** die Informationen und wählen Sie **Benutzer hinzufügen** aus.

      Ein Dialogfeld mit einem **Einmalkennwort** wird angezeigt.

   1. Wählen Sie **Kopieren** und fügen Sie dann die Anmeldeinformationen in eine Textdatei ein. Die Anmeldeinformationen bestehen aus der URL des AWS Zugriffsportals, einem Benutzernamen und einem Einmalkennwort.

   1. Klicken Sie auf **Schließen**.

1. Erstellen Sie wie folgt einen Berechtigungssatz:

   1. Wählen Sie im Navigationsbereich die Option **Berechtigungssätze** und dann **Berechtigungssatz erstellen** aus.

   1. Wählen Sie **Vordefinierter Berechtigungssatz** und dann aus **AdministratorAccess**. Diese Richtlinie gewährt allen volle Berechtigungen AWS-Services. 

   1. Wählen Sie **Weiter** aus.

   1. Entfernen Sie im Feld **Name des Berechtigungssatzes** den Wert `AdministratorAccess` und geben Sie Folgendes ein:

      ```
      codecatalyst-eks-permission-set
      ```

   1. Wählen Sie **Weiter** aus.

   1. **Überprüfen Sie auf der Seite Überprüfen und erstellen** die Informationen und wählen Sie **Erstellen** aus.

1. Weisen Sie den Berechtigungssatz wie folgt zu`codecatalyst-eks-user`:

   1. Wählen Sie im Navigationsbereich die Option aus **AWS-Konten**, und aktivieren Sie dann das Kontrollkästchen neben dem AWS-Konto , bei dem Sie derzeit angemeldet sind.

   1. Wählen Sie **Benutzer oder Gruppen zuweisen** aus.

   1. Wählen Sie die Registerkarte **Users**.

   1. Aktivieren Sie das Kontrollkästchen neben`codecatalyst-eks-user`.

   1. Wählen Sie **Weiter** aus.

   1. Aktivieren Sie das Kontrollkästchen neben`codecatalyst-eks-permission-set`.

   1. Wählen Sie **Weiter** aus.

   1. Überprüfen Sie die Informationen und wählen Sie **Senden** aus.

      Sie haben sie nun `codecatalyst-eks-permission-set` zugewiesen `codecatalyst-eks-user` und an Sie AWS-Konto gebunden.

1. Rufen Sie `codecatalyst-eks-user` die Zugriffsschlüssel und das Sitzungstoken wie folgt ab:

   1. Stellen Sie sicher, dass Sie die URL des AWS Zugriffsportals sowie den Benutzernamen und das Einmalpasswort für haben`codecatalyst-eks-user`. Sie hätten diese Informationen früher in einen Texteditor kopieren sollen.
**Anmerkung**  
Wenn Ihnen diese Informationen nicht vorliegen, rufen Sie die `codecatalyst-eks-user` Detailseite im IAM Identity Center auf und wählen Sie **Passwort zurücksetzen**, **Einmalpasswort generieren [...]** , und klicken **Sie erneut auf Passwort zurücksetzen**, um die Informationen auf dem Bildschirm anzuzeigen.

   1. Melden Sie sich ab AWS.

   1. Fügen Sie die URL des AWS Zugangsportals in die Adressleiste Ihres Browsers ein.

   1. Melden Sie sich an mit:
      + **Nutzername**:

        ```
        codecatalyst-eks-user
        ```
      + **Passwort**:

        *one-time-password*

   1. Geben **Sie unter Neues Passwort einrichten** ein neues Passwort ein und wählen Sie **Neues Passwort festlegen** aus.

      Auf dem Bildschirm erscheint ein **AWS-Konto**Feld.

   1. Wählen Sie **AWS-Konto**und wählen Sie dann den Namen des Benutzers und des AWS-Konto Berechtigungssatzes aus, dem Sie den `codecatalyst-eks-user` Benutzer zugewiesen haben.

   1. Wählen Sie neben `codecatalyst-eks-permission-set` **Befehlszeile oder programmatischer Zugriff** aus.

   1. Kopieren Sie die Befehle in der Mitte der Seite. Sie sehen etwa wie folgt aus:

      ```
      export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" 
      export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" 
      export AWS_SESSION_TOKEN="session-token"
      ```

      ... wo *session-token* ist eine lange zufällige Zeichenfolge.

1. Fügen Sie die Zugriffsschlüssel und das AWS CLI Sitzungstoken wie folgt zur hinzu:

   1. Kehren Sie zu Ihrer CodeCatalyst Entwicklungsumgebung zurück.

   1. Fügen Sie an der Terminal-Eingabeaufforderung die Befehle ein, die Sie kopiert haben. Drücken Sie die **Eingabetaste**.

      Sie haben das jetzt AWS CLI mit Zugriffsschlüsseln und einem Sitzungstoken konfiguriert. Sie können es jetzt verwenden AWS CLI , um die für dieses Tutorial erforderlichen Aufgaben zu erledigen.
**Wichtig**  
Wenn Sie während dieses Tutorials zu irgendeinem Zeitpunkt Meldungen sehen, die den folgenden ähneln:  
`Unable to locate credentials. You can configure credentials by running "aws configure".`  
Oder:  
`ExpiredToken: The security token included in the request is expired`  
... das liegt daran, dass Ihre AWS CLI Sitzung abgelaufen ist. Führen Sie in diesem Fall den `aws configure` Befehl *nicht* aus. Verwenden Sie stattdessen die Anweisungen in Schritt 4 dieses Verfahrens, das mit „Aktualisieren `Obtain codecatalyst-eks-user's access key and session token` Sie Ihre Sitzung“ beginnt.

## Schritt 2: Erstellen Sie einen Amazon EKS-Cluster
<a name="deploy-tut-eks-cluster"></a>

In diesem Abschnitt erstellen Sie einen Cluster in Amazon EKS. Die folgenden Anweisungen beschreiben eine schnelle Methode zum Erstellen des Clusters mithilfe von`eksctl`. Wenn Sie jedoch detaillierte Anweisungen wünschen, finden Sie unter:
+ [Erste Schritte mit eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) im **Amazon EKS-Benutzerhandbuch**

  oder
+ [Erste Schritte mit der Konsole und AWS CLI](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html) im **Amazon EKS-Benutzerhandbuch** (dieses Thema enthält `kubectl` Anweisungen zum Erstellen des Clusters) 

**Anmerkung**  
[Private Cluster](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) werden von der CodeCatalyst Integration mit Amazon EKS nicht unterstützt.

**Bevor Sie beginnen**

Stellen Sie sicher, dass Sie die folgenden Aufgaben auf Ihrem Entwicklungscomputer abgeschlossen haben:
+ Das `eksctl` Hilfsprogramm wurde installiert.
+ Das `kubectl` Hilfsprogramm wurde installiert.
+ Habe das installiert AWS CLI und mit Zugriffsschlüsseln und einem Sitzungstoken konfiguriert.

Informationen zur Ausführung dieser Aufgaben finden Sie unter[Schritt 1: Richten Sie Ihren Entwicklungscomputer ein](#deploy-tut-eks-dev-env-create).

**So erstellen Sie einen Cluster**
**Wichtig**  
Verwenden Sie nicht die Benutzeroberfläche des Amazon EKS-Service, um den Cluster zu erstellen, da der Cluster dann nicht korrekt konfiguriert wird. Verwenden Sie das `eksctl` Hilfsprogramm, wie in den folgenden Schritten beschrieben.

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Erstellen Sie einen Cluster und Knoten:

   ```
   eksctl create cluster --name codecatalyst-eks-cluster --region us-west-2
   ```

   Wobei Folgendes gilt:
   + *codecatalyst-eks-cluster*wird durch den Namen ersetzt, den Sie Ihrem Cluster geben möchten.
   + *us-west-2*wird durch Ihre Region ersetzt.

   Nach 10 bis 20 Minuten erscheint eine Meldung, die der folgenden ähnelt: 

   `EKS cluster "codecatalyst-eks-cluster" in "us-west-2" region is ready`
**Anmerkung**  
Während AWS der Erstellung Ihres Clusters werden mehrere `waiting for CloudFormation stack` Meldungen angezeigt. Das ist normal.

1. Stellen Sie sicher, dass Ihr Cluster erfolgreich erstellt wurde:

   ```
   kubectl cluster-info
   ```

   Es wird eine Meldung ähnlich der folgenden angezeigt, die auf eine erfolgreiche Clustererstellung hinweist:

   ```
   Kubernetes master is running at https://long-string.gr7.us-west-2.eks.amazonaws.com
   CoreDNS is running at https://long-string.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
   ```

## Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository
<a name="deploy-tut-eks-ecr"></a>

In diesem Abschnitt erstellen Sie ein privates Image-Repository in Amazon Elastic Container Registry (Amazon ECR). Dieses Repository speichert das Docker-Image für das Tutorial.

Weitere Informationen zu Amazon ECR finden Sie im *Amazon Elastic Container Registry User Guide*.

**Um ein Bild-Repository in Amazon ECR zu erstellen**

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Erstellen Sie ein leeres Repository in Amazon ECR:

   ```
   aws ecr create-repository --repository-name codecatalyst-eks-image-repo
   ```

   *codecatalyst-eks-image-repo*Ersetzen Sie es durch den Namen, den Sie dem Amazon ECR-Repository geben möchten.

   In diesem Tutorial wird davon ausgegangen, dass Sie Ihrem Repository `codecatalyst-eks-image-repo` einen Namen gegeben haben.

1. Zeigen Sie die Details des Amazon ECR-Repositorys an:

   ```
   aws ecr describe-repositories \
         --repository-names codecatalyst-eks-image-repo
   ```

1. Notieren Sie sich den `“repositoryUri”:` Wert, zum Beispiel. `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo`

   Sie benötigen ihn später, wenn Sie das Repository zu Ihrem Workflow hinzufügen. 

## Schritt 4: Quelldateien hinzufügen
<a name="deploy-tut-eks-source-files"></a>

In diesem Abschnitt fügen Sie Anwendungsquelldateien zu Ihrem Quell-Repository hinzu (`codecatalyst-eks-source-repository`). Sie bestehen aus:
+ Eine `index.html` Datei — Zeigt ein „Hallo, Welt\$1“ Nachricht im Browser.
+ Ein Dockerfile — Beschreibt das Basis-Image, das für Ihr Docker-Image verwendet werden soll, und die Docker-Befehle, die darauf angewendet werden sollen.
+ Eine `deployment.yaml` Datei — Das Kubernetes-Manifest, das den Kubernetes-Service und die Bereitstellung definiert. 

Die Ordnerstruktur sieht wie folgt aus:

```
|— codecatalyst-eks-source-repository
   |— Kubernetes
      |— deployment.yaml
   |— public-html
   |  |— index.html
   |— Dockerfile
```

**Topics**
+ [

### index.html
](#deploy-tut-eks-source-files-index)
+ [

### Dockerfile
](#deploy-tut-eks-source-files-dockerfile)
+ [

### deployment.yaml
](#deploy-tut-eks-source-files-deployment-yml)

### index.html
<a name="deploy-tut-eks-source-files-index"></a>

In der `index.html` Datei wird die Meldung „Hello, World\$1“ angezeigt Nachricht im Browser. 

**Um die Datei index.html hinzuzufügen**

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Erstellen Sie in `codecatalyst-eks-source-repository` einen Ordner mit dem Namen`public-html`.

1. Erstellen Sie in `/public-html` eine Datei namens `index.html` mit dem folgenden Inhalt:

   ```
   <html>
     <head>
       <title>Hello World</title>
       <style>
         body {
         background-color: black;
         text-align: center;
         color: white;
         font-family: Arial, Helvetica, sans-serif;
         }  
       </style>
     </head>
     <body>
       <h1>Hello, World!</h1>
     </body>
   </html>
   ```

1. Geben Sie an der Terminal-Eingabeaufforderung Folgendes ein:

   ```
   cd /projects/codecatalyst-eks-source-repository
   ```

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "add public-html/index.html"
   git push
   ```

   Das `index.html` wird Ihrem Repository in einem `public-html` Ordner hinzugefügt. 

### Dockerfile
<a name="deploy-tut-eks-source-files-dockerfile"></a>

Das Dockerfile beschreibt das zu verwendende Basis-Decker-Image und die darauf anzuwendenden Docker-Befehle. [Weitere Informationen zum Dockerfile finden Sie in der Dockerfile-Referenz.](https://docs.docker.com/engine/reference/builder/)

Das hier angegebene Dockerfile gibt an, dass das Apache 2.4-Basisimage () verwendet werden soll. `httpd` Es enthält auch Anweisungen zum Kopieren einer `index.html` aufgerufenen Quelldatei in einen Ordner auf dem Apache-Server, der Webseiten bereitstellt. Die `EXPOSE` Anweisung in der Dockerfile teilt Docker mit, dass der Container auf Port 80 lauscht.

**Um das Dockerfile hinzuzufügen**

1. Erstellen Sie in `codecatalyst-eks-source-repository` eine Datei namens `Dockerfile` mit dem folgenden Inhalt:

   ```
   FROM httpd:2.4
   COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
   EXPOSE 80
   ```

   Geben Sie keine Dateierweiterung an.
**Wichtig**  
Das Dockerfile muss sich im Stammordner Ihres Repositorys befinden. Der `Docker build` Befehl des Workflows erwartet, dass es dort vorhanden ist.

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "add Dockerfile"
   git push
   ```

   Das Dockerfile wird zu Ihrem Repository hinzugefügt.

### deployment.yaml
<a name="deploy-tut-eks-source-files-deployment-yml"></a>

In diesem Abschnitt fügen Sie Ihrem Repository eine `deployment.yaml` Datei hinzu. Die `deployment.yaml` Datei ist ein Kubernetes-Manifest, das zwei auszuführende Kubernetes-Ressourcentypen oder *-arten* definiert: einen „Dienst“ und eine „Bereitstellung“.
+ Der „Service“ stellt einen Load Balancer in Amazon EC2 bereit. Der Load Balancer stellt Ihnen eine mit dem Internet verbundene öffentliche URL und einen Standardport (Port 80) zur Verfügung, über den Sie zu „Hello, World\$1“ navigieren können Anwendung. 
+ Bei der „Bereitstellung“ werden drei Pods bereitgestellt, und jeder Pod enthält einen Docker-Container mit dem Namen „Hello, World\$1“ Anwendung. Die drei Pods werden auf den Knoten bereitgestellt, die bei der Erstellung des Clusters erstellt wurden.

Das Manifest in diesem Tutorial ist kurz. Ein Manifest kann jedoch eine beliebige Anzahl von Kubernetes-Ressourcentypen wie Pods, Jobs, Ingresses und Netzwerkrichtlinien enthalten. Außerdem können Sie mehrere Manifestdateien verwenden, wenn Ihre Bereitstellung komplex ist.

**Um eine deployment.yaml-Datei hinzuzufügen**

1. Erstellen Sie in einen `codecatalyst-eks-source-repository` Ordner mit dem Namen. `Kubernetes`

1. Erstellen Sie in `/Kubernetes` eine Datei namens `deployment.yaml` mit dem folgenden Inhalt:

   ```
   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
     labels:
       app: my-app
   spec:
     type: LoadBalancer
     selector:
       app: my-app
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-deployment
     labels:
       app: my-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: codecatalyst-eks-container
           # The $REPOSITORY_URI and $IMAGE_TAG placeholders will be replaced by actual values supplied by the build action in your workflow
           image: $REPOSITORY_URI:$IMAGE_TAG
           ports:
           - containerPort: 80
   ```

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "add Kubernetes/deployment.yaml"
   git push
   ```

   Die `deployment.yaml` Datei wird Ihrem Repository in einem Ordner mit dem Namen hinzugefügt`Kubernetes`. 

Sie haben jetzt alle Ihre Quelldateien hinzugefügt.

Nehmen Sie sich einen Moment Zeit, um Ihre Arbeit zu überprüfen und sicherzustellen, dass Sie alle Dateien in den richtigen Ordnern abgelegt haben. Die Ordnerstruktur ist wie folgt:

```
|— codecatalyst-eks-source-repository
   |— Kubernetes
      |— deployment.yaml
   |— public-html
   |  |— index.html
   |— Dockerfile
```

## Schritt 5: AWS Rollen erstellen
<a name="deploy-tut-eks-roles"></a>

In diesem Abschnitt erstellen Sie AWS IAM-Rollen, die Ihr CodeCatalyst Workflow benötigt, um zu funktionieren. Diese Rollen sind:
+ **Build-Rolle** — Erteilt der CodeCatalyst Build-Aktion (im Workflow) die Berechtigung, auf Ihr AWS Konto zuzugreifen und in Amazon ECR und Amazon EC2 zu schreiben.
+ **Rolle bereitstellen** — Erteilt der **Cluster-Aktion CodeCatalyst Deploy to Kubernetes** (im Workflow) die Berechtigung, auf Ihr AWS Konto und Amazon EKS zuzugreifen.

*Weitere Informationen zu IAM-Rollen finden Sie unter [IAM-Rollen im Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html).AWS Identity and Access Management *

**Anmerkung**  
Um Zeit zu sparen, können Sie anstelle der beiden zuvor aufgeführten Rollen eine einzelne `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle, die so genannte Rolle, erstellen. Weitere Informationen finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über sehr umfangreiche Berechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. In diesem Tutorial wird davon ausgegangen, dass Sie die beiden zuvor aufgeführten Rollen erstellen.

Führen Sie die folgenden Verfahren aus, um die Build- und Deploy-Rollen zu erstellen.

**1. Um eine Vertrauensrichtlinie für beide Rollen zu erstellen**

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Erstellen Sie im `Cloud9-long-string` Verzeichnis eine Datei namens `codecatalyst-eks-trust-policy.json` mit dem folgenden Inhalt:

**2. Um die Build-Richtlinie für die Build-Rolle zu erstellen**
+ Erstellen Sie im `Cloud9-long-string` Verzeichnis eine Datei namens `codecatalyst-eks-build-policy.json` mit dem folgenden Inhalt:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "ecr:*",
                  "ec2:*"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

  ```
  "Resource": "*"
  ```

**3. Um die Bereitstellungsrichtlinie für die Bereitstellungsrolle zu erstellen**
+ Erstellen Sie im `Cloud9-long-string` Verzeichnis eine Datei namens `codecatalyst-eks-deploy-policy.json` mit dem folgenden Inhalt:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "eks:DescribeCluster",
                  "eks:ListClusters"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

  ```
  "Resource": "*"
  ```

Sie haben Ihrer Entwicklungsumgebung jetzt drei Richtliniendokumente hinzugefügt. Ihre Verzeichnisstruktur sieht jetzt wie folgt aus:

```
|— Cloud9-long-string
   |— .c9
   |— codecatalyst-eks-source-repository
      |— Kubernetes
      |— public-html
      |— Dockerfile
   codecatalyst-eks-build-policy.json
   codecatalyst-eks-deploy-policy.json
   codecatalyst-eks-trust-policy.json
```

**4. Um die Build-Richtlinie hinzuzufügen AWS**

1. Geben Sie im Dev Environment-Terminal Folgendes ein:

   ```
   cd /projects
   ```

1. Geben Sie ein:

   ```
   aws iam create-policy \
       --policy-name codecatalyst-eks-build-policy \
       --policy-document file://codecatalyst-eks-build-policy.json
   ```

1. Drücken Sie die **Eingabetaste**.

1. Notieren Sie sich den `"arn":` Wert in der Befehlsausgabe, zum Beispiel`arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy`. Sie benötigen diesen ARN später.

**5. Um die Bereitstellungsrichtlinie hinzuzufügen AWS**

1. Geben Sie ein:

   ```
   aws iam create-policy \
       --policy-name codecatalyst-eks-deploy-policy \
       --policy-document file://codecatalyst-eks-deploy-policy.json
   ```

1. Drücken Sie die **Eingabetaste**.

1. Notieren Sie sich in der Befehlsausgabe den `"arn":` Wert der Bereitstellungsrichtlinie, `arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy` z. B. Sie benötigen diesen ARN später.

**6. Um die Build-Rolle zu erstellen**

1. Geben Sie ein: 

   ```
   aws iam create-role \
         --role-name codecatalyst-eks-build-role \
         --assume-role-policy-document file://codecatalyst-eks-trust-policy.json
   ```

1. Drücken Sie die **Eingabetaste**.

1. Geben Sie ein:

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-eks-build-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy
   ```

   Wo *arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy* wird durch den ARN der Build-Richtlinie ersetzt, die Sie zuvor notiert haben.

1. Drücken Sie die **Eingabetaste**.

1. Geben Sie an der Terminal-Eingabeaufforderung Folgendes ein:

   ```
   aws iam get-role \
         --role-name codecatalyst-eks-build-role
   ```

1. Drücken Sie die **Eingabetaste**.

1. Notieren Sie sich den `"Arn":` Wert der Rolle, zum Beispiel`arn:aws:iam::111122223333:role/codecatalyst-eks-build-role`. Sie benötigen diesen ARN später.

**7. Um die Bereitstellungsrolle zu erstellen**

1. Geben Sie ein:

   ```
   aws iam create-role \
         --role-name codecatalyst-eks-deploy-role \
         --assume-role-policy-document file://codecatalyst-eks-trust-policy.json
   ```

1. Drücken Sie die **Eingabetaste**.

1. Geben Sie ein:

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-eks-deploy-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy
   ```

   Wo *arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy* wird durch den ARN der Bereitstellungsrichtlinie ersetzt, die Sie zuvor notiert haben.

1. Drücken Sie die **Eingabetaste**.

1. Geben Sie ein:

   ```
   aws iam get-role \
         --role-name codecatalyst-eks-deploy-role
   ```

1. Drücken Sie die **Eingabetaste**.

1. Notieren Sie sich den `"Arn":` Wert der Rolle, zum Beispiel`arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role`. Sie benötigen diesen ARN später.

Sie haben jetzt Build- und Deploy-Rollen erstellt und diese notiert ARNs.

## Schritt 6: AWS Rollen hinzufügen zu CodeCatalyst
<a name="deploy-tut-eks-import-roles"></a>

In diesem Schritt fügen Sie die Build-Rolle (`codecatalyst-eks-build-role`) und die Bereitstellungsrolle (`codecatalyst-eks-deploy-role`) zu der Rolle hinzu AWS-Konto , die Sie mit Ihrem Bereich verbunden haben. Dadurch sind die Rollen für die Verwendung in Ihrem Workflow verfügbar.

**Um Build- und Deploy-Rollen zu Ihrem hinzuzufügen AWS-Konto**

1. Navigieren Sie in der CodeCatalyst Konsole zu Ihrem Bereich.

1. Wählen Sie oben **Einstellungen** aus.

1. Wählen Sie im Navigationsbereich **AWS Konten** aus. Eine Liste von Konten wird angezeigt.

1. Kopieren Sie in die Spalte ** CodeCatalyst Amazon-Anzeigename** den Anzeigenamen der AWS-Konto Stelle, in der Sie Ihre Build- und Deploy-Rollen erstellt haben. (Es könnte eine Zahl sein.) Sie benötigen diesen Wert später, wenn Sie Ihren Workflow erstellen.

1. Wählen Sie den Anzeigenamen.

1. Wählen Sie in der ** AWS Managementkonsole die Option Rollen verwalten aus**.

   Die Seite „**IAM-Rolle zu Amazon CodeCatalyst Space hinzufügen**“ wird angezeigt. Möglicherweise müssen Sie sich anmelden, um auf die Seite zuzugreifen.

1. Wählen Sie **Eine bestehende Rolle hinzufügen, die Sie in IAM erstellt haben**.

   Eine Dropdownliste wird angezeigt. In der Liste werden die Build- und Deploy-Rollen sowie alle anderen IAM-Rollen mit einer Vertrauensrichtlinie angezeigt, die auch die Dienstprinzipale `codecatalyst-runner.amazonaws.com` und die `codecatalyst.amazonaws.com` Dienstprinzipale umfasst.

1. Fügen Sie aus der Dropdownliste Folgendes hinzu:
   + `codecatalyst-eks-build-role`
   + `codecatalyst-eks-deploy-role`
**Anmerkung**  
Wenn Sie das sehen`The security token included in the request is invalid`, liegt es möglicherweise daran, dass Sie nicht über die richtigen Berechtigungen verfügen. Um dieses Problem zu beheben, melden Sie sich ab und melden Sie sich mit dem AWS Konto wieder an, das Sie bei der Erstellung Ihres CodeCatalyst Bereichs verwendet haben. AWS 

1. Kehren Sie zur CodeCatalyst Konsole zurück und aktualisieren Sie die Seite.

   Die Rollen Build und Deploy sollten jetzt unter **IAM-Rollen** angezeigt werden.

   Diese Rollen sind jetzt für die Verwendung in CodeCatalyst Workflows verfügbar.

## Schritt 7: Aktualisieren Sie das ConfigMap
<a name="deploy-tut-eks-configmap"></a>

Sie müssen die Bereitstellungsrolle, die Sie in [Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles) der `ConfigMap` Kubernetes-Datei erstellt haben, hinzufügen, damit die **Cluster-Aktion Deploy to Kubernetes (in Ihrem Workflow) auf Ihren Cluster** zugreifen und mit ihm interagieren kann. Sie können `eksctl` oder verwenden, `kubectl` um diese Aufgabe auszuführen.

**Um die ConfigMap Kubernetes-Datei mit eksctl zu konfigurieren**
+ Geben Sie im Dev Environment-Terminal Folgendes ein: 

  ```
  eksctl create iamidentitymapping --cluster codecatalyst-eks-cluster --arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role --group system:masters --username codecatalyst-eks-deploy-role --region us-west-2
  ```

  Wobei Folgendes gilt:
  + *codecatalyst-eks-cluster*wird durch den Clusternamen des Amazon EKS-Clusters ersetzt.
  +  *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*wird durch den ARN der Bereitstellungsrolle ersetzt, in der Sie erstellt haben[Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).
  +  *codecatalyst-eks-deploy-role*(neben`--username`) wird durch den Namen der Bereitstellungsrolle ersetzt, in der Sie sie erstellt haben[Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).
**Anmerkung**  
Wenn Sie sich entschieden haben, keine Bereitstellungsrolle zu erstellen, *codecatalyst-eks-deploy-role* ersetzen Sie sie durch den Namen der `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle. Weitere Informationen über diese Rolle finden Sie unter [Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).
  +  *us-west-2*wird durch Ihre Region ersetzt.

  Einzelheiten zu diesem Befehl finden Sie unter [IAM-Benutzer und -Rollen verwalten](https://eksctl.io/usage/iam-identity-mappings/).

  Eine Meldung ähnlich der folgenden wird angezeigt:

  ```
  2023-06-09 00:58:29 [ℹ]  checking arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role against entries in the auth ConfigMap
  2023-06-09 00:58:29 [ℹ]  adding identity "arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role" to auth ConfigMap
  ```

**Um die ConfigMap Kubernetes-Datei mit kubectl zu konfigurieren**

1. Geben Sie im Dev Environment-Terminal Folgendes ein:

   ```
   kubectl edit configmap -n kube-system aws-auth
   ```

   Die ConfigMap Datei wird auf dem Bildschirm angezeigt.

1. Fügen Sie den Text in roter Kursivschrift hinzu:

   ```
   # Please edit the object below. Lines beginning with a '#' will be ignored,
   # and an empty file will abort the edit. If an error occurs while saving this file will be
   # reopened with the relevant failures.
   #
   apiVersion: v1
   data:
     mapRoles: |
       - groups:
         - system:bootstrappers
         - system:nodes
         rolearn: arn:aws:iam::111122223333:role/eksctl-codecatalyst-eks-cluster-n-NodeInstanceRole-16BC456ME6YR5
         username: system:node:{{EC2PrivateDNSName}}
       - groups:
         - system:masters
         rolearn: arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role
         username: codecatalyst-eks-deploy-role
     mapUsers: |
       []
   kind: ConfigMap
   metadata:
     creationTimestamp: "2023-06-08T19:04:39Z"
     managedFields:
     ...
   ```

   Wobei Folgendes gilt:
   +  *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*wird durch den ARN der Bereitstellungsrolle ersetzt, in der Sie erstellt haben[Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles). 
   +  *codecatalyst-eks-deploy-role*(neben`username:`) wird durch den Namen der Bereitstellungsrolle ersetzt, in der Sie sie erstellt haben[Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).
**Anmerkung**  
Wenn Sie sich entschieden haben, keine Bereitstellungsrolle zu erstellen, *codecatalyst-eks-deploy-role* ersetzen Sie sie durch den Namen der `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle. Weitere Informationen über diese Rolle finden Sie unter [Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).

   Einzelheiten finden Sie unter [Aktivieren des IAM-Prinzipalzugriffs auf Ihren Cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) im **Amazon EKS-Benutzerhandbuch**.

Sie haben jetzt der Bereitstellungsrolle und damit der Aktion **Deploy to Amazon EKS** `system:masters` Berechtigungen für Ihren Kubernetes-Cluster erteilt.

## Schritt 8: Erstellen Sie einen Workflow und führen Sie ihn aus
<a name="deploy-tut-eks-workflow"></a>

In diesem Schritt erstellen Sie einen Workflow, der Ihre Quelldateien zu einem Docker-Image zusammenbaut und das Image dann in Tree-Pods in Ihrem Amazon EKS-Cluster bereitstellt.

Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein Trigger — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine Build-Aktion (`BuildBackend`) — Beim Auslösen erstellt die Aktion das Docker-Image mithilfe der Dockerfile und überträgt das Image an Amazon ECR. Die Build-Aktion aktualisiert auch die `$IMAGE_TAG` Variablen `$REPOSITORY_URI` und in der `deployment.yaml` Datei mit den richtigen Werten und erstellt dann ein Ausgabeartefakt aus dieser Datei und allen anderen Dateien im Ordner. `Kubernetes` In diesem Tutorial ist die einzige Datei im `Kubernetes` Ordner, `deployment.yaml` aber Sie könnten weitere Dateien hinzufügen. Das Artefakt wird als Eingabe für die Bereitstellungsaktion verwendet, die als Nächstes folgt.

  Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).
+ Eine Bereitstellungsaktion (`DeployToEKS`) — Nach Abschluss der Build-Aktion sucht die Bereitstellungsaktion nach dem von der Build-Aktion (`Manifests`) generierten Ausgabeartefakt und findet die darin enthaltene `deployment.yaml` Datei. Die Aktion folgt dann den Anweisungen in der `deployment.yaml` Datei, um drei Pods auszuführen, von denen jeder ein einzelnes „Hello, World\$1“ enthält Docker-Container — in Ihrem Amazon EKS-Cluster. 

**So erstellen Sie ein Workflow**

1. Gehen Sie zur Konsole. CodeCatalyst 

1. Navigiere zu deinem Projekt (`codecatalyst-eks-project`).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

1. Wählen Sie für **Quell-Repository** die Option`codecatalyst-eks-source-repository`.

1. Wählen Sie für **Branch** die Option`main`.

1. Wählen Sie **Erstellen** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie den folgenden YAML-Code hinzu, um eine neue Workflow-Definitionsdatei zu erstellen:
**Anmerkung**  
Weitere Informationen zur Workflow-Definitionsdatei finden Sie unter[YAML-Workflow-Definition](workflow-reference.md).
**Anmerkung**  
Im folgenden YAML-Code können Sie die `Connections:` Abschnitte weglassen, wenn Sie möchten. Wenn Sie diese Abschnitte weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle angegebene Rolle** in Ihrer Umgebung die Berechtigungen und Vertrauensrichtlinien beider Rollen enthält, die unter beschrieben sind. [Schritt 6: AWS Rollen hinzufügen zu CodeCatalyst](#deploy-tut-eks-import-roles) Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)

   ```
   Name: codecatalyst-eks-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     BuildBackend:
       Identifier: aws/build@v1
       Environment:
         Name: codecatalyst-eks-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-eks-build-role
       Inputs:
         Sources:
           - WorkflowSource
         Variables:
           - Name: REPOSITORY_URI
             Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo
           - Name: IMAGE_TAG
             Value: ${WorkflowSource.CommitId}
       Configuration:
         Steps:
           #pre_build:
           - Run: echo Logging in to Amazon ECR...
           - Run: aws --version
           - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
           #build:
           - Run: echo Build started on `date`
           - Run: echo Building the Docker image...
           - Run: docker build -t $REPOSITORY_URI:latest .
           - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
           #post_build:
           - Run: echo Build completed on `date`
           - Run: echo Pushing the Docker images...
           - Run: docker push $REPOSITORY_URI:latest
           - Run: docker push $REPOSITORY_URI:$IMAGE_TAG
           # Replace the variables in deployment.yaml
           - Run: find Kubernetes/ -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
           - Run: find Kubernetes/ -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
           - Run: cat Kubernetes/*
           # The output artifact will be a zip file that contains Kubernetes manifest files.
       Outputs:
         Artifacts:
           - Name: Manifests
             Files: 
               - "Kubernetes/*"
     DeployToEKS:
       DependsOn: 
         - BuildBackend
       Identifier: aws/kubernetes-deploy@v1
       Environment:
         Name: codecatalyst-eks-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-eks-deploy-role
       Inputs:
         Artifacts:
           - Manifests
       Configuration:
         Namespace: default
         Region: us-west-2
         Cluster: codecatalyst-eks-cluster
         Manifests: Kubernetes/
   ```

   Ersetzen Sie im vorherigen Code:
   + Beide Instanzen von *codecatalyst-eks-environment* mit dem Namen der Umgebung, in der Sie erstellt haben[Voraussetzungen](#deploy-tut-eks-prereqs).
   + Beide Instanzen von *codecatalyst-account-connection* mit dem Anzeigenamen Ihrer Kontoverbindung. Der Anzeigename kann eine Zahl sein. Weitere Informationen finden Sie unter [Schritt 6: AWS Rollen hinzufügen zu CodeCatalyst](#deploy-tut-eks-import-roles).
   + *codecatalyst-eks-build-role*mit dem Namen der Build-Rolle, in der Sie sie erstellt haben[Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).
   + *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo*(in der `Value:` Eigenschaft) mit der URI des Amazon ECR-Repositorys, in [Schritt 3: Erstellen Sie ein Amazon ECR-Image-Repository](#deploy-tut-eks-ecr) dem Sie es erstellt haben.
   + *111122223333.dkr.ecr.us-west-2.amazonaws.com*(im `Run: aws ecr` Befehl) mit der URI des Amazon ECR-Repositorys ohne das Bildsuffix ()`/codecatalyst-eks-image-repo`.
   + *codecatalyst-eks-deploy-role*mit dem Namen der Bereitstellungsrolle, in der Sie sie erstellt haben. [Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles)
   + Beide Instanzen von *us-west-2* mit Ihrem AWS Regionalcode. Eine Liste der Regionalcodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html) in der *Allgemeine AWS-Referenz*.
**Anmerkung**  
Wenn Sie sich entschieden haben, keine Build- und Deploy-Rollen zu erstellen, ersetzen Sie *codecatalyst-eks-build-role* und *codecatalyst-eks-deploy-role* durch den Namen der `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle. Weitere Informationen über diese Rolle finden Sie unter [Schritt 5: AWS Rollen erstellen](#deploy-tut-eks-roles).

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im Dialogfeld „**Workflow bestätigen**“ Folgendes ein:

   1. Entfernen Sie **bei Nachricht bestätigen** den Text und geben Sie Folgendes ein:

      ```
      Add first workflow
      ```

   1. Wählen Sie für **Repository**`codecatalyst-eks-source-repository`.

   1. Wählen Sie als **Branch-Name** die Option main aus.

   1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt einen Workflow erstellt. Eine Workflow-Ausführung wird aufgrund des oben im Workflow definierten Triggers automatisch gestartet. Insbesondere, als Sie die `workflow.yaml` Datei in Ihr Quell-Repository übernommen (und per Push übertragen) haben, hat der Trigger die Workflow-Ausführung gestartet.

**Um den Fortschritt der Workflow-Ausführung zu sehen**

1. **Wählen Sie im Navigationsbereich der CodeCatalyst Konsole **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Workflow aus, den Sie gerade erstellt haben,. `codecatalyst-eks-workflow`

1. Wählen Sie **BuildBackend**, ob Sie den Baufortschritt sehen möchten.

1. Wählen Sie **DeployToEKS**, um den Fortschritt der Bereitstellung zu sehen.

   Weitere Informationen zum Anzeigen von Ausführungsdetails finden Sie unter[Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

**Um die Bereitstellung zu überprüfen**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie links unten **Load Balancers** aus.

1. Wählen Sie den Load Balancer aus, der als Teil Ihrer Kubernetes-Bereitstellung erstellt wurde. **Wenn Sie sich nicht sicher sind, welchen Load Balancer Sie wählen sollen, suchen Sie auf der Registerkarte „Tags“ nach den folgenden Tags:**
   + `kubernetes.io/service-name`
   + `kubernetes.io/cluster/ekstutorialcluster`

1. Wählen Sie den richtigen Load Balancer aus und wählen Sie den Tab **Beschreibung** aus.

1. Kopieren Sie den **DNS-Namenswert** und fügen Sie ihn in die Adressleiste Ihres Browsers ein.

   Das „Hallo, Welt\$1“ In Ihrem Browser wird eine Webseite angezeigt, die darauf hinweist, dass Sie Ihre Anwendung erfolgreich bereitgestellt haben.

## Schritt 9: Nehmen Sie eine Änderung an Ihren Quelldateien vor
<a name="deploy-tut-eks-change"></a>

In diesem Abschnitt nehmen Sie eine Änderung an der `index.html` Datei in Ihrem Quell-Repository vor. Diese Änderung veranlasst den Workflow, ein neues Docker-Image zu erstellen, es mit einer Commit-ID zu kennzeichnen, es an Amazon ECR weiterzuleiten und es in Amazon ECS bereitzustellen. 

**Um die Datei index.html zu ändern**

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Wechseln Sie an der Terminal-Eingabeaufforderung zu Ihrem Quell-Repository:

   ```
   cd /projects/codecatalyst-eks-source-repository
   ```

1.  Rufen Sie die neuesten Workflow-Änderungen ab:

   ```
   git pull
   ```

1. Öffnen Sie `codecatalyst-eks-source-repository/public-html/index.html`.

1. Ändern Sie in Zeile 14 den `Hello, World!` Text in`Tutorial complete!`.

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "update index.html title"
   git push
   ```

   Eine Workflow-Ausführung wird automatisch gestartet.

1. (Optional) Geben Sie Folgendes ein:

   ```
   git show HEAD
   ```

   Notieren Sie sich die Commit-ID für die `index.html` Änderung. Diese Commit-ID wird dem Docker-Image zugeordnet, das durch die Workflow-Ausführung bereitgestellt wird, die Sie gerade gestartet haben.

1. Beobachten Sie den Fortschritt der Bereitstellung:

   1. **Wählen Sie in der CodeCatalyst Konsole im Navigationsbereich **CI/CD** und dann Workflows aus.**

   1. Wählen Sie`codecatalyst-eks-workflow`, ob Sie die letzte Ausführung anzeigen möchten.

   1. Wählen Sie und **DeployToEKS **BuildBackend****, um den Fortschritt der Workflow-Ausführung zu sehen.

1. Stellen Sie wie folgt sicher, dass Ihre Anwendung aktualisiert wurde:

   1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Wählen Sie links unten **Load Balancers** aus.

   1. Wählen Sie den Load Balancer aus, der als Teil Ihrer Kubernetes-Bereitstellung erstellt wurde.

   1. Kopieren Sie den **DNS-Namenswert** und fügen Sie ihn in die Adressleiste Ihres Browsers ein.

      Das 'Tutorial ist abgeschlossen\$1 ' In Ihrem Browser wird eine Webseite angezeigt, die darauf hinweist, dass Sie erfolgreich eine neue Version Ihrer Anwendung bereitgestellt haben.

1. (Optional) Wechseln Sie in AWS zur Amazon ECR-Konsole und überprüfen Sie, ob das neue Docker-Image mit der Commit-ID aus Schritt 7 dieses Verfahrens gekennzeichnet wurde.

## Bereinigen
<a name="deploy-tut-eks-cleanup"></a>

Sie sollten Ihre Umgebung bereinigen, damit Ihnen die in diesem Tutorial verwendeten Speicher- und Rechenressourcen nicht unnötig in Rechnung gestellt werden.

**So räumen Sie auf**

1. Löschen Sie Ihren Cluster:

   1. Geben Sie im Dev Environment-Terminal Folgendes ein:

     ```
     eksctl delete cluster --region=us-west-2 --name=codecatalyst-eks-cluster
     ```

     Wobei Folgendes gilt:
     + *us-west-2*wird durch Ihre Region ersetzt.
     + *codecatalyst-eks-cluster*wird durch den Namen des Clusters ersetzt, den Sie erstellt haben.

     Nach 5-10 Minuten werden der Cluster und die zugehörigen Ressourcen gelöscht, einschließlich, aber nicht beschränkt auf CloudFormation Stacks, Knotengruppen (in Amazon EC2) und Load Balancer.
**Wichtig**  
Wenn der `eksctl delete cluster` Befehl nicht funktioniert, müssen Sie möglicherweise Ihre AWS Anmeldeinformationen oder Ihre Anmeldeinformationen aktualisieren. `kubectl` Wenn Sie sich nicht sicher sind, welche Anmeldeinformationen Sie aktualisieren sollen, aktualisieren Sie zuerst die AWS Anmeldeinformationen. Informationen zum Aktualisieren Ihrer AWS Anmeldeinformationen finden Sie unter[Wie behebe ich die Fehler „Anmeldeinformationen konnten nicht gefunden werden“ und ExpiredToken „“?](troubleshooting-workflows.md#troubleshooting-workflows-auth-errors-eks). Informationen zum Aktualisieren Ihrer `kubectl` Anmeldeinformationen finden Sie unter[Wie behebe ich die Fehler „Es konnte keine Verbindung zum Server hergestellt werden“?](troubleshooting-workflows.md#troubleshooting-workflows-unable-connect-eks).

1. Bereinigen Sie in der AWS Konsole wie folgt:

   1. Löschen `codecatalyst-eks-image-repo` Sie in Amazon ECR.

   1. Löschen Sie im IAM Identity Center:

      1. `codecatalyst-eks-user`

      1. `codecatalyst-eks-permission-set`

   1. Löschen Sie in IAM:
      + `codecatalyst-eks-build-role`
      + `codecatalyst-eks-deploy-role`
      + `codecatalyst-eks-build-policy`
      + `codecatalyst-eks-deploy-policy`

1. Bereinigen Sie in der CodeCatalyst Konsole wie folgt:

   1. Löschen`codecatalyst-eks-workflow`.

   1. Löschen`codecatalyst-eks-environment`.

   1. Löschen`codecatalyst-eks-source-repository`.

   1. Löschen Sie Ihre Entwicklungsumgebung.

   1. Löschen`codecatalyst-eks-project`.

In diesem Tutorial haben Sie gelernt, wie Sie mithilfe eines CodeCatalyst Workflows und einer **Cluster-Aktion „Deploy to Kubernetes“ eine Anwendung für einen Amazon EKS-Service bereitstellen**.

# Aktion „Im Kubernetes-Cluster bereitstellen“ hinzufügen
<a name="deploy-action-eks-adding"></a>

Verwenden Sie die folgenden Anweisungen, um die Aktion „In **Kubernetes-Cluster bereitstellen“ zu Ihrem Workflow** hinzuzufügen. 

**Bevor Sie beginnen**

Bevor Sie Ihrem Workflow die **Cluster-Aktion „In Kubernetes bereitstellen**“ hinzufügen, müssen Sie Folgendes vorbereitet haben:

**Tipp**  
Folgen Sie den Anweisungen unter, um diese Voraussetzungen schnell einzurichten. [Tutorial: Bereitstellen einer Anwendung in Amazon EKS](deploy-tut-eks.md)
+ Ein Kubernetes-Cluster in Amazon EKS. Informationen zu Clustern finden Sie unter [Amazon EKS-Cluster](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html) im **Amazon EKS-Benutzerhandbuch**.
+ Mindestens ein Dockerfile, das beschreibt, wie Sie Ihre Anwendung zu einem Docker-Image zusammenstellen. [Weitere Informationen zu Dockerfiles finden Sie in der Dockerfile-Referenz.](https://docs.docker.com/engine/reference/builder/)
+ *Mindestens eine Kubernetes-Manifestdatei, die in der Kubernetes-Dokumentation als *Konfigurationsdatei oder Konfiguration* bezeichnet wird.* Weitere Informationen finden Sie in der [Kubernetes-Dokumentation unter Ressourcen verwalten](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/).
+ Eine IAM-Rolle, die der **Cluster-Aktion Deploy to Kubernetes die Möglichkeit gibt, auf Ihren Amazon EKS-Cluster** zuzugreifen und mit ihm zu interagieren. Weitere Informationen erhalten Sie unter dem Thema [Role](deploy-action-ref-eks.md#deploy.action.eks.environment.connections.role) im [Aktion „Im Kubernetes-Cluster bereitstellen“ YAML](deploy-action-ref-eks.md).

  Nachdem Sie diese Rolle erstellt haben, müssen Sie sie hinzufügen zu:
  + Ihre Kubernetes-Datei ConfigMap . Informationen zum Hinzufügen einer Rolle zu einer ConfigMap Datei finden Sie unter [Aktivieren des IAM-Prinzipalzugriffs auf Ihren Cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) im **Amazon EKS-Benutzerhandbuch**.
  + CodeCatalyst. Informationen zum Hinzufügen einer IAM-Rolle zu finden Sie CodeCatalyst unter[Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).
+ Ein CodeCatalyst Raum, ein Projekt und eine Umgebung. Der Bereich und die Umgebung müssen beide mit dem AWS Konto verbunden sein, in dem Sie Ihre Anwendung bereitstellen werden. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md), [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty) und [Einsatz in AWS-Konten und VPCs](deploy-environments.md).
+ Ein Quell-Repository, das von unterstützt wird CodeCatalyst. Das Repository speichert Ihre Anwendungsquelldateien, Dockerfiles und Kubernetes-Manifeste. Weitere Informationen finden Sie unter [Speichern Sie Code mit Quell-Repositorys in und arbeiten Sie gemeinsam daran CodeCatalystSpeichern Sie Code mit Quell-Repositorys und arbeiten Sie gemeinsam daran](source.md).

------
#### [ Visual ]

**Um die Aktion „Im Kubernetes-Cluster bereitstellen“ mit dem visuellen Editor hinzuzufügen**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/. CodeCatalyst ](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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **Cluster-Aktion Deploy to Kubernetes** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie Auf **Kubernetes-Cluster bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion „Im Kubernetes-Cluster bereitstellen“ YAML](deploy-action-ref-eks.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „Im Kubernetes-Cluster bereitstellen“ mit dem YAML-Editor hinzuzufügen**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/. CodeCatalyst ](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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **Cluster-Aktion Deploy to Kubernetes** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie Auf **Kubernetes-Cluster bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion „Im Kubernetes-Cluster bereitstellen“ YAML](deploy-action-ref-eks.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.

------

# Variablen „Im Kubernetes-Cluster bereitstellen“
<a name="deploy-action-eks-variables"></a>

Die **Cluster-Aktion „Auf Kubernetes bereitstellen**“ erzeugt und legt zur Laufzeit die folgenden Variablen fest. Diese werden als *vordefinierte* Variablen bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Cluster  |  Der Amazon.com-Ressourcenname (ARN) des Amazon EKS-Clusters, auf dem während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `arn:aws:eks:us-west-2:111122223333:cluster/codecatalyst-eks-cluster`  | 
|  Bereitstellungsplattform  |  Der Name der Bereitstellungsplattform. Fest codiert auf. `AWS:EKS`  | 
|  Metadaten  |  Reserved Instances. Metadaten im JSON-Format, die sich auf den Cluster beziehen, der während der Workflow-Ausführung bereitgestellt wurde.  | 
|  Namespace  |  Der Kubernetes-Namespace, in dem der Cluster bereitgestellt wurde. Beispiel: `default`  | 
|  Ressourcen  |  Reserved Instances. Metadaten im JSON-Format, die sich auf die Ressourcen beziehen, die während der Workflow-Ausführung bereitgestellt wurden.  | 
|  server  |  Der Name des API-Serverendpunkts, den Sie für die Kommunikation mit Ihrem Cluster mithilfe von Verwaltungstools wie verwenden können. `kubectl` Weitere Informationen zum API-Serviceendpunkt finden Sie unter [Zugriffskontrolle für Amazon EKS-Cluster-Endpunkte](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) im **Amazon EKS-Benutzerhandbuch**. Beispiel: `https://random-string.gr7.us-west-2.eks.amazonaws.com`  | 

# Aktion „Im Kubernetes-Cluster bereitstellen“ YAML
<a name="deploy-action-ref-eks"></a>

Im Folgenden finden Sie die YAML-Definition der Cluster-Aktion **Deploy to Kubernetes**. Informationen zur Verwendung dieser Aktion finden Sie unter. [Bereitstellung auf Amazon EKS mit einem Workflow](deploy-action-eks.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 action definition starts here.   
  DeployToKubernetesCluster\$1nn: 
    Identifier: aws/kubernetes-deploy@v1
    DependsOn:
      - build-action
    Compute:  
        - Type: EC2 | Lambda
        - Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: DeployToEKS
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - manifest-artifact
    Configuration:
      Namespace: namespace
      Region: us-east-1 
      Cluster: eks-cluster
      Manifests: manifest-path
```

## DeployToKubernetesCluster
<a name="deploy.action.eks.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `DeployToKubernetesCluster_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Anzeigename der Aktion**

## Identifier
<a name="deploy.action.eks.identifier"></a>

(*DeployToKubernetesCluster*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/kubernetes-deploy@v1`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ DeployToKubernetesCluster \$1nn/ aws/kubernetes-deploy @v1 label**

## DependsOn
<a name="deploy.action.eks.dependson"></a>

(*DeployToKubernetesCluster*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="deploy.action.eks.computename"></a>

(*DeployToKubernetesCluster*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="deploy.action.eks.computetype"></a>

(*DeployToKubernetesCluster*/Compute/**Type**)

([Compute](#deploy.action.eks.computename)Erforderlich, falls enthalten)

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: Konfiguration tab/Advanced — optional/ Berechnungstyp**

## Fleet
<a name="deploy.action.eks.computefleet"></a>

(*DeployToKubernetesCluster*/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 können sofort Aktionen ausführen. Weitere Informationen zu bereitgestellten Flotten finden Sie unter. [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets)

Wenn nicht angegeben, `Fleet` ist die Standardeinstellung. `Linux.x86-64.Large`

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Compute Fleet**

## Timeout
<a name="deploy.action.eks.timeout"></a>

(*DeployToKubernetesCluster*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Environment
<a name="deploy.action.eks.environment"></a>

(*DeployToKubernetesCluster*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="deploy.action.eks.environment.name"></a>

(*DeployToKubernetesCluster*/Environment/**Name**)

(Erforderlich, falls [Environment](#deploy.action.eks.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="deploy.action.eks.environment.connections"></a>

(*DeployToKubernetesCluster*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="deploy.action.eks.environment.connections.name"></a>

(*DeployToKubernetesCluster*/Environment/Connections/**Name**)

(Optional)

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="deploy.action.eks.environment.connections.role"></a>

(*DeployToKubernetesCluster*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#deploy.action.eks.environment.connections))

Geben Sie den Namen der IAM-Rolle an, auf die die **Clusteraktion Deploy to Kubernetes** zugreift. AWS Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf die in der folgenden Richtlinie angegebenen. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "eks:DescribeCluster",
                  "eks:ListClusters"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**Anmerkung**  
Wenn die Rolle zum ersten Mal verwendet wird, verwenden Sie den folgenden Platzhalter in der Ressourcenrichtlinienanweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

  ```
  "Resource": "*"
  ```
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

Stellen Sie sicher, dass diese Rolle hinzugefügt wurde zu:
+ Ihre Kontoverbindung. Weitere Informationen zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter[Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).
+ Ihr Kubernetes ConfigMap. Weitere Informationen zum Hinzufügen einer IAM-Rolle zu einer ConfigMap finden Sie in der Dokumentation unter [Verwalten von IAM-Benutzern und -Rollen](https://eksctl.io/usage/iam-identity-mappings/). `eksctl`

**Tipp**  
Anweisungen [Tutorial: Bereitstellen einer Anwendung in Amazon EKS](deploy-tut-eks.md) zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie auch unter. ConfigMap

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Inputs
<a name="deploy.action.eks.inputs"></a>

(*DeployToKubernetesCluster*/**Inputs**)

(Erforderlich, falls enthalten[Connections](#deploy.action.eks.environment.connections))

`Inputs`In diesem Abschnitt werden die Daten definiert, die während einer Workflow-Ausführung `DeployToKubernetesCluster` benötigt werden.

**Anmerkung**  
Pro Aktion „In **Amazon EKS bereitstellen**“ ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

## Sources
<a name="deploy.action.eks.inputs.sources"></a>

(*DeployToKubernetesCluster*/Inputs/**Sources**)

(Erforderlich, wenn Ihre Manifestdatei in einem Quell-Repository gespeichert ist)

Wenn Ihre Kubernetes-Manifestdatei (en) in einem Quell-Repository gespeichert sind, geben Sie die Bezeichnung dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label. `WorkflowSource`

Wenn Ihre Manifestdateien nicht in einem Quell-Repository enthalten sind, müssen sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="deploy.action.eks.inputs.artifacts"></a>

(*DeployToKubernetesCluster*/Inputs/**Artifacts**)

(Erforderlich, wenn Ihre Manifestdatei in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer früheren Aktion gespeichert ist)

Wenn die Kubernetes-Manifestdatei (en) in einem Artefakt enthalten sind, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Wenn Ihre Manifestdateien nicht in einem Artefakt enthalten sind, müssen sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Configuration
<a name="deploy.action.eks.configuration"></a>

(*DeployToKubernetesCluster*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## Namespace
<a name="deploy.action.eks.namespace"></a>

(*DeployToKubernetesCluster*/Configuration/**Namespace**)

(Optional)

Geben Sie den Kubernetes-Namespace an, in dem Ihre Kubernetes-Anwendung bereitgestellt wird. Verwenden Sie diese Option`default`, wenn Sie in Ihrem Cluster keine Namespaces verwenden. Weitere Informationen zu Namespaces finden Sie in der Kubernetes-Dokumentation unter [Unterteilung Ihres Clusters mithilfe](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#subdividing-your-cluster-using-kubernetes-namespaces) von Kubernetes-Namespaces.

Wenn Sie den Namespace weglassen, wird der Wert von verwendet. `default`

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Namespace“**

## Region
<a name="deploy.action.eks.region"></a>

(*DeployToKubernetesCluster*/Configuration/**Region**)

(Erforderlich)

Geben Sie die AWS Region an, in der sich Ihr Amazon EKS-Cluster und -Service befinden. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes) in der. *Allgemeine AWS-Referenz*

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Region“**

## Cluster
<a name="deploy.action.eks.cluster"></a>

(*DeployToKubernetesCluster*/Configuration/**Cluster**)

(Erforderlich)

Geben Sie den Namen eines vorhandenen Amazon EKS-Clusters an. Mit der Aktion „**Auf Kubernetes-Cluster** bereitstellen“ wird Ihre containerisierte Anwendung in diesem Cluster bereitgestellt. Weitere Informationen zu Amazon EKS-Clustern finden Sie unter [Clusters](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html) im **Amazon EKS-Benutzerhandbuch**.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Cluster“**

## Manifests
<a name="deploy.action.eks.manifest"></a>

(*DeployToKubernetesCluster*/Configuration/**Manifests**)

(Erforderlich)

*Geben Sie den Pfad zu Ihren Kubernetes-Manifestdateien im YAML-Format an, die in der Kubernetes-Dokumentation als *Konfigurationsdateien, *Konfigurationsdateien* oder einfach als Konfigurationen* bezeichnet werden.*

Wenn Sie mehrere Manifestdateien verwenden, platzieren Sie sie in einem einzigen Ordner und verweisen Sie auf diesen Ordner. Manifestdateien werden von Kubernetes alphanumerisch verarbeitet. Stellen Sie daher sicher, dass Sie Dateinamen mit steigenden Zahlen oder Buchstaben voranstellen, um die Verarbeitungsreihenfolge zu kontrollieren. Beispiel:

`00-namespace.yaml`

`01-deployment.yaml`

Wenn sich Ihre Manifestdateien in Ihrem Quell-Repository befinden, ist der Pfad relativ zum Stammordner des Quell-Repositorys. Wenn sich die Dateien in einem Artefakt aus einer früheren Workflow-Aktion befinden, ist der Pfad relativ zum Artefakt-Stammordner. 

Beispiele:

`Manifests/`

`deployment.yaml`

`my-deployment.yml`

Verwenden Sie keine Platzhalter (). `*`

**Anmerkung**  
[Helm-Diagramme](https://helm.sh/docs/topics/charts/) und [Anpassungsdateien](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) werden nicht unterstützt.

Weitere Informationen zu Manifestdateien finden Sie in der [Kubernetes-Dokumentation unter Organisieren von Ressourcenkonfigurationen](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#organizing-resource-configurations).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Manifeste“**

# Einen CloudFormation Stack bereitstellen
<a name="deploy-action-cfn"></a>

In diesem Abschnitt wird beschrieben, wie Sie einen AWS CloudFormation Stack mithilfe eines CodeCatalyst Workflows bereitstellen. Um dies zu erreichen, müssen Sie Ihrem Workflow die Aktion ** CloudFormation Stack bereitstellen** hinzufügen. Die Aktion stellt einen CloudFormation Stapel von Ressourcen bereit, der auf einer von Ihnen bereitgestellten Vorlage AWS basiert. Die Vorlage kann eine sein:
+ CloudFormation Vorlage — Weitere Informationen finden Sie unter [Mit CloudFormation Vorlagen arbeiten](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html).
+ AWS SAM Vorlage — Weitere Informationen finden Sie in der [AWS Serverless Application Model (AWS SAM) -Spezifikation](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html).
**Anmerkung**  
Um eine AWS SAM Vorlage verwenden zu können, müssen Sie zuerst Ihre AWS SAM Anwendung mithilfe des `[sam package](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html)` Vorgangs paketieren. Ein Tutorial, das Ihnen zeigt, wie Sie dieses Verpacken im Rahmen eines CodeCatalyst Amazon-Workflows automatisch durchführen, finden Sie unter[Tutorial: Eine serverlose Anwendung bereitstellen](deploy-tut-lambda.md).

Wenn der Stapel bereits vorhanden ist, führt die Aktion den CloudFormation `[CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html)` Vorgang und dann den `[ExecuteChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ExecuteChangeSet.html)` Vorgang aus. Die Aktion wartet dann auf die Bereitstellung der Änderungen und markiert sich je nach Ergebnis entweder als erfolgreich oder als fehlgeschlagen.

Verwenden Sie die Aktion ** CloudFormation Stack bereitstellen**, wenn Sie bereits über eine CloudFormation AWS SAM Oder-Vorlage verfügen, die Ressourcen enthält, die Sie bereitstellen möchten, oder wenn Sie planen, im Rahmen einer [Workflow-Build-Aktion](build-add-action.md) mithilfe von Tools wie AWS SAM und [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)automatisch eine Vorlage zu generieren.

Es gibt keine Einschränkungen hinsichtlich der Vorlage, die Sie verwenden können — unabhängig davon, welche Vorlage Sie verwenden können, CloudFormation oder die AWS SAM Sie zusammen mit der Aktion „** CloudFormation Stack bereitstellen**“ verwenden können.

**Tipp**  
Ein Tutorial, das Ihnen zeigt, wie Sie eine serverlose Anwendung mithilfe der Aktion „** CloudFormation Stack bereitstellen“ bereitstellen**, finden Sie unter. [Tutorial: Eine serverlose Anwendung bereitstellen](deploy-tut-lambda.md)

**Topics**
+ [

## Runtime-Image, das von der Aktion „Stack bereitstellen“ CloudFormation verwendet wird
](#deploy-action-cfn-runtime)
+ [

# Tutorial: Eine serverlose Anwendung bereitstellen
](deploy-tut-lambda.md)
+ [

# Aktion „ CloudFormation Stapel bereitstellen“ hinzufügen
](deploy-action-cfn-adding.md)
+ [

# Rollbacks konfigurieren
](deploy-consumption-enable-alarms.md)
+ [

# CloudFormation 'Stack'-Variablen bereitstellen
](deploy-action-cfn-variables.md)
+ [

# Aktion CloudFormation 'Stack bereitstellen' YAML
](deploy-action-ref-cfn.md)

## Runtime-Image, das von der Aktion „Stack bereitstellen“ CloudFormation verwendet wird
<a name="deploy-action-cfn-runtime"></a>

Die Aktion ** CloudFormation Stack bereitstellen** wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Tutorial: Eine serverlose Anwendung bereitstellen
<a name="deploy-tut-lambda"></a>

In diesem Tutorial erfahren Sie, wie Sie mithilfe eines Workflows eine serverlose Anwendung als CloudFormation Stack erstellen, testen und bereitstellen.

Die Anwendung in diesem Tutorial ist eine einfache Webanwendung, die eine „Hello World“ -Nachricht ausgibt. Es besteht aus einer AWS Lambda Funktion und einem Amazon API Gateway, und Sie erstellen es mit der [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html), einer Erweiterung von [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).

**Topics**
+ [

## Voraussetzungen
](#deploy-tut-lambda-cfn-prereqs)
+ [

## Schritt 1: Erstellen Sie ein Quell-Repository
](#deploy-tut-lambda-cfn-source)
+ [

## Schritt 2: AWS Rollen erstellen
](#deploy-tut-lambda-cfn-roles)
+ [

## Schritt 3: AWS Rollen hinzufügen CodeCatalyst
](#deploy-tut-lambda-cfn-roles-add)
+ [

## Schritt 4: Erstellen Sie einen Amazon S3 S3-Bucket
](#deploy-tut-lambda-cfn-s3)
+ [

## Schritt 5: Quelldateien hinzufügen
](#deploy-tut-lambda-cfn-files)
+ [

## Schritt 6: Einen Workflow erstellen und ausführen
](#deploy-tut-lambda-cfn-workflow)
+ [

## Schritt 7: Nehmen Sie eine Änderung vor
](#deploy-tut-lambda-cfn-change)
+ [

## Bereinigen
](#deploy-tut-lambda-cfn-clean-up)

## Voraussetzungen
<a name="deploy-tut-lambda-cfn-prereqs"></a>

Bevor Sie beginnen:
+ Sie benötigen einen CodeCatalyst **Bereich** mit einem verbundenen AWS Konto. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In Ihrem Bereich benötigen Sie ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-cfn-project
  ```

  Verwenden Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).
+ In Ihrem Projekt benötigen Sie eine CodeCatalyst **Umgebung** mit dem Namen:

  ```
  codecatalyst-cfn-environment
  ```

  Konfigurieren Sie diese Umgebung wie folgt:
  + Wählen Sie einen beliebigen Typ, z. B. „Keine **Produktion**“.
  + Connect dein AWS Konto damit.
  + Wählen Sie für die **Standard-IAM-Rolle eine** beliebige Rolle aus. Sie werden später eine andere Rolle angeben.

  Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).

## Schritt 1: Erstellen Sie ein Quell-Repository
<a name="deploy-tut-lambda-cfn-source"></a>

In diesem Schritt erstellen Sie ein Quell-Repository in CodeCatalyst. Dieses Repository wird verwendet, um die Quelldateien des Tutorials zu speichern, z. B. die Lambda-Funktionsdatei. 

Weitere Hinweise zu Quell-Repositorys finden Sie unter. [Erstellen eines Quell-Repositorys](source-repositories-create.md)

**Um ein Quell-Repository zu erstellen**

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus. CodeCatalyst 

1. Wählen **Sie Repository hinzufügen** und anschließend **Repository erstellen** aus.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   codecatalyst-cfn-source-repository
   ```

1. Wählen Sie **Erstellen** aus.

Sie haben jetzt ein Repository mit dem Namen erstellt`codecatalyst-cfn-source-repository`.

## Schritt 2: AWS Rollen erstellen
<a name="deploy-tut-lambda-cfn-roles"></a>

In diesem Schritt erstellen Sie die folgenden AWS IAM-Rollen:
+ **Rolle bereitstellen** — Erteilt der Aktion „** CloudFormation Stack CodeCatalyst bereitstellen**“ die Berechtigung, auf Ihr AWS Konto und Ihren CloudFormation Dienst zuzugreifen, in dem Sie Ihre serverlose Anwendung bereitstellen werden. Die Aktion ** CloudFormation Stack bereitstellen** ist Teil Ihres Workflows.
+ **Build-Rolle** — Erteilt der CodeCatalyst Build-Aktion die Berechtigung, auf Ihr AWS Konto zuzugreifen und in Amazon S3 zu schreiben, wo Ihr serverloses Anwendungspaket gespeichert wird. Die Build-Aktion ist Teil Ihres Workflows.
+ **Stack-Rolle** — Erteilt die CloudFormation Berechtigung zum Lesen und Ändern der Ressourcen, die in der AWS SAM Vorlage angegeben sind, die Sie später bereitstellen werden. Erteilt auch die Erlaubnis für CloudWatch.

Weitere Informationen zu IAM-Rollen finden Sie unter [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) im *AWS Identity and Access Management Benutzerhandbuch*.

**Anmerkung**  
Um Zeit zu sparen, können Sie anstelle der drei zuvor aufgeführten Rollen eine einzelne `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle, die so genannte Rolle, erstellen. Weitere Informationen finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über sehr umfangreiche Berechtigungen verfügt, die ein Sicherheitsrisiko darstellen können. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. In diesem Tutorial wird davon ausgegangen, dass Sie die drei zuvor aufgeführten Rollen erstellen.

**Anmerkung**  
Eine [Lambda-Ausführungsrolle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) ist ebenfalls erforderlich, aber Sie müssen sie jetzt nicht erstellen, da die `sam-template.yml` Datei sie für Sie erstellt, wenn Sie den Workflow in Schritt 5 ausführen.



**Um eine Bereitstellungsrolle zu erstellen**

1. Erstellen Sie wie folgt eine Richtlinie für die Rolle:

   1. Melden Sie sich an bei AWS.

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Wählen Sie im Navigationsbereich **Richtlinien**.

   1. Wählen Sie **Richtlinie erstellen** aus.

   1. Wählen Sie den Tab **JSON**.

   1. Löschen Sie den vorhandenen Code.

   1. Fügen Sie folgenden Code ein:
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.

   1. Klicken Sie auf **Weiter: Prüfen**.

   1. Geben Sie im Feld **Name** Folgendes ein:

      ```
      codecatalyst-deploy-policy
      ```

   1. Wählen Sie **Richtlinie erstellen** aus.

      Sie haben jetzt eine Berechtigungsrichtlinie erstellt.

1. Erstellen Sie die Bereitstellungsrolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.

   1. Wählen Sie **Benutzerdefinierte Vertrauensrichtlinie**.

   1. Löschen Sie die bestehende benutzerdefinierte Vertrauensrichtlinie.

   1. Fügen Sie die folgende benutzerdefinierte Vertrauensrichtlinie hinzu:

   1. Wählen Sie **Weiter** aus.

   1. Suchen Sie **unter Berechtigungsrichtlinien** nach dem entsprechenden Kontrollkästchen `codecatalyst-deploy-policy` und aktivieren Sie es.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-deploy-role
      ```

   1. Geben Sie **als Rollenbeschreibung** Folgendes ein:

      ```
      CodeCatalyst deploy role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

   Sie haben jetzt eine Bereitstellungsrolle mit einer Vertrauensrichtlinie und einer Berechtigungsrichtlinie erstellt.

1. Rufen Sie den ARN für die Bereitstellungsrolle wie folgt ab:

   1. Wählen Sie im Navigationsbereich **Rollen**.

   1. Geben Sie im Suchfeld den Namen der Rolle ein, die Sie gerade erstellt haben (`codecatalyst-deploy-role`).

   1. Wählen Sie die Rolle aus der Liste aus.

      Die **Übersichtsseite** der Rolle wird angezeigt.

   1. Kopieren Sie oben den **ARN-Wert**.

   Sie haben jetzt die Bereitstellungsrolle mit den entsprechenden Berechtigungen erstellt und ihren ARN abgerufen.

**Um eine Build-Rolle zu erstellen**

1. Erstellen Sie wie folgt eine Richtlinie für die Rolle:

   1. Melden Sie sich an bei AWS.

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Wählen Sie im Navigationsbereich **Richtlinien**.

   1. Wählen Sie **Richtlinie erstellen** aus.

   1. Wählen Sie den Tab **JSON**.

   1. Löschen Sie den vorhandenen Code.

   1. Fügen Sie folgenden Code ein:
**Anmerkung**  
Wenn die Rolle zum ersten Mal zum Ausführen von Workflow-Aktionen verwendet wird, verwenden Sie den Platzhalter in der Ressourcenrichtlinien-Anweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

      ```
      "Resource": "*"
      ```

   1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.

   1. Klicken Sie auf **Weiter: Prüfen**.

   1. Geben Sie im Feld **Name** Folgendes ein:

      ```
      codecatalyst-build-policy
      ```

   1. Wählen Sie **Richtlinie erstellen** aus.

      Sie haben jetzt eine Berechtigungsrichtlinie erstellt.

1. Erstellen Sie die Build-Rolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.

   1. Wählen Sie **Benutzerdefinierte Vertrauensrichtlinie**.

   1. Löschen Sie die bestehende benutzerdefinierte Vertrauensrichtlinie.

   1. Fügen Sie die folgende benutzerdefinierte Vertrauensrichtlinie hinzu:

   1. Wählen Sie **Weiter** aus.

   1. Suchen Sie **unter Berechtigungsrichtlinien** nach dem entsprechenden Kontrollkästchen `codecatalyst-build-policy` und aktivieren Sie es.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-build-role
      ```

   1. Geben Sie **als Rollenbeschreibung** Folgendes ein:

      ```
      CodeCatalyst build role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

   Sie haben jetzt eine Build-Rolle mit einer Vertrauensrichtlinie und einer Berechtigungsrichtlinie erstellt.

1. Rufen Sie den ARN für die Build-Rolle wie folgt ab:

   1. Wählen Sie im Navigationsbereich **Rollen**.

   1. Geben Sie im Suchfeld den Namen der Rolle ein, die Sie gerade erstellt haben (`codecatalyst-build-role`).

   1. Wählen Sie die Rolle aus der Liste aus.

      Die **Übersichtsseite** der Rolle wird angezeigt.

   1. Kopieren Sie oben den **ARN-Wert**.

   Sie haben jetzt die Build-Rolle mit den entsprechenden Berechtigungen erstellt und ihren ARN abgerufen.<a name="deploy-tut-lambda-cfn-roles-stack"></a>

**Um eine Stack-Rolle zu erstellen**

1. Melden Sie sich AWS mit dem Konto an, in dem Sie Ihren Stack bereitstellen möchten.

1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

1. Erstellen Sie die Stack-Rolle wie folgt:

   1. Wählen Sie im Navigationsbereich **Rollen** aus.

   1. Wählen Sie **Create role** (Rolle erstellen) aus.

   1. Wählen Sie einen **AWS -Service** aus.

   1. Wählen **Sie im Abschnitt Anwendungsfall** eine Option **CloudFormation**aus der Drop-down-Liste aus.

   1. Wählen Sie das Optionsfeld **CloudFormation**.

   1. Wählen Sie unten **Weiter** aus.

   1. Suchen Sie mithilfe des Suchfeldes nach den folgenden Berechtigungsrichtlinien und aktivieren Sie dann die entsprechenden Kontrollkästchen.
**Anmerkung**  
Wenn Sie nach einer Richtlinie suchen und sie nicht angezeigt wird, wählen Sie **Filter löschen** aus und versuchen Sie es erneut.
      + **CloudWatchFullAccess**
      + **AWS CloudFormationFullAccess**
      + **IAMFullAccess**
      + **AWS Lambda\$1 FullAccess**
      + **APIGatewayAmazon-Administrator**
      + **Amazon S3 FullAccess**
      + **AmazonEC2ContainerRegistryFullAccess**

      Die erste Richtlinie ermöglicht den Zugriff auf Stack-Rollbacks, CloudWatch um Stack-Rollbacks zu aktivieren, wenn ein Alarm auftritt.

      Die verbleibenden Richtlinien ermöglichen den AWS SAM Zugriff auf die Dienste und Ressourcen im Stack, die in diesem Tutorial bereitgestellt werden. Weitere Informationen finden Sie unter [Berechtigungen](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html) im *AWS Serverless Application Model Entwicklerhandbuch*.

   1. Wählen Sie **Weiter** aus.

   1. Geben Sie **als Rollenname** Folgendes ein:

      ```
      codecatalyst-stack-role
      ```

   1. Wählen Sie **Rolle erstellen** aus.

1. Rufen Sie den ARN der Stack-Rolle wie folgt ab:

   1. Wählen Sie im Navigationsbereich **Rollen**.

   1. Geben Sie im Suchfeld den Namen der Rolle ein, die Sie gerade erstellt haben (`codecatalyst-stack-role`).

   1. Wählen Sie die Rolle aus der Liste aus.

   1. Kopieren Sie im Abschnitt **Zusammenfassung** den **ARN-Wert**. Sie benötigen sie später.

   Sie haben jetzt die Stack-Rolle mit den entsprechenden Berechtigungen erstellt und ihren ARN abgerufen.

## Schritt 3: AWS Rollen hinzufügen CodeCatalyst
<a name="deploy-tut-lambda-cfn-roles-add"></a>

In diesem Schritt fügen Sie der CodeCatalyst Kontoverbindung in Ihrem Bereich die Build-Rolle (`codecatalyst-build-role``codecatalyst-deploy-role`) und die Bereitstellungsrolle () hinzu.

**Anmerkung**  
Sie müssen die Stack-Rolle (`codecatalyst-stack-role`) nicht zur Verbindung hinzufügen. Das liegt daran, dass die Stack-Rolle von *CloudFormation*(nicht CodeCatalyst) verwendet wird, *nachdem* bereits eine Verbindung zwischen CodeCatalyst und AWS unter Verwendung der Deploy-Rolle hergestellt wurde. Da die Stack-Rolle nicht für den CodeCatalyst Zugriff verwendet wird AWS, muss sie keiner Kontoverbindung zugeordnet werden.

**Um Ihrer Kontoverbindung Rollen hinzuzufügen, zu erstellen und bereitzustellen**

1. Navigieren CodeCatalyst Sie darin zu Ihrem Bereich.

1. Wählen Sie **AWS accounts (-Konten)**. Eine Liste der Kontoverbindungen wird angezeigt.

1. Wählen Sie die Kontoverbindung aus, die dem AWS Konto entspricht, in dem Sie Ihre Build- und Deploy-Rollen erstellt haben.

1. Wählen Sie in der ** AWS Managementkonsole die Option Rollen verwalten aus**.

   Die Seite „**IAM-Rolle zu Amazon CodeCatalyst Space hinzufügen**“ wird angezeigt. Möglicherweise müssen Sie sich anmelden, um auf die Seite zuzugreifen.

1. Wählen Sie **Eine bestehende Rolle hinzufügen, die Sie in IAM erstellt haben**.

   Eine Dropdownliste wird angezeigt. In der Liste werden alle IAM-Rollen mit einer Vertrauensrichtlinie angezeigt, die die Dienstprinzipale `codecatalyst-runner.amazonaws.com` und die `codecatalyst.amazonaws.com` Dienstprinzipale umfasst.

1. Wählen Sie in der Dropdownliste die Option und `codecatalyst-build-role` anschließend Rolle **hinzufügen** aus.

1. Wählen Sie **IAM-Rolle hinzufügen** aus, wählen Sie **Vorhandene Rolle hinzufügen, die Sie in IAM erstellt haben**, und wählen Sie in der Drop-down-Liste die Option aus. `codecatalyst-deploy-role` Wählen Sie **Rolle hinzufügen** aus.

   Sie haben jetzt die Build- und Deploy-Rollen zu Ihrem Bereich hinzugefügt.

1. Kopieren Sie den Wert des ** CodeCatalyst Amazon-Anzeigenamens**. Sie benötigen diesen Wert später, wenn Sie Ihren Workflow erstellen.

## Schritt 4: Erstellen Sie einen Amazon S3 S3-Bucket
<a name="deploy-tut-lambda-cfn-s3"></a>

In diesem Schritt erstellen Sie einen Amazon S3 S3-Bucket, in dem Sie die ZIP-Datei des Bereitstellungspakets Ihrer serverlosen Anwendung speichern.

**So erstellen Sie einen Amazon-S3-Bucket**

1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Wählen Sie im Hauptbereich **Create Bucket** aus.

1. Geben Sie als **Bucket-Namen** Folgendes ein:

   ```
   codecatalyst-cfn-s3-bucket
   ```

1. Wählen Sie unter **AWS -Region** eine Region aus. In diesem Tutorial wird davon ausgegangen, dass Sie **US West (Oregon) us-west-2** ausgewählt haben. Informationen zu den von Amazon S3 unterstützten Regionen finden Sie unter [Amazon Simple Storage Service-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/s3.html) in der *Allgemeine AWS-Referenz*.

1. Wählen Sie unten auf der Seite die Option **Bucket erstellen** aus.

Sie haben jetzt einen Bucket mit dem Namen **codecatalyst-cfn-s3-bucket** in der Region USA West (Oregon) us-west-2 erstellt.

## Schritt 5: Quelldateien hinzufügen
<a name="deploy-tut-lambda-cfn-files"></a>

In diesem Schritt fügen Sie Ihrem CodeCatalyst Quell-Repository mehrere Anwendungsquelldateien hinzu. Der `hello-world` Ordner enthält die Anwendungsdateien, die Sie bereitstellen werden. Der `tests` Ordner enthält Komponententests. Die Ordnerstruktur ist wie folgt:

```
.
|— hello-world
|  |— tests
|     |— unit
|        |— test-handler.js
|  |— app.js
|— .npmignore
|— package.json
|— sam-template.yml
|— setup-sam.sh
```

### .npmignore-Datei
<a name="deploy-tut-lambda-cfn-files-npmignore"></a>

Die `.npmignore` Datei gibt an, welche Dateien und Ordner npm aus dem Anwendungspaket ausschließen soll. In diesem Tutorial schließt npm den `tests` Ordner aus, da er nicht Teil der Anwendung ist.

**Um die Datei „.npmignore“ hinzuzufügen**

1. [Öffnen Sie die CodeCatalyst Konsole unter https://codecatalyst.aws/.](https://codecatalyst.aws/)

1. Wähle dein Projekt, `codecatalyst-cfn-project`

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus.

1. Wählen Sie aus der Liste der Quell-Repositorys Ihr Repository aus. `codecatalyst-cfn-source-repository` 

1. Wählen Sie unter **Dateien** die Option **Datei erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   .npmignore
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   tests/*
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt eine Datei mit dem Namen `.npmignore` im Stammverzeichnis Ihres Repositorys erstellt.

### package.json-Datei
<a name="deploy-tut-lambda-cfn-files-package-json"></a>

Die `package.json` Datei enthält wichtige Metadaten zu Ihrem Node-Projekt wie Projektname, Versionsnummer, Beschreibung, Abhängigkeiten und andere Details, die beschreiben, wie Sie mit Ihrer Anwendung interagieren und sie ausführen.

Die `package.json` in diesem Tutorial enthaltene Liste enthält eine Liste von Abhängigkeiten und ein `test` Skript. Das Testskript macht Folgendes:
+ Unter Verwendung von [Mocha](https://mochajs.org/) führt das Testskript die in angegebenen Komponententests aus `hello-world/tests/unit/` und schreibt die Ergebnisse mithilfe des [Xunit-Reporters]() in eine `junit.xml` Datei.
+ [Unter Verwendung von [Istanbul (NYC)](https://istanbul.js.org/) generiert das Testskript mithilfe des Clover Reporters einen Bericht über die Codeabdeckung (`clover.xml`).](https://openclover.org/doc/manual/4.2.0/general--about-openclover.html) Weitere Informationen finden Sie in der [Istanbul-Dokumentation unter Verwenden alternativer Reporter](https://istanbul.js.org/docs/advanced/alternative-reporters/#clover).

**Um die Datei package.json hinzuzufügen**

1. **Wählen Sie in Ihrem Repository unter **Dateien** die Option Datei erstellen aus.**

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   package.json
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   {
     "name": "hello_world",
     "version": "1.0.0",
     "description": "hello world sample for NodeJS",
     "main": "app.js",
     "repository": "https://github.com/awslabs/aws-sam-cli/tree/develop/samcli/local/init/templates/cookiecutter-aws-sam-hello-nodejs",
     "author": "SAM CLI",
     "license": "MIT",
     "dependencies": {
       "axios": "^0.21.1",
       "nyc": "^15.1.0"
     },
     "scripts": {
       "test": "nyc --reporter=clover mocha hello-world/tests/unit/ --reporter xunit --reporter-option output=junit.xml"
     },
     "devDependencies": {
       "aws-sdk": "^2.815.0",
       "chai": "^4.2.0",
       "mocha": "^8.2.1"
     }
   }
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt eine Datei mit dem Namen `package.json` zum Stammverzeichnis des Repositorys hinzugefügt.

### Datei sam-template.yml
<a name="deploy-tut-lambda-cfn-files-sam-template-yml"></a>

Die `sam-template.yml` Datei enthält die Anweisungen für die Bereitstellung der Lambda-Funktion und des API Gateway und deren gemeinsame Konfiguration. Sie folgt der [AWS Serverless Application Model Vorlagenspezifikation](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html), die die CloudFormation Vorlagenspezifikation erweitert.

In diesem Tutorial verwenden Sie eine AWS SAM Vorlage anstelle einer regulären CloudFormation Vorlage, da sie einen hilfreichen [AWS: :Serverless: :Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) Ressourcentyp AWS SAM bietet. Dieser Typ führt viele behind-the-scenes Konfigurationen durch, die Sie normalerweise ausschreiben müssen, um die grundlegende Syntax zu verwenden. CloudFormation Beispielsweise `AWS::Serverless::Function` erstellt der eine Lambda-Funktion, eine Lambda-Ausführungsrolle und Ereignisquellenzuordnungen, mit denen die Funktion gestartet wird. Sie müssen all das programmieren, wenn Sie es mit Basic schreiben möchten. CloudFormation

In diesem Tutorial wird zwar eine vorgefertigte Vorlage verwendet, Sie können jedoch eine Vorlage als Teil Ihres Workflows mithilfe einer Build-Aktion generieren. Weitere Informationen finden Sie unter [Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md).

**Um die Datei sam-template.yml hinzuzufügen**

1. **Wählen Sie in Ihrem Repository unter **Dateien** die Option Datei erstellen aus.**

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   sam-template.yml
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   AWSTemplateFormatVersion: '2010-09-09'
   Transform: AWS::Serverless-2016-10-31
   Description: >
     serverless-api
   
     Sample SAM Template for serverless-api
     
   # More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
   Globals:
     Function:
       Timeout: 3
   
   Resources:
     HelloWorldFunction:
       Type: AWS::Serverless::Function # For details on this resource type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
       Properties:
         CodeUri: hello-world/
         Handler: app.lambdaHandler
         Runtime: nodejs12.x
         Events:
           HelloWorld:
             Type: Api # For details on this event source type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
             Properties:
               Path: /hello
               Method: get
   
   Outputs:
     # ServerlessRestApi is an implicit API created out of the events key under Serverless::Function
     # Find out about other implicit resources you can reference within AWS SAM at
     # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
     HelloWorldApi:
       Description: "API Gateway endpoint URL for the Hello World function"
       Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
     HelloWorldFunction:
       Description: "Hello World Lambda function ARN"
       Value: !GetAtt HelloWorldFunction.Arn
     HelloWorldFunctionIamRole:
       Description: "Implicit Lambda execution role created for the Hello World function"
       Value: !GetAtt HelloWorldFunctionRole.Arn
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt eine Datei mit `sam-template.yml` dem Namen im Stammordner Ihres Repositorys hinzugefügt.

### Datei setup-sam.sh
<a name="deploy-tut-lambda-cfn-files-setup-sam"></a>

Die `setup-sam.sh` Datei enthält Anweisungen zum Herunterladen und Installieren des AWS SAM CLI-Dienstprogramms. Der Workflow verwendet dieses Hilfsprogramm, um die `hello-world` Quelle zu verpacken.

**Um die Datei setup-sam.sh hinzuzufügen**

1. Wählen Sie in Ihrem Repository unter **Dateien** die Option **Datei erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   setup-sam.sh
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   #!/usr/bin/env bash
   echo "Setting up sam"
   
   yum install unzip -y
   
   curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip
   unzip -qq aws-sam-cli-linux-x86_64.zip -d sam-installation-directory
   
   ./sam-installation-directory/install; export AWS_DEFAULT_REGION=us-west-2
   ```

   Ersetzen Sie den Code im vorherigen Code *us-west-2* durch Ihre AWS Region.

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt eine Datei mit dem Namen `setup-sam.sh` zum Stammverzeichnis des Repositorys hinzugefügt.

### Datei app.js
<a name="deploy-tut-lambda-cfn-files-app-js"></a>

Das `app.js` enthält den Lambda-Funktionscode. In diesem Tutorial gibt der Code den Text `hello world` zurück.

**Um die Datei app.js hinzuzufügen**

1. Wählen Sie in Ihrem Repository unter **Dateien** die Option **Datei erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   hello-world/app.js
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   // const axios = require('axios')
   // const url = 'http://checkip.amazonaws.com/';
   let response;
   
   /**
    *
    * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
    * @param {Object} event - API Gateway Lambda Proxy Input Format
    *
    * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html 
    * @param {Object} context
    *
    * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
    * @returns {Object} object - API Gateway Lambda Proxy Output Format
    * 
    */
   exports.lambdaHandler = async (event, context) => {
       try {
           // const ret = await axios(url);
           response = {
               'statusCode': 200,
               'body': JSON.stringify({
                   message: 'hello world',
                   // location: ret.data.trim()
               })
           }
       } catch (err) {
           console.log(err);
           return err;
       }
   
       return response
   };
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt einen Ordner mit dem Namen `hello-world` und eine Datei mit dem Namen erstellt`app.js`.

### Datei test-handler.js
<a name="deploy-tut-lambda-cfn-files-test-handler-js"></a>

Die `test-handler.js` Datei enthält Komponententests für die Lambda-Funktion.

**Um die Datei test-handler.js hinzuzufügen**

1. Wählen Sie in Ihrem Repository unter **Dateien** die Option **Datei erstellen** aus.

1. Geben Sie als **Dateiname** Folgendes ein:

   ```
   hello-world/tests/unit/test-handler.js
   ```

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   'use strict';
   
   const app = require('../../app.js');
   const chai = require('chai');
   const expect = chai.expect;
   var event, context;
   
   describe('Tests index', function () {
       it('verifies successful response', async () => {
           const result = await app.lambdaHandler(event, context)
   
           expect(result).to.be.an('object');
           expect(result.statusCode).to.equal(200);
           expect(result.body).to.be.an('string');
   
           let response = JSON.parse(result.body);
   
           expect(response).to.be.an('object');
           expect(response.message).to.be.equal("hello world");
           // expect(response.location).to.be.an("string");
       });
   });
   ```

1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

   Sie haben jetzt eine Datei mit `test-handler.js` dem Namen unter dem `hello-world/tests/unit` Ordner hinzugefügt.

Sie haben jetzt alle Ihre Quelldateien hinzugefügt.

Nehmen Sie sich einen Moment Zeit, um Ihre Arbeit zu überprüfen und sicherzustellen, dass Sie alle Dateien in den richtigen Ordnern abgelegt haben. Die Ordnerstruktur ist wie folgt:

```
.
|— hello-world
|  |— tests
|     |— unit
|        |— test-handler.js
|  |— app.js
|— .npmignore
|— README.md
|— package.json
|— sam-template.yml
|— setup-sam.sh
```

## Schritt 6: Einen Workflow erstellen und ausführen
<a name="deploy-tut-lambda-cfn-workflow"></a>

In diesem Schritt erstellen Sie einen Workflow, der Ihren Lambda-Quellcode verpackt und bereitstellt. Der Workflow besteht aus den folgenden Bausteinen, die sequentiell ausgeführt werden:
+ Ein Trigger — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine Testaktion (`Test`) — Beim Trigger installiert diese Aktion den [Node-Paketmanager (npm)](https://www.npmjs.com/) und führt dann den `npm run test` Befehl aus. Dieser Befehl weist npm an, das in der `test` Datei definierte Skript auszuführen. `package.json` Das `test` Skript wiederum führt die Komponententests aus und generiert zwei Berichte: einen Testbericht (`junit.xml`) und einen Bericht über die Codeabdeckung (`clover.xml`). Weitere Informationen finden Sie unter [package.json-Datei](#deploy-tut-lambda-cfn-files-package-json).

  Als Nächstes wandelt die Testaktion die XML-Berichte in CodeCatalyst Berichte um und zeigt sie in der CodeCatalyst Konsole auf der Registerkarte **Berichte** der Testaktion an.

  Weitere Informationen zur Testaktion finden Sie unter[Testen mit WorkflowsTesten mit Workflows](test-workflow-actions.md).
+ Eine Build-Aktion (`BuildBackend`) — Nach Abschluss der Testaktion lädt die Build-Aktion die AWS SAM CLI herunter und installiert sie, packt die `hello-world` Quelle und kopiert das Paket in Ihren Amazon S3 S3-Bucket, wo es vom Lambda-Service erwartet wird. Die Aktion gibt auch eine neue AWS SAM Vorlagendatei namens aus `sam-template-packaged.yml` und platziert sie in einem Ausgabeartefakt namens. `buildArtifact`

  Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).
+ Eine Bereitstellungsaktion (`DeployCloudFormationStack`) — Nach Abschluss der Build-Aktion sucht die Bereitstellungsaktion nach dem von der Build-Aktion (`buildArtifact`) generierten Ausgabeartefakt, findet die darin enthaltene AWS SAM Vorlage und führt dann die Vorlage aus. Die AWS SAM Vorlage erstellt einen Stack, der die serverlose Anwendung bereitstellt.

**So erstellen Sie ein Workflow**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

1. Wählen Sie für **Quell-Repository**`codecatalyst-cfn-source-repository`.

1. Wählen Sie für **Branch**`main`.

1. Wählen Sie **Erstellen** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie den folgenden YAML-Code hinzu:
**Anmerkung**  
Im folgenden YAML-Code können Sie die `Connections:` Abschnitte weglassen, wenn Sie möchten. Wenn Sie diese Abschnitte weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle angegebene Rolle** in Ihrer Umgebung die Berechtigungen und Vertrauensrichtlinien beider Rollen enthält, die unter beschrieben sind. [Schritt 2: AWS Rollen erstellen](#deploy-tut-lambda-cfn-roles) Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)

   ```
   Name: codecatalyst-cfn-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main   
   Actions:
     Test:
       Identifier: aws/managed-test@v1
       Inputs:
         Sources:
           - WorkflowSource
       Outputs:
         Reports:
           CoverageReport:
             Format: CLOVERXML
             IncludePaths:
               - "coverage/*"
           TestReport:
             Format: JUNITXML
             IncludePaths:
               - junit.xml
       Configuration:
         Steps:
           - Run: npm install
           - Run: npm run test  
     BuildBackend:
       Identifier: aws/build@v1
       DependsOn:
         - Test
       Environment:
         Name: codecatalyst-cfn-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-build-role
       Inputs:
         Sources:
           - WorkflowSource
       Configuration: 
         Steps:
           - Run: . ./setup-sam.sh
           - Run: sam package --template-file sam-template.yml --s3-bucket codecatalyst-cfn-s3-bucket --output-template-file sam-template-packaged.yml --region us-west-2
       Outputs:
         Artifacts:
           - Name: buildArtifact
             Files:
               - "**/*"
     DeployCloudFormationStack:
       Identifier: aws/cfn-deploy@v1
       DependsOn: 
         - BuildBackend
       Environment:
         Name: codecatalyst-cfn-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-deploy-role
       Inputs:
         Artifacts:
           - buildArtifact
         Sources: []
       Configuration:
         name: codecatalyst-cfn-stack
         region: us-west-2
         role-arn: arn:aws:iam::111122223333:role/StackRole
         template: ./sam-template-packaged.yml
         capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
   ```

   Ersetzen Sie im vorherigen Code:
   + Beide Instanzen von *codecatalyst-cfn-environment* mit dem Namen Ihrer Umgebung.
   + Beide Instanzen von *codecatalyst-account-connection* mit dem Anzeigenamen Ihrer Kontoverbindung. Der Anzeigename kann eine Zahl sein. Weitere Informationen finden Sie unter [Schritt 3: AWS Rollen hinzufügen CodeCatalyst](#deploy-tut-lambda-cfn-roles-add).
   + *codecatalyst-build-role*mit dem Namen der Build-Rolle, in der Sie erstellt haben[Schritt 2: AWS Rollen erstellen](#deploy-tut-lambda-cfn-roles).
   + *codecatalyst-cfn-s3-bucket*mit dem Namen des Amazon S3 S3-Buckets, in dem Sie ihn erstellt haben[Schritt 4: Erstellen Sie einen Amazon S3 S3-Bucket](#deploy-tut-lambda-cfn-s3).
   + Beide Instanzen *us-west-2* mit der Region, in der sich Ihr Amazon S3 S3-Bucket befindet (erste Instance), und in der Ihr Stack bereitgestellt wird (zweite Instance). Diese Regionen können unterschiedlich sein. In diesem Tutorial wird davon ausgegangen, dass beide Regionen auf eingestellt sind`us-west-2`. Einzelheiten zu den von Amazon S3 und CloudFormation unterstützten Regionen finden Sie unter [Service-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in der *Allgemeine AWS-Referenz*.
   + *codecatalyst-deploy-role*mit dem Namen der Bereitstellungsrolle, in [Schritt 2: AWS Rollen erstellen](#deploy-tut-lambda-cfn-roles) der Sie erstellt haben.
   + *codecatalyst-cfn-environment*mit dem Namen der Umgebung, in der Sie erstellt haben[Voraussetzungen](#deploy-tut-lambda-cfn-prereqs).
   + *arn:aws:iam::111122223333:role/StackRole*mit dem Amazon-Ressourcennamen (ARN) der Stack-Rolle, in der Sie erstellt haben[Schritt 2: AWS Rollen erstellen](#deploy-tut-lambda-cfn-roles).
**Anmerkung**  
Wenn Sie sich entschieden haben, keine Build-, Deployment- und Stack-Rollen zu erstellen *codecatalyst-build-role**codecatalyst-deploy-role*, ersetzen Sie, und *arn:aws:iam::111122223333:role/StackRole* durch den Namen oder ARN der `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle. Weitere Informationen über diese Rolle finden Sie unter [Schritt 2: AWS Rollen erstellen](#deploy-tut-lambda-cfn-roles).

   Informationen zu den Eigenschaften des zuvor gezeigten Codes finden Sie unter[Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.md).

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im **Dialogfeld „Workflow bestätigen**“ Folgendes ein:

   1. Behalten Sie als **Workflow-Dateiname** die Standardeinstellung bei`codecatalyst-cfn-workflow`.

   1. Geben Sie für **Commit-Nachricht** Folgendes ein:

      ```
      add initial workflow file
      ```

   1. Wählen Sie für **Repository **codecatalyst-cfn-source-repository****.

   1. Wählen Sie als **Branch-Name** die Option **main** aus.

   1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt einen Workflow erstellt. Eine Workflow-Ausführung wird aufgrund des oben im Workflow definierten Triggers automatisch gestartet. Insbesondere, als Sie die `codecatalyst-cfn-workflow.yaml` Datei in Ihr Quell-Repository übernommen (und per Push übertragen) haben, hat der Trigger die Workflow-Ausführung gestartet.

**Um den laufenden Workflow-Lauf zu sehen**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Workflow aus, den Sie gerade erstellt haben:. `codecatalyst-cfn-workflow`

1. Wählen Sie die Registerkarte „**Läufe**“.

1. Wählen Sie in der Spalte **Run-ID** die Run-ID aus.

1. Wählen Sie **Test**, um den Fortschritt der Tests zu sehen.

1. Wählen Sie **BuildBackend**, um den Baufortschritt zu sehen.

1. Wählen Sie **DeployCloudFormationStack**diese Option, um den Fortschritt der Bereitstellung zu sehen.

   Weitere Informationen zum Anzeigen von Ausführungsdetails finden Sie unter[Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

1. Wenn die **DeployCloudFormationStack**Aktion abgeschlossen ist, gehen Sie wie folgt vor:
   + Wenn die Workflow-Ausführung erfolgreich war, fahren Sie mit dem nächsten Verfahren fort.
   + Wenn die Workflow-Ausführung beim **Test** oder bei der **BuildBackend**Aktion fehlgeschlagen ist, wählen Sie **Protokolle** aus, um das Problem zu beheben.
   + Wenn die Workflow-Ausführung bei der **DeployCloudFormationStack**Aktion fehlgeschlagen ist, wählen Sie die Aktion „Bereitstellen“ und anschließend die Registerkarte „**Zusammenfassung**“. Scrollen Sie zum Abschnitt „**CloudFormation Ereignisse**“, um die detaillierte Fehlermeldung anzuzeigen. Wenn ein Rollback aufgetreten ist, löschen Sie den `codecatalyst-cfn-stack` Stack über die CloudFormation Konsole, AWS bevor Sie den Workflow erneut ausführen.

**Um die Bereitstellung zu überprüfen**

1. Wählen Sie nach einer erfolgreichen Bereitstellung in der horizontalen Menüleiste oben die Option **Variablen (7)** aus. (Wählen Sie im Bereich auf der rechten Seite nicht **Variablen** aus.)

1. Fügen Sie **HelloWorldApi**als Nächstes die `https://` URL in einen Browser ein.

   Eine **Hello-World-JSON-Meldung** von der Lambda-Funktion wird angezeigt, die darauf hinweist, dass der Workflow die Lambda-Funktion und das API Gateway erfolgreich bereitgestellt und konfiguriert hat.
**Tipp**  
Sie können diese URL mit einigen kleinen Konfigurationen im Workflow-Diagramm CodeCatalyst anzeigen lassen. Weitere Informationen finden Sie unter [Anzeige der App-URL im Workflow-Diagramm](deploy-app-url.md).

**Um die Ergebnisse der Komponententests und die Codeabdeckung zu überprüfen**

1. Wählen Sie im Workflow-Diagramm **Test** und dann **Berichte** aus.

1. Wählen **TestReport**Sie, ob Sie sich die Ergebnisse der Komponententests oder die Codeabdeckung der getesteten Dateien anzeigen lassen möchten **CoverageReport**, in diesem Fall `app.js` und`test-handler.js`.

**Um die bereitgestellten Ressourcen zu überprüfen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/). 

1. Beachten Sie die **codecatalyst-cfn-stack**API, die die AWS SAM Vorlage erstellt hat. Der API-Name stammt aus dem `Configuration/name` Wert in der Workflow-Definitionsdatei (`codecatalyst-cfn-workflow.yaml`).

1. Öffnen Sie die AWS Lambda Konsole unter [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Wählen Sie im Navigationsbereich **Funktionen** aus.

1. Wählen Sie Ihre Lambda-Funktion,`codecatalyst-cfn-stack-HelloWorldFunction-string`.

1. Sie können sehen, wie das API Gateway ein Auslöser für die Funktion ist. Diese Integration wurde automatisch nach dem AWS SAM `AWS::Serverless::Function` Ressourcentyp konfiguriert.

## Schritt 7: Nehmen Sie eine Änderung vor
<a name="deploy-tut-lambda-cfn-change"></a>

In diesem Schritt nehmen Sie eine Änderung an Ihrem Lambda-Quellcode vor und übernehmen diese. Mit diesem Commit wird ein neuer Workflow-Lauf gestartet. Bei diesem Lauf wird die neue Lambda-Funktion in einem blaugrünen Schema bereitgestellt, das die in der Lambda-Konsole angegebene Standardkonfiguration zur Verkehrsverlagerung verwendet.

**Um eine Änderung an Ihrer Lambda-Quelle vorzunehmen**

1. Navigieren Sie in CodeCatalyst zu Ihrem Projekt.

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus.

1. Wählen Sie Ihr Quell-Repository `codecatalyst-cfn-source-repository` aus.

1. Ändern Sie die Anwendungsdatei:

   1. Wählen Sie den Ordner `hello-world` aus.

   1. Wählen Sie die `app.js` Datei aus.

   1. Wählen Sie **Bearbeiten** aus.

   1. Wechseln Sie in Zeile 23 `hello world` zu**Tutorial complete\$1**.

   1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

      Durch den Commit wird ein Workflow-Lauf gestartet. Dieser Lauf schlägt fehl, weil Sie die Komponententests nicht aktualisiert haben, um die Namensänderung widerzuspiegeln.

1. Aktualisieren Sie die Komponententests:

   1. Wählen Sie `hello-world\tests\unit\test-handler.js`.

   1. Wählen Sie **Bearbeiten** aus.

   1. Wechseln Sie in Zeile 19 `hello world` zu**Tutorial complete\$1**.

   1. Wählen Sie **Commit** und anschließend erneut **Commit** aus.

      Durch den Commit wird ein weiterer Workflow-Lauf gestartet. Dieser Lauf wird erfolgreich sein.

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. **Wählen Sie `codecatalyst-cfn-workflow` und wählen Sie dann Runs aus.**

1. Wählen Sie die Lauf-ID des letzten Laufs aus. Es sollte noch in Bearbeitung sein.

1. Wählen Sie **Test** und **BuildBackend**, **DeployCloudFormationStack**um den Fortschritt der Workflow-Ausführung zu sehen.

1. Wenn der Workflow abgeschlossen ist, wählen Sie oben **Variablen (7)** aus.

1. Fügen Sie **HelloWorldApi**als Nächstes die `https://` URL in einen Browser ein.

   Im Browser wird eine `Tutorial complete!` Meldung angezeigt, die darauf hinweist, dass Ihre neue Anwendung erfolgreich bereitgestellt wurde.

## Bereinigen
<a name="deploy-tut-lambda-cfn-clean-up"></a>

Bereinigen Sie die in diesem Tutorial verwendeten Dateien und Dienste, um zu vermeiden, dass dafür Gebühren anfallen.

**Um in der CodeCatalyst Konsole aufzuräumen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Löschen`codecatalyst-cfn-workflow`.

1. Löschen`codecatalyst-cfn-environment`.

1. Löschen`codecatalyst-cfn-source-repository`.

1. Löschen`codecatalyst-cfn-project`.

**Zum Aufräumen in der AWS-Managementkonsole**

1.  CloudFormationAufräumen wie folgt:

   1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).

   1. Löschen Sie das `codecatalyst-cfn-stack`.

      Durch das Löschen des Stacks werden alle Tutorial-Ressourcen aus den API Gateway- und Lambda-Diensten entfernt.

1. Bereinigen Sie in Amazon S3 wie folgt:

   1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

   1. Wählen Sie das Symbol `codecatalyst-cfn-s3-bucket`.

   1. Löschen Sie den Inhalt des Buckets.

   1. Löschen Sie den Bucket.

1. Bereinigen Sie in IAM wie folgt:

   1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

   1. Löschen Sie das `codecatalyst-deploy-policy`.

   1. Löschen Sie das `codecatalyst-build-policy`.

   1. Löschen Sie das `codecatalyst-stack-policy`.

   1. Löschen Sie das `codecatalyst-deploy-role`.

   1. Löschen Sie das `codecatalyst-build-role`.

   1. Löschen Sie das `codecatalyst-stack-role`.

In diesem Tutorial haben Sie gelernt, wie Sie eine serverlose Anwendung mithilfe eines CodeCatalyst Workflows und einer CloudFormation Stack-Aktion bereitstellen als ** CloudFormation Stack bereitstellen**.

# Aktion „ CloudFormation Stapel bereitstellen“ hinzufügen
<a name="deploy-action-cfn-adding"></a>

Verwenden Sie die folgenden Anweisungen, um die Aktion ** CloudFormation Stack bereitstellen** zu Ihrem Workflow hinzuzufügen. 

------
#### [ Visual ]

**Um die Aktion „ CloudFormation Stapel bereitstellen“ mit dem visuellen 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion ** CloudFormation Stack bereitstellen** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie ** CloudFormation Stack bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld gehen Sie wie folgt vor:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „ CloudFormation Stack bereitstellen“ mit dem YAML-Editor hinzuzufügen**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion ** CloudFormation Stack bereitstellen** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie ** CloudFormation Stack bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld gehen Sie wie folgt vor:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.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.

------

# Rollbacks konfigurieren
<a name="deploy-consumption-enable-alarms"></a>

Wenn die Aktion ** CloudFormation Stack bereitstellen** fehlschlägt, führt dies standardmäßig CloudFormation dazu, dass der Stack auf den letzten bekannten stabilen Status zurückgesetzt wird. Sie können das Verhalten so ändern, dass Rollbacks nicht nur dann auftreten, wenn die Aktion fehlschlägt, sondern auch, wenn ein bestimmter CloudWatch Amazon-Alarm ausgelöst wird. Weitere Informationen zu CloudWatch Alarmen finden Sie unter [Verwenden von CloudWatch Amazon-Alarmen](https://docs.aws.amazon.com/) im * CloudWatch Amazon-Benutzerhandbuch*.

Sie können auch das Standardverhalten so ändern, dass der Stack CloudFormation nicht zurückgesetzt wird, wenn die Aktion fehlschlägt. 

Verwenden Sie die folgenden Anweisungen, um Rollbacks zu konfigurieren.

**Anmerkung**  
Sie können ein Rollback nicht manuell starten.

------
#### [ Visual ]

**Bevor Sie beginnen**

1. Stellen Sie sicher, dass Sie über einen [Workflow](workflow.md) verfügen, der eine funktionierende Aktion „** CloudFormation Stack bereitstellen**“ beinhaltet. Weitere Informationen finden Sie unter [Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md).

1. Stellen Sie sicher, dass Sie in der **Rolle, die im Feld Stack-Rolle — optional** der Aktion ** CloudFormation Stack bereitstellen** angegeben ist, die **CloudWatchFullAccess**Berechtigung angeben. Informationen zum Erstellen dieser Rolle mit den entsprechenden Berechtigungen finden Sie unter[Schritt 2: AWS Rollen erstellen](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles).

**So konfigurieren Sie Rollback-Alarme für die Aktion „Stack bereitstellen“ CloudFormation**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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 Ihre ** CloudFormation Stack-Aktion „Deploy**“.

1. Wählen Sie im Detailbereich **Konfiguration** aus.

1. Erweitern Sie unten die Option **Erweitert**.

1. Wählen Sie unter **Alarm überwachen ARNs** die Option **Alarm hinzufügen** aus.

1. Geben Sie Informationen in die folgenden Felder ein.
   + **Alarm ARN**

     Geben Sie den Amazon-Ressourcennamen (ARN) eines CloudWatch Amazon-Alarms an, der als Rollback-Trigger verwendet werden soll. Beispiel, `arn:aws:cloudwatch::123456789012:alarm/MyAlarm`. Sie können maximal fünf Rollback-Trigger haben.
**Anmerkung**  
Wenn Sie einen CloudWatch Alarm-ARN angeben, müssen Sie auch zusätzliche Berechtigungen konfigurieren, damit die Aktion darauf zugreifen kann CloudWatch. Weitere Informationen finden Sie unter [Rollbacks konfigurieren](#deploy-consumption-enable-alarms).
   + **Dauer der Überwachung**

     Geben Sie einen Zeitraum von 0 bis 180 Minuten an, in dem die angegebenen Alarme CloudFormation überwacht werden. Die Überwachung beginnt, *nachdem* alle Stack-Ressourcen bereitgestellt wurden. Wenn der Alarm innerhalb der angegebenen Überwachungszeit auftritt, CloudFormation schlägt die Bereitstellung fehl und der gesamte Stack-Vorgang wird rückgängig gemacht.

     Standard: 0. CloudFormation überwacht Alarme nur, während die Stack-Ressourcen bereitgestellt werden, nicht danach.

------
#### [ YAML ]

**Um Rollback-Trigger für die Aktion „Stack bereitstellen“ CloudFormation zu konfigurieren**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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 eines Workflows, der die Aktion ** CloudFormation Stack bereitstellen** enthält. 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 die `monitor-timeout-in-minutes` Eigenschaften `monitor-alarm-arns` und im YAML-Code hinzu, um Rollback-Trigger hinzuzufügen. Eine Erläuterung der einzelnen Eigenschaften finden Sie unter. [Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.md)

1. Stellen Sie sicher, dass Sie in der Rolle, die in der `role-arn` Eigenschaft der Aktion ** CloudFormation Stack bereitstellen** angegeben ist, die **CloudWatchFullAccess**entsprechende Berechtigung angeben. Informationen zum Erstellen dieser Rolle mit den entsprechenden Berechtigungen finden Sie unter[Schritt 2: AWS Rollen erstellen](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles).

------

------
#### [ Visual ]

**So deaktivieren Sie Rollbacks für die Aktion „Stack bereitstellen“ CloudFormation**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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 eines Workflows, der die Aktion ** CloudFormation Stack bereitstellen** enthält. 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 Ihre ** CloudFormation Stack-Aktion „Deploy**“.

1. Wählen Sie im Detailbereich **Konfiguration** aus.

1. Erweitern Sie unten die Option **Erweitert**.

1. Aktivieren Sie **„Rollback deaktivieren“**.

------
#### [ YAML ]

**Um Rollbacks für die Aktion „Stack bereitstellen“ CloudFormation zu deaktivieren**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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 eines Workflows, der die Aktion ** CloudFormation Stack bereitstellen** enthält. 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 die `disable-rollback: 1` Eigenschaft im YAML-Code hinzu, um Rollbacks zu verhindern. Eine Erläuterung dieser Eigenschaft finden Sie unter. [Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.md)

------

# CloudFormation 'Stack'-Variablen bereitstellen
<a name="deploy-action-cfn-variables"></a>

Die Aktion „** CloudFormation Stack bereitstellen**“ erzeugt und setzt zur Laufzeit die folgenden Variablen. Diese werden als *vordefinierte Variablen* bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Bereitstellungsplattform  |  Der Name der Bereitstellungsplattform. Fest codiert auf. `AWS:CloudFormation`  | 
|  Region  |  Der Regionalcode von AWS-Region , für den während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `us-west-2`  | 
|  Stack-ID  |  Der Amazon-Ressourcenname (ARN) des bereitgestellten Stacks. Beispiel: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cfn-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 

# Aktion CloudFormation 'Stack bereitstellen' YAML
<a name="deploy-action-ref-cfn"></a>

Im Folgenden finden Sie die YAML-Definition der ** CloudFormation Stack-Aktion Deploy**. Informationen zur Verwendung dieser Aktion finden Sie unter[Einen CloudFormation Stack bereitstellen](deploy-action-cfn.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 action definition starts here.    
  DeployCloudFormationStack:  
    Identifier: aws/cfn-deploy@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: DeployRole
    Inputs:
      Sources:
        - source-name-1
      Artifacts:
        - CloudFormation-artifact
    Configuration:
      name: stack-name
      region: us-west-2
      template: template-path
      role-arn: arn:aws:iam::123456789012:role/StackRole        
      capabilities: CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND
      parameter-overrides: KeyOne=ValueOne,KeyTwo=ValueTwo | path-to-JSON-file
      no-execute-changeset: 1|0
      fail-on-empty-changeset: 1|0
      disable-rollback: 1|0
      termination-protection: 1|0
      timeout-in-minutes: minutes
      notification-arns: arn:aws:sns:us-east-1:123456789012:MyTopic,arn:aws:sns:us-east-1:123456789012:MyOtherTopic
      monitor-alarm-arns: arn:aws:cloudwatch::123456789012:alarm/MyAlarm,arn:aws:cloudwatch::123456789012:alarm/MyOtherAlarm
      monitor-timeout-in-minutes: minutes       
      tags: '[{"Key":"MyKey1","Value":"MyValue1"},{"Key":"MyKey2","Value":"MyValue2"}]'
```

## DeployCloudFormationStack
<a name="deploy.action.cfn.deploycloudformationstack"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `DeployCloudFormationStack_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Anzeigename der Aktion**

## Identifier
<a name="deploy.action.cfn.identifier"></a>

(*DeployCloudFormationStack*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/cfn-deploy@v1`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ DeployCloudFormationStack \$1nn/ aws/cfn-deploy @v1 label**

## DependsOn
<a name="deploy.action.cfn.dependson"></a>

(*DeployCloudFormationStack*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="deploy.action.cfn.computename"></a>

(*DeployCloudFormationStack*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="deploy.action.cfn.computetype"></a>

(*DeployCloudFormationStack*/Compute/**Type**)

([Compute](#deploy.action.cfn.computename)Erforderlich, falls enthalten)

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: Konfiguration tab/Advanced — optional/ Berechnungstyp**

## Fleet
<a name="deploy.action.cfn.computefleet"></a>

(*DeployCloudFormationStack*/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 können sofort Aktionen ausführen. 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`

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Compute Fleet**

## Timeout
<a name="deploy.action.cfn.timeout"></a>

(*DeployCloudFormationStack*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Timeout** in Minuten — optional

## Environment
<a name="deploy.action.cfn.environment"></a>

(*DeployCloudFormationStack*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="deploy.action.cfn.environment.name"></a>

(*DeployCloudFormationStack*/Environment/**Name**)

(Erforderlich, falls [Environment](#deploy.action.cfn.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="deploy.action.cfn.environment.connections"></a>

(*DeployCloudFormationStack*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="deploy.action.cfn.environment.connections.name"></a>

(*DeployCloudFormationStack*/Environment/Connections/**Name**)

(Erforderlich, falls enthalten[Connections](#deploy.action.cfn.environment.connections))

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="deploy.action.cfn.environment.connections.role"></a>

(*DeployCloudFormationStack*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#deploy.action.cfn.environment.connections))

Geben Sie den Namen der IAM-Rolle an, die von der ** CloudFormation Stack-Aktion Deploy** für den Zugriff auf AWS den CloudFormation Dienst verwendet wird. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf die in der folgenden Richtlinie angegebenen. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.
**Anmerkung**  
Wenn die Rolle zum ersten Mal verwendet wird, verwenden Sie den folgenden Platzhalter in der Ressourcenrichtlinienanweisung und grenzen Sie dann die Richtlinie mit dem Ressourcennamen ab, sobald sie verfügbar ist.  

  ```
  "Resource": "*"
  ```
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Inputs
<a name="deploy.action.cfn.inputs"></a>

(*DeployCloudFormationStack*/**Inputs**)

(Optional)

`Inputs`In diesem Abschnitt werden die Daten definiert, die während einer `DeployCloudFormationStack` Workflow-Ausführung benötigt werden.

**Anmerkung**  
Pro ** CloudFormation Stack-Aktion vom Typ Deploy** sind maximal vier Eingaben (eine Quelle und drei Artefakte) zulässig.

Wenn Sie auf Dateien verweisen müssen, die sich in verschiedenen Eingaben befinden (z. B. eine Quelle und ein Artefakt), ist die Quelleingabe die primäre Eingabe und das Artefakt die sekundäre Eingabe. Verweise auf Dateien in sekundären Eingaben benötigen ein spezielles Präfix, um sie von der primären Eingabe zu unterscheiden. Details hierzu finden Sie unter [Beispiel: Referenzieren von Dateien in mehreren Artefakten](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“**

## Sources
<a name="deploy.action.cfn.inputs.sources"></a>

(*DeployCloudFormationStack*/Inputs/**Sources**)

(Erforderlich, wenn Ihre AWS SAM Vorlage CloudFormation oder Ihre Vorlage in einem Quell-Repository gespeichert ist)

Wenn Ihre AWS SAM Vorlage CloudFormation oder Ihre Vorlage in einem Quell-Repository gespeichert ist, geben Sie die Bezeichnung dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label`WorkflowSource`.

Wenn Ihre AWS SAM Vorlage CloudFormation oder nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde, oder in einem Amazon S3 S3-Bucket.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="deploy.action.cfn.inputs.artifacts"></a>

(*DeployCloudFormationStack*/Inputs/**Artifacts**)

(Erforderlich, wenn Ihre AWS SAM Vorlage CloudFormation oder Ihre Vorlage in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer vorherigen Aktion gespeichert ist)

Wenn die AWS SAM Vorlage CloudFormation oder, die Sie bereitstellen möchten, in einem Artefakt enthalten ist, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Wenn Ihre CloudFormation Vorlage nicht in einem Artefakt enthalten ist, muss sie sich in Ihrem Quell-Repository oder in einem Amazon S3 S3-Bucket befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Configuration
<a name="deploy.action.cfn.configuration"></a>

(*DeployCloudFormationStack*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## name
<a name="deploy.action.cfn.stackname"></a>

(*DeployCloudFormationStack*/Configuration/**name**)

(Erforderlich)

Geben Sie einen Namen für den CloudFormation Stack an, den die Aktion ** CloudFormation Stack bereitstellen** erstellt oder aktualisiert.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Name des **Stacks**

## region
<a name="deploy.action.cfn.stackregion"></a>

(*DeployCloudFormationStack*/Configuration/**region**)

(Erforderlich)

Geben Sie an, AWS-Region in welchem Bereich der Stack bereitgestellt werden soll. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Region „Stack“**

## template
<a name="deploy.action.cfn.templatepath"></a>

(*DeployCloudFormationStack*/Configuration/**template**)

(Erforderlich)

Geben Sie den Namen und den Pfad zu Ihrer Datei CloudFormation oder der AWS SAM Vorlagendatei an. Die Vorlage kann im JSON- oder YAML-Format vorliegen und sich in einem Quell-Repository, einem Artefakt aus einer früheren Aktion oder einem Amazon S3 S3-Bucket befinden. Wenn sich die Vorlagendatei in einem Quell-Repository oder Artefakt befindet, ist der Pfad relativ zur Quelle oder zum Artefakt-Stamm. Wenn sich die Vorlage in einem Amazon S3 S3-Bucket befindet, entspricht der Pfad dem **Objekt-URL-Wert** der Vorlage.

Beispiele:

`./MyFolder/MyTemplate.json`

`MyFolder/MyTemplate.yml`

`https://MyBucket.s3.us-west-2.amazonaws.com/MyTemplate.yml`

**Anmerkung**  
Möglicherweise müssen Sie dem Dateipfad der Vorlage ein Präfix hinzufügen, um anzugeben, in welchem Artefakt oder in welcher Quelle die Vorlage gefunden werden soll. Weitere Informationen erhalten Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Vorlage“**

## role-arn
<a name="deploy.action.cfn.stackrolearn"></a>

(*DeployCloudFormationStack*/Configuration/**role-arn**)

(Erforderlich)

Geben Sie den Amazon-Ressourcennamen (ARN) der Stack-Rolle an. CloudFormation verwendet diese Rolle, um auf Ressourcen in Ihrem Stack zuzugreifen und diese zu ändern. Beispiel: `arn:aws:iam::123456789012:role/StackRole`.

Stellen Sie sicher, dass die Stack-Rolle Folgendes beinhaltet:
+ Eine oder mehrere Berechtigungsrichtlinien. Die Richtlinien hängen von den Ressourcen ab, die Sie in Ihrem Stack haben. Wenn Ihr Stack beispielsweise eine AWS Lambda Funktion enthält, müssen Sie Berechtigungen hinzufügen, die Zugriff auf Lambda gewähren. Wenn Sie das unter beschriebene Tutorial befolgt haben[Tutorial: Eine serverlose Anwendung bereitstellen](deploy-tut-lambda.md), enthält es ein Verfahren mit dem Titel, [Um eine Stack-Rolle zu erstellen](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles-stack) das die Berechtigungen auflistet, die die Stack-Rolle benötigt, wenn Sie einen typischen serverlosen Anwendungsstapel bereitstellen.
**Warnung**  
Beschränken Sie die Berechtigungen auf diejenigen, die der CloudFormation Dienst für den Zugriff auf Ressourcen in Ihrem Stack benötigt. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.
+ Die folgende Vertrauensrichtlinie:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                  "Service": "cloudformation.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
          }
      ]
  }
  ```

------

Ordnen Sie diese Rolle optional Ihrer Kontoverbindung zu. Weitere Informationen zum Zuordnen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter. [Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md) Wenn Sie die Stack-Rolle nicht mit der Kontoverbindung verknüpfen, wird die Stack-Rolle nicht in der Dropdownliste **Stack-Rolle** im Visual Editor angezeigt. Der Rollen-ARN kann jedoch trotzdem mit dem YAML-Editor in dem `role-arn` Feld angegeben werden.

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ **/Rolle „Stack“ — optional**

## capabilities
<a name="deploy.action.cfn.capabilities"></a>

(*DeployCloudFormationStack*/Configuration/**capabilities**)

(Erforderlich)

Geben Sie eine Liste der IAM-Funktionen an, die für die Erstellung bestimmter CloudFormation Stacks erforderlich sind. In den meisten Fällen können Sie `capabilities` den Standardwert von beibehalten. `CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND`

Wenn Sie `##[error] requires capabilities: [capability-name]` in den Protokollen Ihrer ** CloudFormation Stack-Aktion „Bereitstellen**“ etwas sehen, finden Sie unter Informationen [Wie behebe ich Fehler bei den IAM-Fähigkeiten?](troubleshooting-workflows.md#troubleshooting-workflows-capabilities) zur Behebung des Problems.

*Weitere Informationen zu IAM-Funktionen finden Sie im [IAM-Benutzerhandbuch unter Bestätigung von IAM-Ressourcen in CloudFormation Vorlagen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html#using-iam-capabilities).*

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /Erweitert/Funktionen**

## parameter-overrides
<a name="deploy.action.cfn.parameter.overrides"></a>

(*DeployCloudFormationStack*/Configuration/**parameter-overrides**)

(Optional)

Geben Sie in Ihrer CloudFormation AWS SAM Vorlage Parameter an, die keine Standardwerte haben oder für die Sie nicht standardmäßige Werte angeben möchten. Weitere Informationen zu Parametern finden Sie unter [Parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) im * AWS CloudFormation Benutzerhandbuch*.

Die `parameter-overrides` Unterkunft akzeptiert:
+ Eine JSON-Datei, die die Parameter und Werte enthält.
+ Eine durch Kommas getrennte Liste von Parametern und Werten.

**Um eine JSON-Datei anzugeben**

1. Stellen Sie sicher, dass die JSON-Datei eine der folgenden Syntaxen verwendet:

   ```
   {
     "Parameters": {
       "Param1": "Value1",
       "Param2": "Value2",
       ...
     }
   }
   ```

   Oder...

   ```
   [
     {
        "ParameterKey": "Param1",
        "ParameterValue": "Value1"
     },
     ...
   ]
   ```

   (Es gibt andere Syntaxen, aber sie werden CodeCatalyst zum Zeitpunkt des Schreibens nicht unterstützt.) Weitere Informationen zum Angeben von CloudFormation Parametern in einer JSON-Datei finden Sie unter [Unterstützte JSON-Syntax](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/deploy/index.html#supported-json-syntax) in der *AWS CLI Befehlsreferenz.*

1. Geben Sie den Pfad zur JSON-Datei in einem der folgenden Formate an:
   + Wenn sich Ihre JSON-Datei in einem Ausgabeartefakt einer früheren Aktion befindet, verwenden Sie:

     `file:///artifacts/current-action-name/output-artifact-name/path-to-json-file`

     Einzelheiten finden Sie in **Beispiel 1.**
   + Wenn sich Ihre JSON-Datei in Ihrem Quell-Repository befindet, verwenden Sie:

     `file:///sources/WorkflowSource/path-to-json-file`

     Einzelheiten finden Sie in **Beispiel 2.**

     **Beispiel 1** — Die JSON-Datei befindet sich in einem Ausgabeartefakt

     ```
     ##My workflow YAML
     ...
     Actions:
       MyBuildAction:
         Identifier: aws/build@v1
         Outputs:
           Artifacts:
             - Name: ParamArtifact
               Files:
                 - params.json
         Configuration:
         ...
       MyDeployCFNStackAction:
         Identifier: aws/cfn-deploy@v1
         Configuration:
           parameter-overrides: file:///artifacts/MyDeployCFNStackAction/ParamArtifact/params.json
     ```

     **Beispiel 2** — Die JSON-Datei befindet sich in Ihrem Quell-Repository in einem Ordner namens `my/folder`

     ```
     ##My workflow YAML
     ...
     Actions:
       MyDeployCloudFormationStack:
         Identifier: aws/cfn-deploy@v1
         Inputs:
           Sources:
             - WorkflowSource
         Configuration:
           parameter-overrides: file:///sources/WorkflowSource/my/folder/params.json
     ```

**Um eine durch Kommas getrennte Liste von Parametern zu verwenden**
+ Fügen Sie der `parameter-overrides` Eigenschaft Parameter-Name-Wert-Paare im folgenden Format hinzu:

  `param-1=value-1,param-2=value-2`

  Nehmen wir zum Beispiel die folgende Vorlage an: CloudFormation 

  ```
  ##My CloudFormation template
  
  Description: My CloudFormation template
  
  Parameters:
    InstanceType:
      Description: Defines the Amazon EC2 compute for the production server.
      Type: String
      Default: t2.micro
      AllowedValues:
        - t2.micro
        - t2.small
        - t3.medium
      
  Resources:
  ...
  ```

  ... Sie könnten die `parameter-overrides` Eigenschaft wie folgt festlegen:

  ```
  ##My workflow YAML
  ...
  Actions:
  ...
    DeployCloudFormationStack:
      Identifier: aws/cfn-deploy@v1
      Configuration:
        parameter-overrides: InstanceType=t3.medium,UseVPC=true
  ```
**Anmerkung**  
Sie können einen Parameternamen ohne einen entsprechenden Wert angeben, indem Sie `undefined` ihn als Wert verwenden. Beispiel:  
`parameter-overrides: MyParameter=undefined`  
 Das hat zur Folge, dass bei einem Stack-Update der vorhandene Parameterwert für den angegebenen Parameternamen CloudFormation verwendet wird.

Entsprechende Benutzeroberfläche:
+ **Registerkarte „Konfiguration/Erweitert/Parameterüberschreibungen“**
+ tab/Advanced/Parameter**Überschreibungen der Konfiguration/ Geben Sie Überschreibungen mithilfe einer Datei an**
+ **Überschreibungen der tab/Advanced/Parameter Konfiguration/ Spezifizieren Sie Überschreibungen mithilfe eines Wertesatzes**

## no-execute-changeset
<a name="deploy.action.cfn.noexecutechangeset"></a>

(*DeployCloudFormationStack*/Configuration/**no-execute-changeset**)

(Optional)

Geben Sie an, ob Sie den CloudFormation Änderungssatz erstellen und dann beenden möchten CodeCatalyst , bevor Sie ihn ausführen. Auf diese Weise haben Sie die Möglichkeit, den Änderungssatz in der CloudFormation Konsole zu überprüfen. Wenn Sie feststellen, dass der Änderungssatz gut aussieht, deaktivieren Sie diese Option und führen Sie dann den Workflow erneut aus, sodass Sie den Änderungssatz erstellen und ausführen CodeCatalyst können, ohne ihn anzuhalten. Standardmäßig wird der Änderungssatz erstellt und ausgeführt, ohne ihn anzuhalten. Weitere Informationen finden Sie im CloudFormation [Deploy-Parameter](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) in der *AWS CLI Befehlsreferenz*. Weitere Informationen zum Anzeigen von Änderungssätzen finden Sie im *AWS CloudFormation Benutzerhandbuch* unter [Änderungssätze anzeigen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-view.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /Erweitert/Änderungssatz nicht ausführen**

## fail-on-empty-changeset
<a name="deploy.action.cfn.failonemptychangeset"></a>

(*DeployCloudFormationStack*/Configuration/**fail-on-empty-changeset**)

(Optional)

Geben Sie an, ob die Aktion „** CloudFormation Stack bereitstellen**“ fehlschlagen soll CodeCatalyst , wenn der CloudFormation Änderungssatz leer ist. (Wenn ein Änderungssatz leer ist, bedeutet dies, dass während der letzten Bereitstellung keine Änderungen am Stack vorgenommen wurden.) Standardmäßig kann die Aktion fortgesetzt werden, wenn der Änderungssatz leer ist, und es wird eine `UPDATE_COMPLETE` Meldung zurückgegeben, obwohl der Stack nicht aktualisiert wurde.

Weitere Informationen zu dieser Einstellung finden Sie im CloudFormation [Deploy-Parameter](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) in der *AWS CLI Befehlsreferenz*. Weitere Informationen zu Änderungssätzen finden Sie unter [Aktualisieren von Stacks mithilfe von Änderungssätzen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) im *AWS CloudFormation Benutzerhandbuch*.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /Erweitert/Fehler bei leerem Changeset**

## disable-rollback
<a name="deploy.action.cfn.disablerollback"></a>

(*DeployCloudFormationStack*/Configuration/**disable-rollback**)

(Optional)

Geben Sie an, ob Sie die Stack-Bereitstellung rückgängig CodeCatalyst machen möchten, falls sie fehlschlägt. Durch das Rollback wird der Stack in den letzten bekannten stabilen Zustand zurückversetzt. Standardmäßig werden Rollbacks aktiviert. Weitere Informationen zu dieser Einstellung finden Sie im CloudFormation [Deploy-Parameter](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) in der *AWS CLI Befehlsreferenz.*

Weitere Informationen dazu, wie die Aktion ** CloudFormation Stack bereitstellen** Rollbacks behandelt, finden Sie unter[Rollbacks konfigurieren](deploy-consumption-enable-alarms.md).

Weitere Informationen zum Rollback eines Stacks finden Sie unter [Optionen für Stack-Fehler](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html) im *AWS CloudFormation Benutzerhandbuch*.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /Erweitert/Rollback deaktivieren**

## termination-protection
<a name="deploy.action.cfn.terminationprotection"></a>

(*DeployCloudFormationStack*/Configuration/**termination-protection**)

(Optional)

Geben Sie an, ob der ** CloudFormation Deploy-Stack dem Stack**, den er bereitstellt, einen Kündigungsschutz hinzufügen soll. Wenn ein Benutzer versucht, einen Stack mit aktiviertem Beendigungsschutz zu löschen, schlägt das Löschen fehl und der Stack – einschließlich seines Status – bleibt unverändert. Standardmäßig ist der Kündigungsschutz deaktiviert. Weitere Informationen finden Sie im *AWS CloudFormation Benutzerhandbuch* unter [Einen Stack vor dem Löschen schützen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /„ Erweitert/Kündigungsschutz“**

## timeout-in-minutes
<a name="deploy.action.cfn.timeoutinminutes"></a>

(*DeployCloudFormationStack*/Configuration/**timeout-in-minutes**)

(Optional)

Geben Sie die Zeitspanne in Minuten an, die zur Verfügung stehen CloudFormation soll, bevor bei der Stackerstellung ein Timeout eintritt und der Stack-Status auf gesetzt wird. `CREATE_FAILED` Wenn CloudFormation innerhalb des zugeteilten Zeitraums nicht den gesamten Stack erstellen kann, schlägt die Stack-Erstellung aufgrund des Timeouts fehl und für den Stack wird ein Rollback durchgeführt.

Standardmäßig gibt es keinen Timeout für die Stack-Erstellung. Allerdings gibt es möglicherweise für einzelne Ressourcen einen Timeout, basierend auf der Art des von ihnen implementierten Services. Wenn beispielsweise eine einzelne Ressource in Ihrem Stack abläuft, läuft die Stack-Erstellung ebenfalls aus, auch wenn der von Ihnen angegebene Timeout für die Stack-Erstellung noch nicht erreicht wurde.

**Entsprechende Benutzeroberfläche: Registerkarte CloudFormation „Konfiguration“ /„ Erweitert/Timeout“**

## notification-arns
<a name="deploy.action.cfn.notificationarns"></a>

(*DeployCloudFormationStack*/Configuration/**notification-arns**)

(Optional)

Geben Sie den ARN eines Amazon SNS SNS-Themas an, CodeCatalyst an das Sie Benachrichtigungen senden möchten. Beispiel, `arn:aws:sns:us-east-1:111222333:MyTopic`. Wenn die Aktion „** CloudFormation Stack bereitstellen**“ ausgeführt wird CodeCatalyst , wird CloudFormation für jedes CloudFormation Ereignis, das während der Erstellung oder Aktualisierung des Stacks auftritt, jeweils eine Benachrichtigung gesendet. (Die Ereignisse sind auf der Registerkarte **Ereignisse** der CloudFormation Konsole für den Stack sichtbar.) Sie können bis zu fünf Themen angeben. Weitere Informationen finden Sie unter [Was ist Amazon SNS?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /„ Erweitert/Benachrichtigung“ ARNs**

## monitor-alarm-arns
<a name="deploy.action.cfn.monitoralarmarns"></a>

(*DeployCloudFormationStack*/Configuration/**monitor-alarm-arns**)

(Optional)

Geben Sie den Amazon-Ressourcennamen (ARN) eines CloudWatch Amazon-Alarms an, der als Rollback-Trigger verwendet werden soll. Beispiel, `arn:aws:cloudwatch::123456789012:alarm/MyAlarm`. Sie können maximal fünf Rollback-Trigger haben.

**Anmerkung**  
Wenn Sie einen CloudWatch Alarm-ARN angeben, müssen Sie auch zusätzliche Berechtigungen konfigurieren, damit die Aktion darauf zugreifen kann CloudWatch. Weitere Informationen finden Sie unter [Rollbacks konfigurieren](deploy-consumption-enable-alarms.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /„ Erweitert/Alarm überwachen“ ARNs**

## monitor-timeout-in-minutes
<a name="deploy.action.cfn.monitortimeinminutes"></a>

(*DeployCloudFormationStack*/Configuration/**monitor-timeout-in-minutes**)

(Optional)

Geben Sie einen Zeitraum zwischen 0 und 180 Minuten an, in dem die angegebenen Alarme CloudFormation überwacht werden. Die Überwachung beginnt, *nachdem* alle Stack-Ressourcen bereitgestellt wurden. Wenn der Alarm innerhalb der angegebenen Überwachungszeit auftritt, CloudFormation schlägt die Bereitstellung fehl und der gesamte Stack-Vorgang wird rückgängig gemacht.

Standard: 0. CloudFormation überwacht Alarme nur, während die Stack-Ressourcen bereitgestellt werden, nicht danach.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /„ Erweitert/Zeit überwachen“**

## tags
<a name="deploy.action.cfn.tags"></a>

(*DeployCloudFormationStack*/Configuration/**tags**)

(Optional)

Geben Sie Tags an, die an Ihren Stack angehängt werden sollen. CloudFormation Tags sind beliebige Schlüssel-Wert-Paare, die Sie verwenden können, um Ihren Stack für Zwecke wie die Kostenzuweisung zu identifizieren. Weitere Informationen zu Tags und ihrer Verwendung finden Sie unter [Tagging Ihrer Ressourcen](https://docs.aws.amazon.com/) im *Amazon EC2-Benutzerhandbuch*. *Weitere Informationen zum Tagging finden Sie unter [CloudFormation Stack-Optionen einrichten](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html) im AWS CloudFormation Benutzerhandbuch. CloudFormation*

Ein Schlüssel kann alphanumerische Zeichen oder Leerzeichen und bis zu 127 Zeichen enthalten. Ein Wert kann alphanumerische Zeichen oder Leerzeichen und bis zu 255 Zeichen enthalten.

Sie können bis zu 50 eindeutige Tags für jeden Stack hinzufügen.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /„ Erweitert/Tags“**

# Eine AWS CDK App mit einem Workflow bereitstellen
<a name="cdk-dep-action"></a>

In diesem Abschnitt wird beschrieben, wie Sie mithilfe eines Workflows eine AWS Cloud Development Kit (AWS CDK) App in Ihrem AWS Konto bereitstellen. Um dies zu erreichen, müssen Sie die **AWS CDK Bereitstellungsaktion** zu Ihrem Workflow hinzufügen. Die **AWS CDK Bereitstellungsaktion** synthetisiert Ihre AWS Cloud Development Kit (AWS CDK) App und stellt sie bereit in. AWS Wenn Ihre App bereits in vorhanden ist AWS, wird sie bei Bedarf durch die Aktion aktualisiert. 

Allgemeine Informationen zum Schreiben von Apps mit dem AWS CDK finden Sie unter [Was ist der AWS CDK?](https://docs.aws.amazon.com/cdk/v2/guide/home.html) im *AWS Cloud Development Kit (AWS CDK) Entwicklerhandbuch*.

**Topics**
+ [

## Wann sollte die Aktion „AWS CDK Bereitstellen“ verwendet werden
](#cdk-dep-action-when-to-use)
+ [

## So funktioniert die Aktion „AWS CDK Bereitstellen“
](#cdk-dep-action-how-it-works)
+ [

## CDK-CLI-Versionen, die von der Aktion „AWS CDK Deploy“ verwendet werden
](#cdk-dep-action-cdk-version)
+ [

## Von der Aktion „Deploy“AWS CDK verwendetes Runtime-Image
](#cdk-dep-action-runtime)
+ [

## Wie viele Stapel kann die Aktion bereitstellen?
](#cdk-dep-action-how-many-stacks)
+ [

# Beispiel: Eine AWS CDK App bereitstellen
](cdk-dep-action-example-workflow.md)
+ [

# Aktion „AWS CDK Deploy“ hinzufügen
](cdk-dep-action-add.md)
+ [

# Variablen 'AWS CDK bereitstellen'
](cdk-dep-action-variables.md)
+ [

# Aktion 'AWS CDK bereitstellen' YAML
](cdk-dep-action-ref.md)

## Wann sollte die Aktion „AWS CDK Bereitstellen“ verwendet werden
<a name="cdk-dep-action-when-to-use"></a>

Verwenden Sie diese Aktion AWS CDK, wenn Sie mit dem eine App entwickelt haben und diese nun automatisch als Teil des automatisierten Workflows für kontinuierliche Integration und Bereitstellung (CI/CD) bereitstellen möchten. Möglicherweise möchten Sie Ihre AWS CDK App beispielsweise automatisch bereitstellen, wenn jemand eine Pull-Anfrage zusammenführt, die sich auf Ihre AWS CDK App-Quelle bezieht. 

## So funktioniert die Aktion „AWS CDK Bereitstellen“
<a name="cdk-dep-action-how-it-works"></a>

Die **AWS CDK Bereitstellung** funktioniert wie folgt:

1. [Wenn Sie zur Laufzeit Version 1.0.12 oder früher der Aktion angegeben haben, lädt die Aktion die neueste CDK-CLI (auch AWS CDK Tookit genannt) in das Laufzeitumgebungsabbild herunter. CodeCatalyst ](#cdk-dep-action-runtime)

   Wenn Sie Version 1.0.13 oder höher angegeben haben, ist die Aktion mit einer [bestimmten Version](#cdk-dep-action-cdk-version) der CDK-CLI gebündelt, sodass kein Download stattfindet.

1. Die Aktion verwendet die CDK-CLI, um den `cdk deploy` Befehl auszuführen. Dieser Befehl synthetisiert Ihre AWS CDK App und stellt sie bereit in. AWS*Weitere Informationen zu diesem Befehl finden Sie im Developer Guide unter dem Thema [AWS CDK Toolkit (cdk-Befehl)](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html).AWS Cloud Development Kit (AWS CDK) *

## CDK-CLI-Versionen, die von der Aktion „AWS CDK Deploy“ verwendet werden
<a name="cdk-dep-action-cdk-version"></a>

Die folgende Tabelle zeigt, welche Version der CDK-CLI standardmäßig von verschiedenen Versionen der **AWS CDK Bereitstellungsaktion** verwendet wird.

**Anmerkung**  
Möglicherweise können Sie die Standardeinstellung überschreiben. Weitere Informationen finden Sie unter [CdkCliVersion](cdk-dep-action-ref.md#cdk.dep.cdk.cli.version) im [Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md).


| AWS CDK Aktionsversion „bereitstellen“ | AWS CDK CLI-Version | 
| --- | --- | 
|  1.0.0 — 1.0.12  |  brandneue  | 
|  1.0.13 oder später  |  2.99.1  | 

## Von der Aktion „Deploy“AWS CDK verwendetes Runtime-Image
<a name="cdk-dep-action-runtime"></a>

Die folgende Tabelle zeigt die Runtime-Umgebungs-Images, die zur Ausführung verschiedener Versionen der **AWS CDK Bereitstellungsaktion CodeCatalyst ** verwendet werden. Die Bilder enthalten verschiedene Sätze vorinstallierter Tools. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

**Anmerkung**  
Wir empfehlen, Ihre **AWS CDK Bereitstellungsaktion** auf Version 2.x zu aktualisieren, um die neuesten Tools nutzen zu können, die auf dem Image vom März 2024 verfügbar sind. Um die Aktion zu aktualisieren, legen Sie ihre `Identifier` Eigenschaft `aws/cdk-deploy@v2` in Ihrer Workflow-Definitionsdatei auf fest. Weitere Informationen finden Sie unter [Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md). 


| Version der AWS CDK Aktion „bereitstellen“ | Images der Laufzeitumgebung | 
| --- | --- | 
|  1.x  |  Bilder vom November 2022  | 
|  2.x  |  Bilder vom März 2024  | 

## Wie viele Stapel kann die Aktion bereitstellen?
<a name="cdk-dep-action-how-many-stacks"></a>

Bei der **AWS CDK Bereitstellung** kann nur ein einziger Stack bereitgestellt werden. Wenn Ihre AWS CDK App aus mehreren Stacks besteht, müssen Sie einen übergeordneten Stack mit verschachtelten Stacks erstellen und den übergeordneten Stapel mithilfe dieser Aktion bereitstellen.

# Beispiel: Eine AWS CDK App bereitstellen
<a name="cdk-dep-action-example-workflow"></a>

Der folgende Beispiel-Workflow umfasst die **AWS CDK Bereitstellungsaktion** zusammen mit der **AWS CDK Bootstrap-Aktion**. Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein **Trigger** — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Dieses Repository enthält Ihre AWS CDK App. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine **AWS CDK Bootstrap-Aktion** (`CDKBootstrap`) — Beim Auslösen stellt die Aktion den `CDKToolkit` Bootstrap-Stack in bereit. AWS Wenn der `CDKToolkit` Stack bereits in der Umgebung vorhanden ist, wird er bei Bedarf aktualisiert. Andernfalls passiert nichts und die Aktion wird als erfolgreich markiert.
+ Eine **AWS CDK Bereitstellungsaktion** (`AWS CDK Deploy`) — Nach Abschluss der **AWS CDK Bootstrap-Aktion** synthetisiert die **AWS CDK Bereitstellungsaktion** Ihren AWS CDK App-Code in einer CloudFormation Vorlage und stellt den in der Vorlage definierten Stack bereit. AWS

**Anmerkung**  
Das folgende Workflow-Beispiel dient der Veranschaulichung und funktioniert ohne zusätzliche Konfiguration nicht.

**Anmerkung**  
Im folgenden YAML-Code können Sie die `Connections:` Abschnitte weglassen, wenn Sie möchten. **Wenn Sie diese Abschnitte weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle** angegebene Rolle in Ihrer Umgebung die Berechtigungen und Vertrauensrichtlinien enthält, die für die **AWS CDK Bootstrap** - und Deploy-Aktionen erforderlich sind.AWS CDK ** Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md) Weitere Informationen zu den Berechtigungen und Vertrauensrichtlinien, die für die Aktionen **AWS CDK Bootstrap** und **AWS CDK Deploy** erforderlich sind, finden Sie in der Beschreibung der `Role` Eigenschaft im Dokument und. [AWS CDK 'Bootstrap'-Aktion YAML](cdk-boot-action-ref.md) [Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md)

```
Name: codecatalyst-cdk-deploy-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  CDKBootstrap:
    Identifier: aws/cdk-bootstrap@v2
    Inputs:
      Sources:
        - WorkflowSource
    Environment:
      Name: codecatalyst-cdk-deploy-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-cdk-bootstrap-role
    Configuration:
      Region: us-west-2
        
  CDKDeploy:
    Identifier: aws/cdk-deploy@v2
    DependsOn: 
      - CDKBootstrap
    Environment:
      Name: codecatalyst-cdk-deploy-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-cdk-deploy-role
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      StackName: my-app-stack
      Region: us-west-2
```

# Aktion „AWS CDK Deploy“ hinzufügen
<a name="cdk-dep-action-add"></a>

 Verwenden Sie die folgenden Anweisungen, um die **AWS CDK Bereitstellungsaktion** zu Ihrem Workflow hinzuzufügen. 

**Bevor Sie beginnen**

Bevor Sie die **AWS CDK Bereitstellungsaktion** zu Ihrem Workflow hinzufügen können, müssen Sie die folgenden Aufgaben ausführen:

1. **Halten Sie eine AWS CDK App bereit**. Sie können Ihre AWS CDK App mit AWS CDK Version 1 oder 2 in jeder Programmiersprache schreiben, die von der unterstützt wird AWS CDK. Stellen Sie sicher, dass Ihre AWS CDK App-Dateien verfügbar sind in:
   + Ein CodeCatalyst [Quell-Repository](source.md) oder 
   + Ein CodeCatalyst [Ausgabeartefakt](workflows-working-artifacts.md), das durch eine andere Workflow-Aktion generiert wurde

1. **Bootstrap für Ihre Umgebung AWS **. Um ein Bootstrap zu erstellen, können Sie:
   + Verwenden Sie eine der Methoden, die im *AWS Cloud Development Kit (AWS CDK) Entwicklerhandbuch* unter [How to Bootstrap](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto) beschrieben sind.
   + Verwenden Sie die **AWS CDK Bootstrap-Aktion**. Sie können diese Aktion im selben Workflow wie Ihre **AWS CDK Bereitstellung** oder in einem anderen Workflow hinzufügen. Stellen Sie einfach sicher, dass die Bootstrap-Aktion mindestens einmal ausgeführt wird, bevor **AWS CDK Sie die Bereitstellungsaktion** ausführen, damit die erforderlichen Ressourcen vorhanden sind. Weitere Informationen zur **AWS CDK Bootstrap-Aktion** finden Sie unter. [Bootstrapping einer AWS CDK App mit einem Workflow](cdk-boot-action.md)

     *Weitere Informationen zu Bootstrapping finden Sie unter [Bootstrapping](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) im Entwicklerhandbuch.AWS Cloud Development Kit (AWS CDK) *

------
#### [ Visual ]

**So fügen Sie die Aktion „AWS CDK Deploy“ mit dem Visual Editor hinzu**

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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS CDK Bereitstellungsaktion** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **AWS CDK Bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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.
**Anmerkung**  
Wenn Ihre **AWS CDK Bereitstellungsaktion** mit einem `npm install` Fehler fehlschlägt, finden Sie unter Informationen [Wie behebe ich „npm install“ -Fehler?](troubleshooting-workflows.md#troubleshooting-workflows-npm) zur Behebung des Fehlers.

------
#### [ YAML ]

**Um die Aktion „AWS CDK Deploy“ 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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS CDK Bereitstellungsaktion** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **AWS CDK Bereitstellen** aus. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Herunterladen**“, um [den Quellcode der Aktion anzuzeigen](workflows-view-source.md#workflows-view-source.title).
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.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 dann erneut **Commit** aus.
**Anmerkung**  
Wenn Ihre **AWS CDK Bereitstellungsaktion** mit einem `npm install` Fehler fehlschlägt, finden Sie unter Informationen [Wie behebe ich „npm install“ -Fehler?](troubleshooting-workflows.md#troubleshooting-workflows-npm) zur Behebung des Fehlers.

------

# Variablen 'AWS CDK bereitstellen'
<a name="cdk-dep-action-variables"></a>

Die Aktion **AWS CDK Deploy** erzeugt und setzt zur Laufzeit die folgenden Variablen. Diese werden als *vordefinierte Variablen* bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Stack-ID  |  Der Amazon-Ressourcenname (ARN) des AWS CDK Anwendungsstapels, für den während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-app-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 
|  Bereitstellungsplattform  |  Der Name der Bereitstellungsplattform. Fest codiert auf. `AWS:CloudFormation`  | 
|  Region  |  Der Regionalcode von AWS-Region , für den während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `us-west-2`  | 
|  BEREITSTELLUNG ÜBERSPRINGEN  |  Der Wert von `true` gibt an, dass die Bereitstellung Ihres AWS CDK Anwendungsstapels während der Workflow-Ausführung übersprungen wurde. Eine Stack-Bereitstellung wird übersprungen, wenn sich der Stack seit der letzten Bereitstellung nicht geändert hat. Diese Variable wird nur erzeugt, wenn ihr Wert ist`true`. Fest codiert auf. `true`  | 
|  *CloudFormation Variablen*  |  Die Aktion „**AWS CDK Bereitstellen**“ generiert nicht nur die zuvor aufgeführten Variablen, sondern stellt auch *CloudFormation*Ausgabevariablen als *Workflow-Variablen* zur Verwendung in nachfolgenden Workflow-Aktionen zur Verfügung. Standardmäßig macht die Aktion nur die ersten vier (oder weniger) CloudFormation Variablen verfügbar, die sie findet. Um festzustellen, welche verfügbar gemacht werden, führen Sie die **AWS CDK Bereitstellungsaktion** einmal aus und schauen Sie dann auf der Seite mit den Ausführungsdetails auf der Registerkarte **Variablen** nach. Wenn die auf der Registerkarte **Variablen** aufgelisteten Variablen nicht Ihren Wünschen entsprechen, können Sie mithilfe der `CfnOutputVariables` YAML-Eigenschaft andere Variablen konfigurieren. Weitere Informationen finden Sie in der [CfnOutputVariables](cdk-dep-action-ref.md#cdk.dep.cfn.out) Eigenschaftsbeschreibung im[Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md).  | 

# Aktion 'AWS CDK bereitstellen' YAML
<a name="cdk-dep-action-ref"></a>

Im Folgenden finden Sie die YAML-Definition der **AWS CDK Bereitstellungsaktion**. Informationen zur Verwendung dieser Aktion finden Sie unter[Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.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 action definition starts here.   
  CDKDeploy\$1nn: 
    Identifier: aws/cdk-deploy@v2
    DependsOn:
      - CDKBootstrap
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
    Outputs:
      Artifacts:
        - Name: cdk_artifact
          Files: 
            - "cdk.out/**/*"
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      StackName: my-cdk-stack
      Region: us-west-2
      Tags: '{"key1": "value1", "key2": "value2"}'
      Context: '{"key1": "value1", "key2": "value2"}'
      CdkCliVersion: version
      CdkRootPath: directory-containing-cdk.json-file
      CfnOutputVariables: '["CnfOutputKey1","CfnOutputKey2","CfnOutputKey3"]'
      CloudAssemblyRootPath: path-to-cdk.out
```

## CDKDeploy
<a name="cdk.dep.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `CDKDeploy_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aktionsname“**

## Identifier
<a name="cdk.dep.identifier"></a>

(*CDKDeploy*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

**Anmerkung**  
Wenn `aws/cdk-deploy@v2` Sie angeben, wird die Aktion für das [Image vom März 2024](build-images.md#build.default-image) ausgeführt, das neuere Tools wie Node.js 18 enthält. Durch `aws/cdk-deploy@v1` die Angabe wird die Aktion auf dem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt, das ältere Tools wie Node.js 16 enthält.

Standard: `aws/cdk-deploy@v2`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ CDKDeploy \$1nn/ aws/cdk-deploy @v2 label**

## DependsOn
<a name="cdk.dep.dependson"></a>

(*CDKDeploy*/**DependsOn**)

(Optional)

**Geben Sie eine Aktion oder Aktionsgruppe an, die erfolgreich ausgeführt werden muss, damit die Bereitstellungsaktion ausgeführt werden kann.AWS CDK ** Wir empfehlen, die **AWS CDK Bootstrap-Aktion** in der `DependsOn` Eigenschaft wie folgt anzugeben:

```
CDKDeploy:
  Identifier: aws/cdk-deploy@v2
  DependsOn:
    - CDKBootstrap
```

**Anmerkung**  
[Bootstrapping](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) ist eine zwingende Voraussetzung für die Bereitstellung einer App. AWS CDK **Wenn Sie die **AWS CDK Bootstrap-Aktion** nicht in Ihren Workflow aufnehmen, müssen Sie eine andere Möglichkeit finden, den AWS CDK Bootstrap-Stack bereitzustellen, bevor Sie Ihre Bereitstellungsaktion ausführen.AWS CDK ** Weitere Informationen finden Sie unter [Aktion „AWS CDK Deploy“ hinzufügen](cdk-dep-action-add.md) in [Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.md).

Weitere Informationen zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="cdk.dep.computename"></a>

(*CDKDeploy*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="cdk.dep.computetype"></a>

(*CDKDeploy*/Compute/**Type**)

([Compute](#cdk.dep.computename)Erforderlich, falls enthalten)

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: Konfiguration tab/Advanced — optional/ Berechnungstyp**

## Fleet
<a name="cdk.dep.computefleet"></a>

(*CDKDeploy*/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 im Leerlauf 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`

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Compute Fleet**

## Timeout
<a name="cdk.dep.timeout"></a>

(*CDKDeploy*/**Timeout**)

(Erforderlich)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Inputs
<a name="cdk.dep.inputs"></a>

(*CDKDeploy*/**Inputs**)

(Optional)

Der `Inputs` Abschnitt definiert die Daten, die während einer Workflow-Ausführung `CDKDeploy` benötigt werden.

**Anmerkung**  
Für jede **AWS CDK Bereitstellungsaktion** ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

## Sources
<a name="cdk.dep.inputs.sources"></a>

(*CDKDeploy*/Inputs/**Sources**)

(Erforderlich, wenn die AWS CDK App, die Sie bereitstellen möchten, in einem Quell-Repository gespeichert ist)

Wenn Ihre AWS CDK App in einem Quell-Repository gespeichert ist, geben Sie die Bezeichnung dieses Quell-Repositorys an. Die **AWS CDK Bereitstellungsaktion** synthetisiert die App in diesem Repository, bevor der Bereitstellungsprozess gestartet wird. Derzeit ist `WorkflowSource` das einzige unterstützte Label.

Wenn Ihre AWS CDK App nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="cdk.dep.inputs.artifacts"></a>

(*CDKDeploy*/Inputs/**Artifacts**)

(Erforderlich, wenn die AWS CDK App, die Sie bereitstellen möchten, in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer vorherigen Aktion gespeichert ist)

Wenn Ihre AWS CDK App in einem Artefakt enthalten ist, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Die **AWS CDK Bereitstellungsaktion** synthetisiert die App im angegebenen Artefakt zu einer CloudFormation Vorlage, bevor der Bereitstellungsprozess gestartet wird. Wenn Ihre AWS CDK App nicht in einem Artefakt enthalten ist, muss sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Artefakte“ — optional**

## Outputs
<a name="cdk.dep.outputs"></a>

(*CDKDeploy*/**Outputs**)

(Optional)

Definiert die Daten, die von der Aktion während einer Workflow-Ausführung ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts - output
<a name="cdk.dep.outputs.artifacts"></a>

(*CDKDeploy*/Outputs/**Artifacts**

(Optional)

Geben Sie die durch die Aktion generierten Artefakte an. Sie können diese Artefakte als Eingabe in anderen Aktionen referenzieren.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte**

## Name
<a name="cdk.dep.outputs.artifacts.name"></a>

(*CDKDeploy*/Outputs/Artifacts/**Name**)

(Erforderlich, falls [Artifacts - output](#cdk.dep.outputs.artifacts) enthalten)

Geben Sie den Namen des Artefakts an, das die CloudFormation Vorlage enthalten soll, die durch die **AWS CDK Bereitstellungsaktion** zur Laufzeit synthetisiert wird. Der Standardwert ist `cdk_artifact`. Wenn Sie kein Artefakt angeben, synthetisiert die Aktion die Vorlage, speichert sie jedoch nicht in einem Artefakt. Erwägen Sie, die synthetisierte Vorlage in einem Artefakt zu speichern, um sie zu Test- oder Fehlerbehebungszwecken aufzuzeichnen.

**Entsprechende Benutzeroberfläche: Gibt den Namen des tab/Artifacts/Add Artefakts aus/des Build-Artefakts**

## Files
<a name="cdk.dep.outputs.artifacts.files"></a>

(*CDKDeploy*/Outputs/Artifacts/**Files**)

(Erforderlich, wenn es enthalten ist) [Artifacts - output](#cdk.dep.outputs.artifacts)

Geben Sie die Dateien an, die in das Artefakt aufgenommen werden sollen. Sie müssen angeben`"cdk.out/**/*"`, dass die synthetisierte CloudFormation Vorlage Ihrer AWS CDK App eingeschlossen werden soll.

**Anmerkung**  
`cdk.out`ist das Standardverzeichnis, in dem synthetisierte Dateien gespeichert werden. Wenn Sie ein anderes Ausgabeverzeichnis als `cdk.out` in Ihrer `cdk.json` Datei angegeben haben, geben Sie dieses Verzeichnis hier statt an`cdk.out`.

Entsprechende Benutzeroberfläche: Gibt tab/Artifacts/Add **Artefakte/Dateien** aus, die von build erzeugt wurden

## Environment
<a name="cdk.dep.environment"></a>

(*CDKDeploy*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="cdk.dep.environment.name"></a>

(*CDKDeploy*/Environment/**Name**)

(Erforderlich, falls [Environment](#cdk.dep.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="cdk.dep.environment.connections"></a>

(*CDKDeploy*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="cdk.dep.environment.connections.name"></a>

(*CDKDeploy*/Environment/Connections/**Name**)

(Erforderlich, wenn [Connections](#cdk.dep.environment.connections) es enthalten ist)

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="cdk.dep.environment.connections.role"></a>

(*CDKDeploy*/Environment/Connections/**Role**)

(Erforderlich, wenn [Connections](#cdk.dep.environment.connections) es enthalten ist)

Geben Sie den Namen der Kontoverbindung an.

Geben Sie den Namen der IAM-Rolle an, mit der die **AWS CDK Bereitstellungsaktion** auf den AWS CDK Anwendungsstapel zugreift AWS und ihn bereitstellt. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf die in der folgenden Richtlinie angegebenen. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "VisualEditor0",
              "Effect": "Allow",
              "Action": [
                  "cloudformation:DescribeStackEvents",
                  "cloudformation:DescribeChangeSet",
                  "cloudformation:DescribeStacks",
                  "cloudformation:ListStackResources"
              ],
              "Resource": "*"
          },
          {
              "Sid": "VisualEditor1",
              "Effect": "Allow",
              "Action": "sts:AssumeRole",
              "Resource": "arn:aws:iam::111122223333:role/cdk-*"
          }
      ]
  }
  ```

------
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Configuration
<a name="cdk.dep.configuration"></a>

(*CDKDeploy*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## StackName
<a name="cdk.dep.stack.name"></a>

(*CDKDeploy*/Configuration/**StackName**)

(Erforderlich)

Der Name Ihres AWS CDK App-Stacks, wie er in der Einstiegspunktdatei im Verzeichnis Ihrer AWS CDK App erscheint. `bin` Das folgende Beispiel zeigt den Inhalt einer TypeScript Einstiegspunktdatei, wobei der Stackname unter hervorgehoben ist. *red italics* Wenn Ihre Einstiegspunktdatei in einer anderen Sprache ist, sieht sie ähnlich aus.

```
import * as cdk from 'aws-cdk-lib';
import { CdkWorksopTypescriptStack } from '../lib/cdk_workshop_typescript-stack';

const app = new cdk.App();
new CdkWorkshopTypescriptStack(app, 'CdkWorkshopTypescriptStack');
```

Sie können nur einen Stapel angeben.

**Tipp**  
Wenn Sie mehrere Stapel haben, können Sie einen übergeordneten Stapel mit verschachtelten Stacks erstellen. In dieser Aktion können Sie dann den übergeordneten Stapel angeben, um alle Stapel bereitzustellen.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Name des Stacks**

## Region
<a name="cdk.dep.region"></a>

(*CDKDeploy*/Configuration/**Region**)

(Optional)

Geben Sie an, AWS-Region in welchem Bereich der AWS CDK Anwendungsstapel bereitgestellt werden soll. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes).

Wenn Sie keine Region angeben, wird die **AWS CDK Bereitstellungsaktion** in der Region bereitgestellt, die in Ihrem AWS CDK Code angegeben ist. Weitere Informationen finden Sie im *AWS Cloud Development Kit (AWS CDK) Entwicklerhandbuch* unter [Umgebungen](https://docs.aws.amazon.com/cdk/v2/guide/environments.html).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Region“**

## Tags
<a name="cdk.dep.tags"></a>

(*CDKDeploy*/Configuration/**Tags**)

(Optional)

Geben Sie die Tags an, die Sie auf die AWS Ressourcen im AWS CDK Anwendungsstapel anwenden möchten. Tags werden sowohl auf den Stack selbst als auch auf einzelne Ressourcen im Stack angewendet. Weitere Informationen zum Taggen finden Sie unter [Tagging](https://docs.aws.amazon.com/cdk/v2/guide/tagging.html) im *AWS Cloud Development Kit (AWS CDK) Entwicklerhandbuch*.

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Tags**

## Context
<a name="cdk.dep.context"></a>

(*CDKDeploy*/Configuration/**Context**)

(Optional)

Geben Sie Kontexte in Form von Schlüssel-Wert-Paaren an, die dem Anwendungsstapel zugeordnet werden sollen. AWS CDK Weitere Informationen zu Kontexten finden Sie unter [Runtime-Kontexte](https://docs.aws.amazon.com/cdk/v2/guide/context.html) im *AWS Cloud Development Kit (AWS CDK) Developer* Guide.

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Kontext**

## CdkCliVersion
<a name="cdk.dep.cdk.cli.version"></a>

(*CDKDeploy*/Configuration/**CdkCliVersion**)

(Optional)

**Diese Eigenschaft ist in Version 1.0.13 oder höher der **AWS CDK Bereitstellungsaktion** und Version 1.0.8 oder höher der Bootstrap-Aktion verfügbar.AWS CDK **

Geben Sie eines der folgenden Elemente an:
+ Die Vollversion der AWS Cloud Development Kit (AWS CDK) Befehlszeilenschnittstelle (CLI) (auch AWS CDK Toolkit genannt), die diese Aktion verwenden soll. Beispiel: `2.102.1`. Erwägen Sie die Angabe einer Vollversion, um Konsistenz und Stabilität beim Erstellen und Bereitstellen Ihrer Anwendung zu gewährleisten.

  Oder
+ `latest`. Erwägen Sie `latest` die Angabe, um die neuesten Funktionen und Korrekturen der CDK-CLI nutzen zu können.

Die Aktion lädt die angegebene Version (oder die neueste Version) der AWS CDK CLI auf das CodeCatalyst [Build-Image](build-images.md) herunter und verwendet dann diese Version, um die Befehle auszuführen, die für die Bereitstellung Ihrer CDK-Anwendung oder das Bootstrap Ihrer AWS Umgebung erforderlich sind.

Eine Liste der unterstützten CDK-CLI-Versionen, die Sie verwenden können, finden Sie unter [AWS CDK Versionen](https://docs.aws.amazon.com/cdk/api/versions.html).

Wenn Sie diese Eigenschaft weglassen, verwendet die Aktion eine AWS CDK Standard-CLI-Version, die in einem der folgenden Themen beschrieben wird:
+ [CDK-CLI-Versionen, die von der Aktion „AWS CDK Deploy“ verwendet werden](cdk-dep-action.md#cdk-dep-action-cdk-version) 
+ [CDK-CLI-Versionen, die von der Aktion „AWS CDK Bootstrap“ verwendet werden](cdk-boot-action.md#cdk-boot-action-cdk-version)

Entsprechende Benutzeroberfläche: Registerkarte „**AWS CDK Konfiguration/CLI-Version**“

## CdkRootPath
<a name="cdk.dep.cdk.root.path"></a>

(*CDKDeploy*/Configuration/**CdkRootPath**)

(Optional)

Der Pfad zu dem Verzeichnis, das die `cdk.json` Datei Ihres AWS CDK Projekts enthält. Die **AWS CDK Bereitstellungsaktion** wird von diesem Ordner aus ausgeführt, und alle durch die Aktion erstellten Ausgaben werden diesem Verzeichnis hinzugefügt. Falls nicht angegeben, geht die **AWS CDK Bereitstellungsaktion** davon aus, dass sich die `cdk.json` Datei im Stammverzeichnis Ihres AWS CDK Projekts befindet.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Verzeichnis, in dem sich die** Datei cdk.json befindet

## CfnOutputVariables
<a name="cdk.dep.cfn.out"></a>

(*CDKDeploy*/Configuration/**CfnOutputVariables**)

(Optional)

Geben Sie an, welche `CfnOutput` Konstrukte in Ihrem AWS CDK Anwendungscode Sie als Workflow-Ausgabevariablen verfügbar machen möchten. Sie können dann in nachfolgenden Aktionen in Ihrem Workflow auf die Workflow-Ausgabevariablen verweisen. Weitere Informationen zu Variablen finden Sie CodeCatalyst unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Wenn Ihr AWS CDK Anwendungscode beispielsweise so aussieht:

```
import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
import * as cdk from 'aws-cdk-lib';
export class HelloCdkStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
      removalPolicy: RemovalPolicy.DESTROY,
    });
    new CfnOutput(this, 'bucketName', {
      value: bucket.bucketName,
      description: 'The name of the s3 bucket',
      exportName: 'amzn-s3-demo-bucket',
    });
    const table = new dynamodb.Table(this, 'todos-table', {
      partitionKey: {name: 'todoId', type: dynamodb.AttributeType.NUMBER},
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: RemovalPolicy.DESTROY,
    })
    new CfnOutput(this, 'tableName', {
      value: table.tableName,
      description: 'The name of the dynamodb table',
      exportName: 'myDynamoDbTable',
    });
    ...
  }
}
```

... und deine `CfnOutputVariables` Immobilie sieht so aus:

```
Configuration:
  ...
  CfnOutputVariables: '["bucketName","tableName"]'
```

... dann generiert die Aktion die folgenden Workflow-Ausgabevariablen:


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  bucketName  |  `bucket.bucketName`  | 
|  tableName  |  `table.tableName`  | 

Sie können dann in nachfolgenden Aktionen auf die `tableName` Variablen `bucketName` und verweisen. Informationen zum Verweisen auf Workflow-Ausgabevariablen in nachfolgenden Aktionen finden Sie unter[Verweisen auf eine vordefinierte Variable](workflows-working-with-variables-reference-output-vars.md).

Wenn Sie in der `CfnOutputVariables` Eigenschaft keine `CfnOutput` Konstrukte angeben, macht die Aktion die ersten vier (oder weniger) gefundenen CloudFormation Ausgabevariablen als Workflow-Ausgabevariablen verfügbar. Weitere Informationen finden Sie unter [Variablen 'AWS CDK bereitstellen'](cdk-dep-action-variables.md).

**Tipp**  
Um eine Liste aller von der Aktion erzeugten CloudFormation Ausgabevariablen zu erhalten, führen Sie den Workflow, der die **AWS CDK Bereitstellungsaktion** enthält, einmal aus und schauen Sie dann auf der Registerkarte **Protokolle** der Aktion nach. Die Protokolle enthalten eine Liste aller mit Ihrer AWS CDK App verknüpften CloudFormation Ausgabevariablen. Sobald Sie wissen, was alle CloudFormation Variablen sind, können Sie mithilfe der `CfnOutputVariables` Eigenschaft angeben, welche Sie in Workflow-Ausgabevariablen konvertieren möchten.

Weitere Informationen zu CloudFormation Ausgabevariablen finden Sie in der Dokumentation zum `CfnOutput` Konstrukt, die in der *AWS Cloud Development Kit (AWS CDK) API-Referenz* unter [class CfnOutput (construct)](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutput.html) verfügbar ist.

Entsprechende Benutzeroberfläche: Registerkarte „**CloudFormation Konfiguration/Ausgabevariablen**“

## CloudAssemblyRootPath
<a name="cdk.dep.cloud"></a>

(*CDKDeploy*/Configuration/**CloudAssemblyRootPath**)

(Optional)

Wenn Sie den Stack Ihrer AWS CDK App bereits zu einer Cloud-Assembly zusammengefasst haben (mithilfe der `cdk synth` Operation), geben Sie den Stammpfad des Cloud-Assembly-Verzeichnisses (`cdk.out`) an. Die CloudFormation Vorlage, die sich im angegebenen Cloud-Assembly-Verzeichnis befindet, wird von der **AWS CDK Bereitstellungsaktion** AWS-Konto mithilfe des `cdk deploy --app` Befehls in Ihnen bereitgestellt. Wenn die `--app` Option vorhanden ist, findet der `cdk synth` Vorgang nicht statt.

Wenn Sie kein Cloud-Assembly-Verzeichnis angeben, führt die **AWS CDK Bereitstellungsaktion** den `cdk deploy` Befehl ohne die `--app` Option aus. Ohne die `--app` Option wird durch den `cdk deploy` Vorgang Ihre AWS CDK App sowohl synthetisiert (`cdk synth`) als auch in Ihrem AWS-Konto bereitgestellt. 

**Warum sollte ich eine bestehende, synthetisierte Cloud-Assembly angeben, wenn die Aktion „AWS CDK Deploy“ die Synthese zur Laufzeit durchführen kann?**

Möglicherweise möchten Sie eine vorhandene, synthetisierte Cloud-Assembly spezifizieren, um:
+ **Stellen Sie sicher, dass bei jeder Ausführung der Aktion „AWS CDK Bereitstellen“ genau derselbe Satz von Ressourcen bereitgestellt wird**

  Wenn Sie keine Cloud-Assembly angeben, ist es möglich, dass die Aktion „**AWS CDK Bereitstellen**“ unterschiedliche Dateien synthetisiert und bereitstellt, je nachdem, wann sie ausgeführt wird. Die **AWS CDK Bereitstellungsaktion** könnte beispielsweise eine Cloud-Assembly mit einem Satz von Abhängigkeiten während einer Testphase und einem anderen Satz von Abhängigkeiten während einer Produktionsphase synthetisieren (wenn sich diese Abhängigkeiten zwischen den Phasen geändert haben). Um eine exakte Parität zwischen dem, was getestet wurde, und dem, was bereitgestellt wird, zu gewährleisten, empfehlen wir, einmal zu synthetisieren und dann das Feld **Pfad zum Cloud-Assembly-Verzeichnis** (visueller Editor) oder die `CloudAssemblyRootPath` Eigenschaft (YAML-Editor) zu verwenden, um die bereits synthetisierte Cloud-Assembly anzugeben.
+ **Verwenden Sie in der App nicht standardmäßige Paketmanager und Tools AWS CDK **

  Während eines `synth` Vorgangs versucht die **AWS CDK Bereitstellungsaktion**, Ihre App mithilfe von Standardtools wie npm oder pip auszuführen. Wenn die Aktion Ihre App mit diesen Tools nicht erfolgreich ausführen kann, findet die Synthese nicht statt und die Aktion schlägt fehl. Um dieses Problem zu umgehen, können Sie die genauen Befehle, die für die erfolgreiche Ausführung Ihrer App erforderlich sind, in der AWS CDK `cdk.json` App-Datei angeben und Ihre App dann mit einer Methode synthetisieren, die nicht die **AWS CDK Bereitstellungsaktion** beinhaltet. Nachdem die Cloud-Assembly generiert wurde, können Sie sie im Feld **Pfad zum Cloud-Assembly-Verzeichnis** (visueller Editor) oder `CloudAssemblyRootPath` Eigenschaft (YAML-Editor) der **AWS CDK Bereitstellungsaktion** angeben. 

Informationen zur Konfiguration der `cdk.json` Datei, sodass sie Befehle für die Installation und Ausführung Ihrer AWS CDK App enthält, finden Sie unter [Angeben des App-Befehls](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-app-command).

*Informationen zu den `cdk synth` Befehlen `cdk deploy` und sowie zu den `--app` Optionen finden Sie unter Stacks [bereitstellen, Stacks](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy) [synthetisieren](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-synth) und [Synthese überspringen](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-nosynth) im Entwicklerhandbuch.AWS Cloud Development Kit (AWS CDK) *

*Informationen zu Cloud-Assemblys finden Sie unter [Cloud Assembly in der API-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/cloud-assembly-schema-readme.html).AWS Cloud Development Kit (AWS CDK) *

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Pfad zum Cloud-Assembly-Verzeichnis**

# Bootstrapping einer AWS CDK App mit einem Workflow
<a name="cdk-boot-action"></a>

In diesem Abschnitt wird beschrieben, wie Sie eine AWS CDK Anwendung mithilfe eines CodeCatalyst Workflows booten. Um dies zu erreichen, müssen Sie Ihrem Workflow die **AWS CDK Bootstrap-Aktion** hinzufügen. [Die **AWS CDK Bootstrap-Aktion** stellt mithilfe der modernen Vorlage einen Bootstrap-Stack in Ihrer AWS Umgebung bereit.](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-template) Wenn bereits ein Bootstrap-Stack vorhanden ist, aktualisiert die Aktion ihn bei Bedarf. Das Vorhandensein eines Bootstrap-Stacks AWS ist eine Voraussetzung für die Bereitstellung einer AWS CDK App.

*Weitere Informationen zu Bootstrapping finden Sie unter [Bootstrapping](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) im Entwicklerhandbuch.AWS Cloud Development Kit (AWS CDK) *

**Topics**
+ [

## Wann sollte die Aktion „Bootstrap“ verwendet werden AWS CDK
](#cdk-boot-action-when-to-use)
+ [

## So funktioniert die Aktion „AWS CDK Bootstrap“
](#cdk-boot-action-how-it-works)
+ [

## CDK-CLI-Versionen, die von der Aktion „AWS CDK Bootstrap“ verwendet werden
](#cdk-boot-action-cdk-version)
+ [

## Von der Aktion „Bootstrap“AWS CDK verwendetes Runtime-Image
](#cdk-boot-action-runtime)
+ [

# Beispiel: Bootstrapping einer App AWS CDK
](cdk-boot-action-example-workflow.md)
+ [

# Die Aktion „AWS CDK Bootstrap“ hinzufügen
](cdk-boot-action-add.md)
+ [

# AWS CDK 'Bootstrap'-Variablen
](cdk-boot-action-variables.md)
+ [

# AWS CDK 'Bootstrap'-Aktion YAML
](cdk-boot-action-ref.md)

## Wann sollte die Aktion „Bootstrap“ verwendet werden AWS CDK
<a name="cdk-boot-action-when-to-use"></a>

Verwenden Sie diese Aktion, wenn Sie über einen Workflow verfügen, der eine AWS CDK App bereitstellt, und Sie den Bootstrap-Stack gleichzeitig bereitstellen (und bei Bedarf aktualisieren) möchten. In diesem Fall würden Sie die **AWS CDK Bootstrap-Aktion** demselben Workflow hinzufügen wie dem, der Ihre App bereitstellt. AWS CDK 

Verwenden **Sie diese Aktion nicht**, wenn eine der folgenden Bedingungen zutrifft:
+ Sie haben bereits einen Bootstrap-Stack mit einem anderen Mechanismus bereitgestellt und möchten ihn beibehalten (keine Updates).
+ Sie möchten eine [benutzerdefinierte Bootstrap-Vorlage verwenden, die von der **AWS CDK Bootstrap-Aktion**](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing) nicht unterstützt wird.

## So funktioniert die Aktion „AWS CDK Bootstrap“
<a name="cdk-boot-action-how-it-works"></a>

Der **AWS CDK Bootstrap** funktioniert wie folgt:

1. [Wenn Sie zur Laufzeit Version 1.0.7 oder früher der Aktion angegeben haben, lädt die Aktion die neueste CDK-CLI (auch AWS CDK Tookit genannt) in das Build-Image herunter. CodeCatalyst ](build-images.md)

   Wenn Sie Version 1.0.8 oder höher angegeben haben, ist die Aktion mit einer [bestimmten Version](cdk-dep-action.md#cdk-dep-action-cdk-version) der CDK-CLI gebündelt, sodass kein Download stattfindet.

1. Die Aktion verwendet die CDK-CLI, um den `cdk bootstrap` Befehl auszuführen. *Mit diesem Befehl werden die Bootstrapping-Aufgaben ausgeführt, die im Thema [Bootstrapping im Entwicklerhandbuch](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) beschrieben sind.AWS Cloud Development Kit (AWS CDK) *

## CDK-CLI-Versionen, die von der Aktion „AWS CDK Bootstrap“ verwendet werden
<a name="cdk-boot-action-cdk-version"></a>

Die folgende Tabelle zeigt, welche Version der CDK-CLI standardmäßig von verschiedenen Versionen der **AWS CDK Bootstrap-Aktion** verwendet wird.

**Anmerkung**  
Möglicherweise können Sie die Standardeinstellung überschreiben. Weitere Informationen finden Sie unter [CdkCliVersion](cdk-boot-action-ref.md#cdk.boot.cdk.cli.version) im [AWS CDK 'Bootstrap'-Aktion YAML](cdk-boot-action-ref.md).


| Version der AWS CDK Aktion „Bootstrap“ | AWS CDK CLI-Version | 
| --- | --- | 
|  1.0.0 — 1.0.7  |  brandneue  | 
|  1.0.8 oder später  |  2.99.1  | 

## Von der Aktion „Bootstrap“AWS CDK verwendetes Runtime-Image
<a name="cdk-boot-action-runtime"></a>

Die folgende Tabelle zeigt die Runtime-Umgebungs-Images, die zur Ausführung verschiedener Versionen der **AWS CDK Bootstrap-Aktion CodeCatalyst ** verwendet werden. Die Bilder enthalten verschiedene Sätze vorinstallierter Tools. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

**Anmerkung**  
Wir empfehlen, Ihre **AWS CDK Bootstrap-Aktion** auf Version 2.x zu aktualisieren, um die neuesten Tools nutzen zu können, die auf dem Image vom März 2024 verfügbar sind. Um die Aktion zu aktualisieren, legen Sie ihre `Identifier` Eigenschaft `aws/cdk-bootstrap@v2` in Ihrer Workflow-Definitionsdatei auf fest. Weitere Informationen finden Sie unter [Aktion 'AWS CDK bereitstellen' YAML](cdk-dep-action-ref.md). 


| Version der AWS CDK Aktion „Bootstrap“ | Bilder der Laufzeitumgebung | 
| --- | --- | 
|  1.x  |  Bilder vom November 2022  | 
|  2.x  |  Bilder vom März 2024  | 

# Beispiel: Bootstrapping einer App AWS CDK
<a name="cdk-boot-action-example-workflow"></a>

Informationen zu einem Workflow, [Beispiel: Eine AWS CDK App bereitstellen](cdk-dep-action-example-workflow.md) der die [Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.md) **AWS CDK Bootstrap-Aktion** enthält, finden Sie im.

# Die Aktion „AWS CDK Bootstrap“ hinzufügen
<a name="cdk-boot-action-add"></a>

 Verwenden Sie die folgenden Anweisungen, um die **AWS CDK Bootstrap-Aktion** zu Ihrem Workflow hinzuzufügen. 

**Bevor Sie beginnen**

Bevor Sie die **AWS CDK Bootstrap-Aktion** verwenden können, stellen Sie sicher, dass Sie eine AWS CDK App bereit haben. Die Bootstrap-Aktion synthetisiert die AWS CDK App vor dem Bootstrapping. Sie können Ihre App in jeder Programmiersprache schreiben, die von der unterstützt wird. AWS CDK

Stellen Sie sicher, dass Ihre AWS CDK App-Dateien verfügbar sind in:
+ Ein CodeCatalyst [Quell-Repository](source.md) oder 
+ Ein CodeCatalyst [Ausgabeartefakt](workflows-working-artifacts.md), das durch eine andere Workflow-Aktion generiert wurde

------
#### [ Visual ]

**Um die Aktion „AWS CDK Bootstrap“ mit dem visuellen 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS CDK Bootstrap-Aktion** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **AWS CDK Bootstrap.** Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben**, **Konfiguration** und **Ausgaben** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[AWS CDK 'Bootstrap'-Aktion YAML](cdk-boot-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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.
**Anmerkung**  
Wenn Ihre **AWS CDK Bootstrap-Aktion** mit einem `npm install` Fehler fehlschlägt, finden Sie weitere Informationen [Wie behebe ich „npm install“ -Fehler?](troubleshooting-workflows.md#troubleshooting-workflows-npm) zur Behebung des Fehlers unter.

------
#### [ YAML ]

**So fügen Sie die Aktion „AWS CDK Bootstrap“ mit dem YAML-Editor hinzu**

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. Wählen Sie links oben **\$1 Aktionen, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS CDK Bootstrap-Aktion** und wählen Sie **\$1**, um sie dem Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[AWS CDK 'Bootstrap'-Aktion YAML](cdk-boot-action-ref.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 dann erneut **Commit** aus.
**Anmerkung**  
Wenn Ihre **AWS CDK Bootstrap-Aktion** mit einem `npm install` Fehler fehlschlägt, finden Sie weitere Informationen [Wie behebe ich „npm install“ -Fehler?](troubleshooting-workflows.md#troubleshooting-workflows-npm) zur Behebung des Fehlers unter.

------

# AWS CDK 'Bootstrap'-Variablen
<a name="cdk-boot-action-variables"></a>

Die **AWS CDK Bootstrap-Aktion** erzeugt und setzt zur Laufzeit die folgenden Variablen. Diese werden als *vordefinierte Variablen* bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Bereitstellungsplattform  |  Der Name der Bereitstellungsplattform. Fest codiert auf. `AWS:CloudFormation`  | 
|  Region  |  Der Regionalcode des AWS-Region , für den der AWS CDK Bootstrap-Stack während der Workflow-Ausführung bereitgestellt wurde. Beispiel: `us-west-2`  | 
|  Stack-ID  |  Der Amazon-Ressourcenname (ARN) des bereitgestellten AWS CDK Bootstrap-Stacks. Beispiel: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-bootstrap-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 
|  BEREITSTELLUNG ÜBERSPRINGEN  |  Der Wert von `true` gibt an, dass die Bereitstellung Ihres AWS CDK Bootstrap-Stacks während der Workflow-Ausführung übersprungen wurde. Eine Stack-Bereitstellung wird übersprungen, wenn sich der Stack seit der letzten Bereitstellung nicht geändert hat. Diese Variable wird nur erzeugt, wenn ihr Wert ist`true`. Fest codiert auf. `true`  | 

# AWS CDK 'Bootstrap'-Aktion YAML
<a name="cdk-boot-action-ref"></a>

**Im Folgenden finden Sie die YAML-Definition der Bootstrap-Aktion.AWS CDK ** Informationen zur Verwendung dieser Aktion finden Sie unter. [Bootstrapping einer AWS CDK App mit einem Workflow](cdk-boot-action.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 action definition starts here.    
  CDKBootstrapAction\$1nn: 
    Identifier: aws/cdk-bootstrap@v2
    DependsOn:
      - action-name
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
    Outputs:
      Artifacts:
        - Name: cdk_bootstrap_artifacts
          Files: 
            - "cdk.out/**/*"
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      Region: us-west-2
      CdkCliVersion: version
```

## CDKBootstrapAction
<a name="cdk.boot.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `CDKBootstrapAction_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Anzeigename der Aktion**

## Identifier
<a name="cdk.boot.identifier"></a>

(*CDKBootstrapAction*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nicht, es sei denn, Sie möchten die Version ändern. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

**Anmerkung**  
Wenn `aws/cdk-bootstrap@v2` Sie angeben, wird die Aktion für das [Image vom März 2024](build-images.md#build.default-image) ausgeführt, das neuere Tools wie Node.js 18 enthält. Durch `aws/cdk-bootstrap@v1` die Angabe wird die Aktion auf dem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt, das ältere Tools wie Node.js 16 enthält.

Standard: `aws/cdk-bootstrap@v2`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ CDKBootstrapAction \$1nn/ aws/cdk-bootstrap @v2 label**

## DependsOn
<a name="cdk.boot.dependson"></a>

(*CDKBootstrapAction*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="cdk.boot.computename"></a>

(*CDKBootstrapAction*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="cdk.boot.computetype"></a>

(*CDKBootstrapAction*/Compute/**Type**)

(Erforderlich, wenn [Compute](#cdk.boot.computename) es enthalten ist)

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: Konfiguration tab/Advanced — optional/ Berechnungstyp**

## Fleet
<a name="cdk.boot.computefleet"></a>

(*CDKBootstrapAction*/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 können sofort Aktionen ausführen. 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`

**Entsprechende Benutzeroberfläche: Konfiguration tab/Advanced — optional/ Compute Fleet**

## Timeout
<a name="cdk.boot.timeout"></a>

(*CDKBootstrapAction*/**Timeout**)

(Erforderlich)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Inputs
<a name="cdk.boot.inputs"></a>

(*CDKBootstrapAction*/**Inputs**)

(Optional)

Der `Inputs` Abschnitt definiert die Daten, die die **AWS CDK Bootstrap-Aktion** während einer Workflow-Ausführung benötigt.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

**Anmerkung**  
Für jede **AWS CDK Bootstrap-Aktion** ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig.

## Sources
<a name="cdk.boot.inputs.sources"></a>

(*CDKBootstrapAction*/Inputs/**Sources**)

(Erforderlich, wenn Ihre AWS CDK App in einem Quell-Repository gespeichert ist)

Wenn Ihre AWS CDK App in einem Quell-Repository gespeichert ist, geben Sie die Bezeichnung dieses Quell-Repositorys an. Die **AWS CDK Bootstrap-Aktion** synthetisiert die App in diesem Repository, bevor der Bootstrapping-Vorgang gestartet wird. Derzeit ist das einzige unterstützte Repository-Label. `WorkflowSource`

Wenn Ihre AWS CDK App nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="cdk.boot.inputs.artifacts"></a>

(*CDKBootstrapAction*/Inputs/**Artifacts**)

(Erforderlich, wenn Ihre AWS CDK App in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer früheren Aktion gespeichert ist)

Wenn Ihre AWS CDK App in einem Artefakt enthalten ist, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Die **AWS CDK Bootstrap-Aktion** synthetisiert die App im angegebenen Artefakt zu einer CloudFormation Vorlage, bevor der Bootstrapping-Vorgang gestartet wird. Wenn Ihre AWS CDK App nicht in einem Artefakt enthalten ist, muss sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Artefakte“ — optional**

## Outputs
<a name="cdk.boot.outputs"></a>

(*CDKBootstrapAction*/**Outputs**)

(Optional)

Definiert die Daten, die von der Aktion während einer Workflow-Ausführung ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts - output
<a name="cdk.boot.outputs.artifacts"></a>

(*CDKBootstrapAction*/Outputs/**Artifacts**)

(Optional)

Geben Sie die durch die Aktion generierten Artefakte an. Sie können diese Artefakte als Eingabe in anderen Aktionen referenzieren.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte**

## Name
<a name="cdk.boot.outputs.artifacts.name"></a>

(*CDKBootstrapAction*/Outputs/Artifacts/**Name**)

(Erforderlich, wenn [Artifacts - output](#cdk.boot.outputs.artifacts) es enthalten ist)

Geben Sie den Namen des Artefakts an, das die CloudFormation Vorlage enthalten soll, die zur Laufzeit durch die **AWS CDK Bootstrap-Aktion** synthetisiert wird. Der Standardwert ist `cdk_bootstrap_artifacts`. Wenn Sie kein Artefakt angeben, synthetisiert die Aktion die Vorlage, speichert sie jedoch nicht in einem Artefakt. Erwägen Sie, die synthetisierte Vorlage in einem Artefakt zu speichern, um sie zu Test- oder Fehlerbehebungszwecken aufzuzeichnen.

**Entsprechende Benutzeroberfläche: Gibt den Namen des tab/Artifacts/Add Artefakts aus/des Build-Artefakts**

## Files
<a name="cdk.boot.outputs.artifacts.files"></a>

(*CDKBootstrapAction*/Outputs/Artifacts/**Files**)

(Erforderlich, wenn es enthalten ist) [Artifacts - output](#cdk.boot.outputs.artifacts)

Geben Sie die Dateien an, die in das Artefakt aufgenommen werden sollen. Sie müssen angeben`"cdk.out/**/*"`, dass die synthetisierte CloudFormation Vorlage Ihrer AWS CDK App eingeschlossen werden soll.

**Anmerkung**  
`cdk.out`ist das Standardverzeichnis, in dem synthetisierte Dateien gespeichert werden. Wenn Sie ein anderes Ausgabeverzeichnis als `cdk.out` in Ihrer `cdk.json` Datei angegeben haben, geben Sie dieses Verzeichnis hier statt an`cdk.out`.

Entsprechende Benutzeroberfläche: Gibt tab/Artifacts/Add **Artefakte/Dateien** aus, die von build erzeugt wurden

## Environment
<a name="cdk.boot.environment"></a>

(*CDKBootstrapAction*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um eine Verbindung zur herzustellen AWS-Konto, und verwendet die in der Amazon VPC-Verbindung angegebene IAM-Rolle, um eine [Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="cdk.boot.environment.name"></a>

(*CDKBootstrapAction*/Environment/**Name**)

(Erforderlich, falls [Environment](#cdk.boot.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="cdk.boot.environment.connections"></a>

(*CDKBootstrapAction*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="cdk.boot.environment.connections.name"></a>

(*CDKBootstrapAction*/Environment/Connections/**Name**)

(Erforderlich, falls enthalten[Connections](#cdk.boot.environment.connections))

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="cdk.boot.environment.connections.role"></a>

(*CDKBootstrapAction*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#cdk.boot.environment.connections))

Geben Sie den Namen der IAM-Rolle an, mit der die **AWS CDK Bootstrap-Aktion auf den Bootstrap-Stack** zugreift AWS und ihn hinzufügt. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die entsprechenden Richtlinien verfügt.

Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Configuration
<a name="cdk.boot.configuration"></a>

(*CDKBootstrapAction*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## Region
<a name="cdk.boot.region"></a>

(*CDKBootstrapAction*/Configuration/**Region**)

(Erforderlich)

Geben Sie an, AWS-Region in welchem Bereich der Bootstrap-Stack bereitgestellt werden soll. Diese Region sollte mit der Region übereinstimmen, in der Ihre AWS CDK App bereitgestellt wird. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Region“**

## CdkCliVersion
<a name="cdk.boot.cdk.cli.version"></a>

(*CDKBootstrapAction*/Configuration/**CdkCliVersion**)

(Optional)

**Diese Eigenschaft ist in Version 1.0.13 oder höher der **AWS CDK Bereitstellungsaktion** und Version 1.0.8 oder höher der AWS CDK Bootstrap-Aktion verfügbar.**

Geben Sie eines der folgenden Elemente an:
+ Die Vollversion der AWS Cloud Development Kit (AWS CDK) Befehlszeilenschnittstelle (CLI) (auch AWS CDK Toolkit genannt), die diese Aktion verwenden soll. Beispiel: `2.102.1`. Erwägen Sie die Angabe einer Vollversion, um Konsistenz und Stabilität beim Erstellen und Bereitstellen Ihrer Anwendung zu gewährleisten.

  Oder
+ `latest`. Erwägen Sie `latest` die Angabe, um die neuesten Funktionen und Korrekturen der CDK-CLI nutzen zu können.

Die Aktion lädt die angegebene Version (oder die neueste Version) der AWS CDK CLI auf das CodeCatalyst [Build-Image](build-images.md) herunter und verwendet dann diese Version, um die Befehle auszuführen, die für die Bereitstellung Ihrer CDK-Anwendung oder das Bootstrap Ihrer AWS Umgebung erforderlich sind.

Eine Liste der unterstützten CDK-CLI-Versionen, die Sie verwenden können, finden Sie unter [AWS CDK Versionen](https://docs.aws.amazon.com/cdk/api/versions.html).

Wenn Sie diese Eigenschaft weglassen, verwendet die Aktion eine AWS CDK Standard-CLI-Version, die in einem der folgenden Themen beschrieben wird:
+ [CDK-CLI-Versionen, die von der Aktion „AWS CDK Deploy“ verwendet werden](cdk-dep-action.md#cdk-dep-action-cdk-version) 
+ [CDK-CLI-Versionen, die von der Aktion „AWS CDK Bootstrap“ verwendet werden](cdk-boot-action.md#cdk-boot-action-cdk-version)

Entsprechende Benutzeroberfläche: Registerkarte „**AWS CDK Konfiguration/CLI-Version**“

# Veröffentlichen von Dateien in Amazon S3 mit einem Workflow
<a name="s3-pub-action"></a>

In diesem Abschnitt wird beschrieben, wie Sie Dateien mithilfe eines CodeCatalyst Workflows in Amazon S3 veröffentlichen. Um dies zu erreichen, müssen Sie Ihrem Workflow die **Amazon S3 S3-Aktion „Veröffentlichen**“ hinzufügen. Die **Amazon S3 S3-Veröffentlichungsaktion** kopiert Dateien aus einem Quellverzeichnis in einen Amazon S3 S3-Bucket. Das Quellverzeichnis kann sich in folgendem Verzeichnis befinden:
+ Ein [Quell-Repository](source.md) oder 
+ Ein [Ausgabeartefakt](workflows-working-artifacts.md), das durch eine andere Workflow-Aktion generiert wurde

**Topics**
+ [

## Wann sollte die Aktion „Amazon S3 Publish“ verwendet werden
](#s3-pub-action-when-to-use)
+ [

## Von der Aktion „Amazon S3 Publish“ verwendetes Runtime-Image
](#s3-pub-action-runtime)
+ [

# Beispiel: Dateien auf Amazon S3 veröffentlichen
](s3-pub-action-example-workflow.md)
+ [

# Die Aktion „Amazon S3 Publish“ hinzufügen
](s3-pub-action-add.md)
+ [

# Aktion „Amazon S3 veröffentlichen“ YAML
](s3-pub-action-ref.md)

## Wann sollte die Aktion „Amazon S3 Publish“ verwendet werden
<a name="s3-pub-action-when-to-use"></a>

Verwenden Sie diese Aktion, wenn:
+ Sie haben einen Workflow, der Dateien generiert, die Sie in Amazon S3 speichern möchten.

  Möglicherweise haben Sie einen Workflow, der eine statische Website erstellt, die Sie in Amazon S3 hosten möchten. In diesem Fall würde Ihr Workflow eine [Build-Aktion](build-add-action.md) zum Erstellen der HTML- und unterstützenden Dateien der Site sowie eine **Amazon S3-Veröffentlichungsaktion** zum Kopieren der Dateien nach Amazon S3 beinhalten.
+ Sie haben ein Quell-Repository, das Dateien enthält, die Sie in Amazon S3 speichern möchten.

  Möglicherweise haben Sie ein Quell-Repository mit Anwendungsquelldateien, die Sie jede Nacht in Amazon S3 archivieren möchten.

## Von der Aktion „Amazon S3 Publish“ verwendetes Runtime-Image
<a name="s3-pub-action-runtime"></a>

Die **Amazon S3 S3-Veröffentlichungsaktion** wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Beispiel: Dateien auf Amazon S3 veröffentlichen
<a name="s3-pub-action-example-workflow"></a>

Der folgende Beispiel-Workflow umfasst die **Amazon S3 S3-Veröffentlichungsaktion** zusammen mit einer Build-Aktion. Der Workflow erstellt eine statische Dokumentationswebsite und veröffentlicht sie dann in Amazon S3, wo sie gehostet wird. Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein **Trigger** — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine **Build-Aktion** (`BuildDocs`) — Beim Trigger erstellt die Aktion eine statische Dokumentationswebsite (`mkdocs build`) und fügt die zugehörigen HTML-Dateien und unterstützenden Metadaten zu einem Artefakt mit dem Namen `MyDocsSite` hinzu. Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).
+ Eine **Amazon S3-Veröffentlichungsaktion** (`PublishToS3`) — Nach Abschluss der Build-Aktion kopiert diese Aktion die Site im `MyDocsSite` Artefakt zum Hosten nach Amazon S3.

**Anmerkung**  
Das folgende Workflow-Beispiel dient der Veranschaulichung und funktioniert ohne zusätzliche Konfiguration nicht.

**Anmerkung**  
Im folgenden YAML-Code können Sie den `Connections:` Abschnitt weglassen, wenn Sie möchten. Wenn Sie diesen Abschnitt weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle in Ihrer Umgebung angegebene Rolle** die Berechtigungen und Vertrauensrichtlinien enthält, die für die **Amazon S3 S3-Veröffentlichungsaktion** erforderlich sind. Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md) Weitere Informationen zu den Berechtigungen und Vertrauensrichtlinien, die für die **Amazon S3 S3-Veröffentlichungsaktion** erforderlich sind, finden Sie in der Beschreibung der [Role](s3-pub-action-ref.md#s3.pub.environment.connections.role) Eigenschaft in der[Aktion „Amazon S3 veröffentlichen“ YAML](s3-pub-action-ref.md).

```
Name: codecatalyst-s3-publish-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  BuildDocs:
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      Steps:
        - Run: echo BuildDocs started on `date`
        - Run: pip install --upgrade pip
        - Run: pip install mkdocs
        - Run: mkdocs build
        - Run: echo BuildDocs completed on `date`
    Outputs:
      Artifacts:
      - Name: MyDocsSite
        Files:
          - "site/**/*"
        
  PublishToS3:
    Identifier: aws/s3-publish@v1
    Environment:
      Name: codecatalyst-s3-publish-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-s3-publish-build-role
    Inputs:
      Sources:
        - WorkflowSource
      Artifacts:
        - MyDocsSite
    Configuration:      
      DestinationBucketName: amzn-s3-demo-bucket
      SourcePath: /artifacts/PublishToS3/MyDocSite/site
      TargetPath: my/docs/site
```

# Die Aktion „Amazon S3 Publish“ hinzufügen
<a name="s3-pub-action-add"></a>

 Verwenden Sie die folgenden Anweisungen, um die **Amazon S3 S3-Veröffentlichungsaktion** zu Ihrem Workflow hinzuzufügen. 

------
#### [ Visual ]

**Um die Aktion „Amazon S3 Publish“ 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **Amazon S3 S3-Aktion „Veröffentlichen**“ und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **Amazon S3 Publish**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben**, **Konfiguration** und **Ausgaben** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion „Amazon S3 veröffentlichen“ YAML](s3-pub-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „Amazon S3 Publish“ mit dem YAML-Editor hinzuzufügen**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **Amazon S3 S3-Aktion „Veröffentlichen**“ und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **Amazon S3 Publish**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion „Amazon S3 veröffentlichen“ YAML](s3-pub-action-ref.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 dann erneut **Commit** aus.

------

# Aktion „Amazon S3 veröffentlichen“ YAML
<a name="s3-pub-action-ref"></a>

Im Folgenden finden Sie die YAML-Definition der **Amazon S3 S3-Veröffentlichungsaktion**. Informationen zur Verwendung dieser Aktion finden Sie unter[Veröffentlichen von Dateien in Amazon S3 mit einem Workflow](s3-pub-action.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 action definition starts here.    
  S3Publish\$1nn: 
    Identifier: aws/s3-publish@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      SourcePath: my/source
      DestinationBucketName: amzn-s3-demo-bucket
      TargetPath: my/target
```

## S3Publish
<a name="s3.pub.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `S3Publish_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aktionsname“**

## Identifier
<a name="s3.pub.identifier"></a>

(*S3Publish*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nicht, es sei denn, Sie möchten die Version ändern. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/s3-publish@v1`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ S3Publish \$1nn/ aws/s3-publish @v1 label**

## DependsOn
<a name="s3.pub.dependson"></a>

(*S3Publish*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="s3.pub.computename"></a>

(*S3Publish*/**Compute**)

(Optional)

Die Rechen-Engine, die zur Ausführung Ihrer Workflow-Aktionen verwendet wurde. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="s3.pub.computetype"></a>

(*S3Publish*/Compute/**Type**)

(Erforderlich, wenn [Compute](#s3.pub.computename) es enthalten ist)

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: Registerkarte „**Konfiguration/Berechnungstyp**“

## Fleet
<a name="s3.pub.computefleet"></a>

(*S3Publish*/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 können sofort Aktionen ausführen. 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`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„Flotte **berechnen**“

## Timeout
<a name="s3.pub.timeout"></a>

(*S3Publish*/**Timeout**)

(Erforderlich)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Inputs
<a name="s3.pub.inputs"></a>

(*S3Publish*/**Inputs**)

(Optional)

Der `Inputs` Abschnitt definiert die Daten, die während einer Workflow-Ausführung `S3Publish` benötigt werden.

**Anmerkung**  
Für jede **AWS CDK Bereitstellungsaktion** sind maximal vier Eingaben (eine Quelle und drei Artefakte) zulässig. Variablen werden auf diese Summe nicht angerechnet.

Wenn Sie auf Dateien verweisen müssen, die sich in unterschiedlichen Eingaben befinden (z. B. eine Quelle und ein Artefakt), ist die Quelleingabe die primäre Eingabe und das Artefakt die sekundäre Eingabe. Verweise auf Dateien in sekundären Eingaben benötigen ein spezielles Präfix, um sie von der primären Eingabe zu unterscheiden. Details hierzu finden Sie unter [Beispiel: Referenzieren von Dateien in mehreren Artefakten](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“**

## Sources
<a name="s3.pub.inputs.sources"></a>

(*S3Publish*/Inputs/**Sources**)

(Erforderlich, wenn die Dateien, die Sie auf Amazon S3 veröffentlichen möchten, in einem Quell-Repository gespeichert sind)

Wenn die Dateien, die Sie in Amazon S3 veröffentlichen möchten, in einem Quell-Repository gespeichert sind, geben Sie die Bezeichnung dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label`WorkflowSource`.

Wenn die Dateien, die Sie in Amazon S3 veröffentlichen möchten, nicht in einem Quell-Repository enthalten sind, müssen sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="s3.pub.inputs.artifacts"></a>

(*S3Publish*/Inputs/**Artifacts**)

(Erforderlich, wenn die Dateien, die Sie auf Amazon S3 veröffentlichen möchten, in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer vorherigen Aktion gespeichert sind)

Wenn die Dateien, die Sie auf Amazon S3 veröffentlichen möchten, in einem Artefakt enthalten sind, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Wenn Ihre Dateien nicht in einem Artefakt enthalten sind, müssen sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Variables - input
<a name="s3.pub.inputs.variables"></a>

(*S3Publish*/Inputs/**Variables**)

(Optional)

Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Variablen“ — optional**

## Environment
<a name="s3.pub.environment"></a>

(*S3Publish*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="s3.pub.environment.name"></a>

(*S3Publish*/Environment/**Name**)

(Erforderlich, wenn [Environment](#s3.pub.environment) es enthalten ist)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="s3.pub.environment.connections"></a>

(*S3Publish*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="s3.pub.environment.connections.name"></a>

(*S3Publish*/Environment/Connections/**Name**)

(Erforderlich, wenn [Connections](#s3.pub.environment.connections) es enthalten ist)

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="s3.pub.environment.connections.role"></a>

(*S3Publish*/Environment/Connections/**Role**)

(Erforderlich, wenn [Connections](#s3.pub.environment.connections) es enthalten ist)

Geben Sie den Namen der IAM-Rolle an, die die **Amazon S3-Veröffentlichungsaktion** für den Zugriff auf AWS und das Kopieren von Dateien nach Amazon S3 verwendet. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf diejenigen, die in der folgenden Richtlinie aufgeführt sind. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "VisualEditor0",
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:ListBucket",
                  "s3:DeleteObject"
              ],
              "Resource": [
                  "arn:aws:s3:::bucket-name",
                  "arn:aws:s3:::bucket-name/*"
              ]
          }
      ]
  }
  ```

------
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Configuration
<a name="s3.pub.configuration"></a>

(*S3Publish*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## SourcePath
<a name="s3.pub.source.directory"></a>

(*S3Publish*/Configuration/**SourcePath**)

(Erforderlich)

Geben Sie den Namen und den Pfad eines Verzeichnisses oder einer Datei an, die Sie in Amazon S3 veröffentlichen möchten. Das Verzeichnis oder die Datei kann sich in einem Quell-Repository oder einem Artefakt aus einer früheren Aktion befinden und ist relativ zum Quell-Repository oder Artefakt-Root.

Beispiele:

Durch die Angabe wird der Inhalt von `/myFolder` nach Amazon S3 `./myFolder/` kopiert, wobei die zugrunde liegende Verzeichnisstruktur beibehalten wird.

Spezifizierung von `./myFolder/myfile.txt` Kopien *nur* `myfile.txt` für Amazon S3. (Die Verzeichnisstruktur wurde entfernt.)

Sie können keine Platzhalter verwenden.

**Anmerkung**  
Möglicherweise müssen Sie dem Verzeichnis- oder Dateipfad ein Präfix hinzufügen, um anzugeben, in welchem Artefakt oder in welcher Quelle es zu finden ist. Weitere Informationen erhalten Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Quellpfad**

## DestinationBucketName
<a name="s3.pub.dest.bucket"></a>

(*S3Publish*/Configuration/**DestinationBucketName**)

(Erforderlich)

Geben Sie den Namen des Amazon S3 S3-Buckets an, in dem Sie Dateien veröffentlichen möchten.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Ziel-Bucket“ — optional**

## TargetPath
<a name="s3.pub.dest.directory"></a>

(*S3Publish*/Configuration/**TargetPath**)

(Optional)

Geben Sie den Namen und den Pfad des Verzeichnisses in Amazon S3 an, in dem Sie Ihre Dateien veröffentlichen möchten. Wenn das Verzeichnis nicht existiert, wird es erstellt. Der Verzeichnispfad darf den Bucket-Namen nicht enthalten.

Beispiele:

`myS3Folder`

`./myS3Folder/myS3Subfolder`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Zielverzeichnis“ — optional**

# Einsatz in AWS-Konten und VPCs
<a name="deploy-environments"></a>

Mithilfe von [CodeCatalyst Workflows](workflow.md) können Sie Anwendungen und andere Ressourcen für Target AWS-Konto s und Amazon VPCs in der AWS Cloud bereitstellen. Um diese Bereitstellungen zu ermöglichen, müssen Sie CodeCatalyst Umgebungen einrichten.

Eine CodeCatalyst *Umgebung*, nicht zu verwechseln mit einer [Entwicklungsumgebung](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html), definiert das Ziel AWS-Konto und die optionale Amazon-VPC, mit der ein CodeCatalyst [Workflow](workflow.md) eine Verbindung herstellt. Eine Umgebung definiert auch die [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Workflow benötigt, um auf die AWS Dienste und Ressourcen innerhalb des Zielkontos zuzugreifen.

Sie können mehrere Umgebungen einrichten und ihnen Namen wie „Entwicklung“, „Test“, „Staging“ und „Produktion“ geben. Wenn Sie die Bereitstellung in diesen Umgebungen durchführen, werden Informationen zu den Bereitstellungen auf den Registerkarten CodeCatalyst **Bereitstellungsaktivität** und **Bereitstellungsziele** in der Umgebung angezeigt.

## Erste Schritte mit Umgebungen?
<a name="deploy-environments-get-started"></a>

Die allgemeinen Schritte zum Hinzufügen und Verwenden einer CodeCatalyst Umgebung lauten wie folgt:

1. **Verbinde in deinem CodeCatalyst Bereich ein oder mehrere AWS Konten**. Fügen Sie während dieses Vorgangs die IAM-Rollen hinzu, die Ihr Workflow für den Zugriff auf Ressourcen in Ihrem AWS-Konto benötigt. Weitere Informationen finden Sie unter [Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md).

1. **Erstellen Sie in Ihrem CodeCatalyst Projekt eine Umgebung**, die eine der Rollen AWS-Konto s und IAM aus Schritt 1 enthält. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](deploy-environments-creating-environment.md).

1. Fügen Sie in Ihrem CodeCatalyst Projekt in einem Workflow **eine [Aktion](workflows-actions.md) hinzu, die auf die Umgebung verweist, die** Sie in Schritt 2 erstellt haben. Weitere Informationen finden Sie unter [Aktion zu einem Workflow hinzufügen](workflows-add-action.md).

   Sie haben jetzt eine Umgebung konfiguriert. Die Aktion kann nun Ressourcen in der in der Umgebung AWS-Konto angegebenen Umgebung bereitstellen.

**Anmerkung**  
Sie können der Umgebung auch eine Amazon VPC hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen von VPC-Verbindungen für einen Space](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) im *CodeCatalyst Administrationshandbuch* und[Eine VPC mit einer Umgebung verknüpfen](deploy-environments-associate-vpc.md).

## Können mehrere Umgebungen innerhalb eines einzigen Workflows existieren?
<a name="deploy-environments-multiple"></a>

Ja. Wenn ein Workflow mehrere Aktionen umfasst, kann jeder dieser Aktionen eine Umgebung zugewiesen werden. Sie könnten beispielsweise einen Workflow haben, der zwei Bereitstellungsaktionen umfasst, wobei einer Aktion eine `my-staging-enviroment` Umgebung und einer anderen eine `my-production-environment` Umgebung zugewiesen wird.

## Welche Workflow-Aktionen unterstützen Umgebungen?
<a name="deploy-environments-supported"></a>

Jede Workflow-Aktion, die Ressourcen in der AWS Cloud bereitstellt oder aus anderen Gründen (z. B. Überwachung und Berichterstattung) mit AWS Diensten kommuniziert, unterstützt Umgebungen.

## Welche Aktionen unterstützen die Anzeige ihrer Bereitstellungsinformationen in? CodeCatalyst
<a name="deploy-environments-supported-targets"></a>

Von den Workflow-Aktionen, die Umgebungen unterstützen, unterstützen nur wenige die Anzeige ihrer Bereitstellungsinformationen auf den Seiten **Bereitstellungsaktivität** und **Bereitstellungsziele** der CodeCatalyst Konsole.

Die folgenden Workflow-Aktionen unterstützen die Anzeige ihrer Bereitstellungsinformationen:
+ ** CloudFormation Stack bereitstellen** — Weitere Informationen finden Sie unter [Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md)
+ Auf **Amazon ECS bereitstellen** — Weitere Informationen finden Sie unter [Bereitstellung auf Amazon ECS mit einem Workflow](deploy-action-ecs.md)
+ Auf einem **Kubernetes-Cluster bereitstellen** — Weitere Informationen finden Sie unter [Bereitstellung auf Amazon EKS mit einem Workflow](deploy-action-eks.md)
+ **AWS CDK bereitstellen** — Weitere Informationen finden Sie unter [Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.md)

## Unterstützte Regionen
<a name="deploy-environments-supported-regions"></a>

Auf der Seite **Umgebungen** können Ressourcen in jeder AWS Region angezeigt werden.

## Ist eine Umgebung verpflichtend?
<a name="deploy-environments-optional-or-mandatory"></a>

Eine Umgebung ist obligatorisch, wenn die Workflow-Aktion, der sie zugewiesen ist, Ressourcen in der AWS Cloud bereitstellt oder aus anderen Gründen (z. B. Überwachung und Berichterstattung) mit AWS Diensten kommuniziert.

Wenn Sie beispielsweise eine Build-Aktion haben, die eine Anwendung erstellt, aber nicht mit Ihrer AWS-Konto oder Amazon VPC kommunizieren muss, müssen Sie der Aktion keine Umgebung zuweisen. Wenn die Build-Aktion jedoch Protokolle an den CloudWatch Amazon-Service in Ihrem sendet AWS-Konto, muss der Aktion eine Umgebung zugewiesen werden. 

**Topics**
+ [

## Erste Schritte mit Umgebungen?
](#deploy-environments-get-started)
+ [

## Können mehrere Umgebungen innerhalb eines einzigen Workflows existieren?
](#deploy-environments-multiple)
+ [

## Welche Workflow-Aktionen unterstützen Umgebungen?
](#deploy-environments-supported)
+ [

## Welche Aktionen unterstützen die Anzeige ihrer Bereitstellungsinformationen in? CodeCatalyst
](#deploy-environments-supported-targets)
+ [

## Unterstützte Regionen
](#deploy-environments-supported-regions)
+ [

## Ist eine Umgebung verpflichtend?
](#deploy-environments-optional-or-mandatory)
+ [

# Erstellen einer Umgebung
](deploy-environments-creating-environment.md)
+ [

# Eine Umgebung mit einer Aktion verknüpfen
](deploy-environments-add-app-to-environment.md)
+ [

# Eine VPC mit einer Umgebung verknüpfen
](deploy-environments-associate-vpc.md)
+ [

# Einen AWS-Konto mit einer Umgebung verknüpfen
](deploy-environments-associate-account.md)
+ [

# Die IAM-Rolle einer Aktion ändern
](deploy-environments-switch-role.md)

# Erstellen einer Umgebung
<a name="deploy-environments-creating-environment"></a>

Verwenden Sie die folgenden Anweisungen, um eine Umgebung zu erstellen, die Sie später einer Workflow-Aktion zuordnen können.

**Bevor Sie beginnen**

Sie benötigen Folgendes:
+ Ein CodeCatalyst Leerzeichen. Weitere Informationen finden Sie unter [Richten Sie ein und melden Sie sich an CodeCatalystRichten Sie ein und melden Sie sich an bei CodeCatalyst](setting-up-topnode.md).
+ Ein CodeCatalyst Projekt. Weitere Informationen finden Sie unter [Ein Projekt mit einem Blueprint erstellen](projects-create.md#projects-create-console-template).
+ Eine AWS Kontoverbindung, die die IAM-Rollen enthält, auf die Ihre Workflow-Aktion zugreifen AWS muss. Informationen zum Erstellen einer Kontoverbindung finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Sie können maximal eine Kontoverbindung pro Umgebung verwenden.
**Anmerkung**  
Sie können eine Umgebung ohne Kontoverbindung erstellen. Sie müssen jedoch später zurückkommen und die Verbindung hinzufügen.
+ Eine der folgenden CodeCatalyst Rollen:
  + **Bereichsadministrator**
  + **Projektadministrator**
  + **Beitragender**
**Anmerkung**  
Wenn Sie die **Rolle Mitwirkender** haben, können Sie eine Umgebung erstellen, sie jedoch keiner AWS-Konto Verbindung zuordnen. Sie müssen jemanden mit der Rolle **Space-Administrator** oder **Projektadministrator** bitten, die Umgebung einer AWS-Konto Verbindung zuzuordnen.

   Weitere Informationen zu Berechtigungen und Rollen finden Sie unter[Benutzern Projektberechtigungen gewähren](projects-members.md).

**So erstellen Sie eine Umgebung**

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 Environments aus.**

1. Geben Sie im Feld **Umgebungsname** einen Namen ein, z. B. **Production** oder. **Staging**

1. Wählen Sie **unter Umgebungstyp** eine der folgenden Optionen aus:
   + **Nicht-Produktionsumgebung** — Eine Umgebung, in der Sie Ihre Anwendung testen können, um sicherzustellen, dass sie wie vorgesehen funktioniert, bevor Sie sie in die Produktionsumgebung überführen.
   + **Produktion** — Eine „Live-Umgebung“, die öffentlich verfügbar ist und Ihre fertige Anwendung hostet.

     Wenn Sie „**Produktion**“ wählen, wird auf der Benutzeroberfläche neben allen Aktionen, mit denen die Umgebung verknüpft ist, ein **Produktions-Logo** angezeigt. Anhand des Badges können Sie schnell erkennen, welche Aktionen in der Produktion bereitgestellt werden. Abgesehen vom Aussehen des Badges gibt es keine Unterschiede zwischen Produktions- und Nicht-Produktionsumgebungen.

1. (Optional) Geben Sie **unter Beschreibung** eine Beschreibung ein, z. B. **Production environment for the hello-world app**

1. Wählen Sie unter **AWS-Konto Verbindung — optional** die AWS Kontoverbindung aus, die Sie dieser Umgebung zuordnen möchten. Workflow-Aktionen, denen diese Umgebung zugewiesen ist, können eine Verbindung mit der zugehörigen Umgebung herstellen AWS-Konto. Weitere Informationen zum Erstellen von AWS-Konto Verbindungen in CodeCatalyst finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md).

   Wenn die AWS-Konto Verbindung, die Sie verwenden möchten, nicht aufgeführt ist, liegt das möglicherweise daran, dass sie in Ihrem Projekt nicht zulässig ist. Weitere Informationen finden Sie unter [Konfiguration von projektbeschränkten Kontoverbindungen](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) im * CodeCatalyst Amazon-Administratorhandbuch*.

1. Wählen Sie unter **Standard-IAM-Rolle** die IAM-Rolle aus, die Sie dieser Umgebung zuordnen möchten. Workflow-Aktionen, denen diese Umgebung zugewiesen ist, erben diese IAM-Rolle und können sie verwenden, um eine Verbindung zu Diensten und Ressourcen in Ihrer Umgebung herzustellen. AWS-Konto

   Wenn Sie die Umgebung mehreren Aktionen zuweisen müssen und für diese Aktionen IAM-Rollen erforderlich sind, die sich von der hier angegebenen Standardrolle unterscheiden, können Sie die verschiedenen Rollen auf der Registerkarte **Konfiguration** jeder Aktion mithilfe der Option Rolle **wechseln** angeben. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

   Wenn die IAM-Rolle, die Sie als Standard verwenden möchten, nicht aufgeführt ist, liegt das möglicherweise daran, dass Sie sie Ihrer AWS-Konto Verbindung noch nicht hinzugefügt haben. Informationen zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter. [Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md)

1. (Optional) Wählen Sie **VPC VPC-Verbindung** eine VPC-Verbindung aus, die Sie dieser Umgebung zuordnen möchten. Weitere Informationen zum Erstellen von VPC-Verbindungen finden Sie unter [Managing Amazon Virtual Private Clouds](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html) im *Amazon CodeCatalyst Administrator Guide*.

   Wenn die VPC-Verbindung, die Sie verwenden möchten, nicht aufgeführt ist, kann dies daran liegen, dass sie eine AWS-Konto Verbindung enthält, die in Ihrem Projekt nicht zulässig ist. Weitere Informationen finden Sie unter [Konfiguration von projektbeschränkten Kontoverbindungen](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) im * CodeCatalyst Amazon-Administratorhandbuch*.

1. Wählen Sie Umgebung **erstellen**. CodeCatalyst erstellt eine leere Umgebung.

**Nächste Schritte**
+ Nachdem Sie eine Umgebung erstellt haben, können Sie sie einer Workflow-Aktion zuordnen. Weitere Informationen finden Sie unter [Eine Umgebung mit einer Aktion verknüpfen](deploy-environments-add-app-to-environment.md).

# Eine Umgebung mit einer Aktion verknüpfen
<a name="deploy-environments-add-app-to-environment"></a>

Wenn Sie eine Umgebung mit einer [unterstützten Workflow-Aktion](deploy-environments.md#deploy-environments-supported) verknüpfen, werden der Aktion die Standard-IAM-Rolle der Umgebung und die optionale Amazon VPC zugewiesen. AWS-Konto Die Aktion kann dann AWS-Konto mithilfe der IAM-Rolle eine Verbindung herstellen und diese bereitstellen sowie eine Verbindung zur optionalen Amazon-VPC herstellen.

Verwenden Sie die folgenden Anweisungen, um einer Aktion eine Umgebung zuzuordnen.

## Schritt 1: Ordnen Sie die Umgebung einer Workflow-Aktion zu
<a name="deploy-environments-add-app-to-environment-assoc"></a>

Gehen Sie wie folgt vor, um einer Workflow-Aktion eine Umgebung zuzuordnen.

------
#### [ Visual ]

**So verknüpfen Sie mithilfe des visuellen Editors eine Umgebung mit einer Workflow-Aktion**

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 eine Aktion aus, die von Umgebungen unterstützt wird. Weitere Informationen finden Sie unter [Welche Aktionen unterstützen die Anzeige ihrer Bereitstellungsinformationen in? CodeCatalyst](deploy-environments.md#deploy-environments-supported-targets).

1. Wählen Sie die Registerkarte **Konfiguration** und geben Sie Informationen im Feld **Umgebung** wie folgt an.

   **Umgebung**

   Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um eine Verbindung zur herzustellen AWS-Konto, und verwendet die in der Amazon VPC-Verbindung angegebene IAM-Rolle, um eine [Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.
**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

   Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

1. (Optional) Ändern Sie die der Aktion zugeordnete IAM-Rolle. Möglicherweise möchten Sie die Rolle ändern, wenn sie die falschen Berechtigungen für die Aktion enthält.

    Um die Rolle zu ändern:

   1. Im Bereich **Was ist drin*my-environment*?** und wählen Sie das vertikale Ellipsensymbol (![\[Ellipsis.\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/elipsis.png)).

   1. Wählen Sie eine der folgenden Optionen:
      +  **Rolle wechseln**. Wählen Sie diese Option, um die von dieser Aktion verwendete IAM-Rolle zu ändern, und zwar nur für diese Aktion. Andere Aktionen verwenden weiterhin die Standard-IAM-Rolle, die in der zugehörigen Umgebung angegeben ist. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).
      +  **Umgebung bearbeiten.** Wählen Sie diese Option, um die in Ihrer Umgebung aufgeführte Standard-IAM-Rolle zu ändern. Wenn Sie diese Option wählen, beginnt Ihre Aktion — und jede andere Aktion, die mit derselben Umgebung verknüpft ist — die neue Standard-IAM-Rolle zu verwenden.
**Wichtig**  
Seien Sie vorsichtig, wenn Sie die Standard-IAM-Rolle aktualisieren. Das Ändern der Rolle kann dazu führen, dass Aktionen fehlschlagen, wenn die Berechtigungen in der Rolle nicht für alle Aktionen ausreichen, die die Umgebung gemeinsam nutzen.

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 mithilfe des YAML-Editors eine Umgebung mit einer Workflow-Aktion zu verknüpfen**

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 der Workflow-Aktion, die Sie einer Umgebung zuordnen möchten, Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     Environment:
       Name: environment-name
   ```

   Weitere Informationen finden Sie im [Aktionstypen](workflows-actions.md#workflows-actions-types) Thema. Dieses Thema enthält Links zur Dokumentation für jede Aktion, einschließlich der zugehörigen YAML-Referenz.

1. (Optional) Wenn Sie möchten, dass die Aktion eine andere Rolle als die Standard-IAM-Rolle verwendet, die in der Umgebung aufgeführt ist, fügen Sie einen `Connections:` Abschnitt hinzu, der die Rolle enthält, die Sie verwenden möchten. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.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**.

------

## Schritt 2: Füllen Sie die Seite mit den Bereitstellungsaktivitäten aus
<a name="deploy-environments-add-app-to-environment-run"></a>

Nachdem Sie eine Umgebung mit einer Workflow-Aktion verknüpft haben, können Sie die Seiten **Bereitstellungsaktivität** und **Bereitstellungsziele** im Bereich **Umgebungen** der CodeCatalyst Konsole mit Bereitstellungsinformationen füllen. Verwenden Sie die folgenden Anweisungen, um diese Seiten zu füllen.

**Anmerkung**  
Nur bei wenigen Aktionen wird die Anzeige ihrer Bereitstellungsinformationen in der CodeCatalyst Konsole unterstützt. Weitere Informationen finden Sie unter [Welche Aktionen unterstützen die Anzeige ihrer Bereitstellungsinformationen in? CodeCatalyst](deploy-environments.md#deploy-environments-supported-targets).

**Um Bereitstellungsinformationen hinzuzufügen CodeCatalyst**

1. Wenn eine Workflow-Ausführung nicht automatisch gestartet wurde, als Sie Ihre Änderungen übernommen haben[Schritt 1: Ordnen Sie die Umgebung einer Workflow-Aktion zu](#deploy-environments-add-app-to-environment-assoc), starten Sie eine Ausführung manuell wie folgt:

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

   Bei der Workflow-Ausführung wird eine neue Bereitstellung gestartet, CodeCatalyst woraufhin Bereitstellungsinformationen hinzugefügt CodeCatalyst werden müssen.

1. Stellen Sie sicher, dass die Bereitstellungsaktivität zur CodeCatalyst Konsole hinzugefügt wurde:

   1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Environments aus.**

   1. Wählen Sie Ihre Umgebung aus (z. B.`Production`).

   1. Wählen Sie die Registerkarte **Bereitstellungsaktivität** und vergewissern Sie sich, dass eine Bereitstellung den **Status SUCCEED** **hat**. Dies weist darauf hin, dass Ihre Anwendungsressourcen bei einer Workflow-Ausführung erfolgreich bereitgestellt wurden.

   1. Wählen Sie die Registerkarte **Bereitstellungsziele** und überprüfen Sie, ob Ihre Anwendungsressourcen angezeigt werden.

# Eine VPC mit einer Umgebung verknüpfen
<a name="deploy-environments-associate-vpc"></a>

Wenn eine Aktion mit einer Umgebung konfiguriert ist, die über eine VPC-Verbindung verfügt, wird die Aktion in Verbindung mit der VPC ausgeführt, wobei die von der zugehörigen VPC angegebenen Netzwerkregeln und Zugriffsressourcen eingehalten werden. Dieselbe VPC-Verbindung kann von einer oder mehreren Umgebungen verwendet werden.

Verwenden Sie die folgenden Anweisungen, um eine VPC-Verbindung mit einer Umgebung zu verknüpfen.

**So verknüpfen Sie eine VPC-Verbindung mit einer Umgebung**

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 Environments aus.**

1. Wählen Sie Ihre Umgebung aus (z. B.`Production`).

1. Wählen Sie die Registerkarte **Umgebungseigenschaften**.

1. **Wählen Sie **VPC-Verbindung verwalten**, wählen Sie die gewünschte VPC-Verbindung aus und klicken Sie auf Bestätigen.** Dadurch wird Ihre ausgewählte VPC-Verbindung mit dieser Umgebung verknüpft.
**Anmerkung**  
Wenn die VPC-Verbindung, die Sie verwenden möchten, nicht aufgeführt ist, kann dies daran liegen, dass sie eine AWS-Konto Verbindung enthält, die in Ihrem Projekt nicht zulässig ist. Weitere Informationen finden Sie unter [Konfiguration von projektbeschränkten Kontoverbindungen](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) im * CodeCatalystAmazon-Administratorhandbuch*.

Weitere Informationen finden Sie unter [Managing Amazon Virtual Private Clouds](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html) im *CodeCatalyst Administratorhandbuch*.

# Einen AWS-Konto mit einer Umgebung verknüpfen
<a name="deploy-environments-associate-account"></a>

Verwenden Sie die folgenden Anweisungen, um einen AWS-Konto mit einer Umgebung zu verknüpfen. Wenn Sie einer Umgebung eine AWS-Konto zuordnen, können Workflow-Aktionen, denen die Umgebung zugewiesen ist, eine Verbindung zu der herstellen AWS-Konto.

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md).

**Bevor Sie beginnen**

Sie benötigen Folgendes:
+ Eine AWS Kontoverbindung, die die IAM-Rollen enthält, auf die Ihre Workflow-Aktion zugreifen AWS muss. Informationen zum Erstellen einer Kontoverbindung finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Sie können maximal eine Kontoverbindung pro Umgebung verwenden.
+ Eine der folgenden CodeCatalyst Rollen: **Bereichsadministrator** oder **Projektadministrator**. Weitere Informationen finden Sie unter [Benutzern Projektberechtigungen gewähren](projects-members.md).

**Um einer Umgebung eine AWS-Konto Person zuzuordnen**

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 Environments aus.**

1. Wählen Sie Ihre Umgebung aus (z. B.`Production`).

1. Wählen Sie **Umgebung bearbeiten**.

1. Wählen Sie unter **Umgebungseigenschaften** in der Dropdownliste **AWS-Konto Verbindung — optional** die gewünschte Option aus AWS-Konto.

   Wenn die AWS-Konto Verbindung, die Sie verwenden möchten, nicht aufgeführt ist, liegt das möglicherweise daran, dass sie in Ihrem Projekt nicht zulässig ist. Weitere Informationen finden Sie unter [Konfiguration von projektbeschränkten Kontoverbindungen](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) im * CodeCatalyst Amazon-Administratorhandbuch*.

1. Wählen Sie unter **Standard-IAM-Rolle** die IAM-Rolle aus, die Sie dieser Umgebung zuordnen möchten. Workflow-Aktionen, denen diese Umgebung zugewiesen ist, erben diese IAM-Rolle und können sie verwenden, um eine Verbindung zu Diensten und Ressourcen in Ihrer Umgebung herzustellen. AWS-Konto

   Wenn die IAM-Rolle, die Sie als Standard verwenden möchten, nicht aufgeführt ist, liegt das möglicherweise daran, dass Sie sie Ihrer AWS-Konto Verbindung noch nicht hinzugefügt haben. Informationen zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter. [Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md)

# Die IAM-Rolle einer Aktion ändern
<a name="deploy-environments-switch-role"></a>

Wenn Sie einer [Workflow-Aktion eine [Umgebung](deploy-environments.md) zuordnen, erbt die Aktion](workflows-actions.md) standardmäßig die in der Umgebung angegebene IAM-Standardrolle. Sie können dieses Verhalten ändern, sodass die Aktion eine andere Rolle verwendet. Möglicherweise möchten Sie, dass eine Aktion eine andere Rolle verwendet, wenn der Standard-IAM-Rolle die Berechtigungen fehlen, die die Aktion für den Betrieb in der AWS Cloud benötigt.

Um einer Aktion eine andere IAM-Rolle zuzuweisen, können Sie die Option **Rolle wechseln** im visuellen Editor oder die `Connections:` Eigenschaft im YAML-Editor verwenden. Die neue Rolle überschreibt die in der Umgebung angegebene Standard-IAM-Rolle, sodass Sie die Standard-IAM-Rolle unverändert beibehalten können. Möglicherweise möchten Sie die Standard-IAM-Rolle unverändert lassen, falls es andere Aktionen gibt, die sie verwenden.

Verwenden Sie die folgenden Anweisungen, um eine Aktion so zu konfigurieren, dass sie eine andere als die in der Umgebung angegebene IAM-Rolle verwendet.

------
#### [ Visual ]

**So weisen Sie einer Aktion eine andere IAM-Rolle zu (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 das Feld für die Aktion aus, deren IAM-Rolle Sie aktualisieren möchten.

1. Wählen Sie die Registerkarte **Konfiguration** aus.

1. Im Bereich **Was ist drin*my-environment*?** Wählen Sie das vertikale Ellipsensymbol (![\[Ellipsis.\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/elipsis.png)) aus.

1. Wählen Sie **Rolle wechseln** aus.

1. Wählen **Sie im Dialogfeld „Rolle wechseln**“ in der Dropdownliste „**IAM-Rolle**“ die IAM-Rolle aus, die die Aktion verwenden soll. Diese Rolle überschreibt die Standard-IAM-Rolle in der Umgebung. Wenn die Rolle, die Sie verwenden möchten, nicht in der Liste enthalten ist, stellen Sie sicher, dass Sie sie Ihrem Bereich hinzugefügt haben. Weitere Informationen finden Sie unter [Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).

   Die gewählte Rolle erscheint jetzt in der Liste **Was ist drin*my-environment*?** Feld zusammen mit dem Badge **Definiert im Workflow**. Die Rolle wird auch in der Workflow-Definitionsdatei im `Connections:` Abschnitt angezeigt.

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 einer Aktion eine andere IAM-Rolle zuzuweisen (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 der Workflow-Aktion, für die Sie eine andere IAM-Rolle verwenden möchten, einen `Connections:` Abschnitt hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     Environment:
       Name: environment-name
       Connections: 
         - Name: account-connection-name
           Role: iam-role-name
   ```

   Ersetzen Sie im vorherigen Code *account-connection-name* durch den Namen der [Kontoverbindung](ipa-connect-account.md), die die IAM-Rolle enthält, und *iam-role-name* durch den Namen der IAM-Rolle, die die Aktion verwenden soll. Diese Rolle überschreibt die Standard-IAM-Rolle in der Umgebung. Stellen Sie sicher, dass Sie die Rolle zu Ihrem Bereich hinzugefügt haben. Weitere Informationen finden Sie unter [Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).

   Weitere Informationen finden Sie im [Aktionstypen](workflows-actions.md#workflows-actions-types) Thema. Dieses Thema enthält Links zur Dokumentation für jede Aktion, einschließlich der zugehörigen YAML-Referenz.

------

# Anzeige der App-URL im Workflow-Diagramm
<a name="deploy-app-url"></a>

Wenn Ihr Workflow eine Anwendung bereitstellt, können Sie Amazon so konfigurieren, CodeCatalyst dass die URL der Anwendung als anklickbarer Link angezeigt wird. Dieser Link wird in der CodeCatalyst Konsole in der Aktion angezeigt, mit der er bereitgestellt wurde. Das folgende Workflow-Diagramm zeigt die **View-App-URL**, die am Ende einer Aktion angezeigt wird.

![\[App-URL anzeigen\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/deploy/view-app-url.png)


Indem Sie diese URL in der CodeCatalyst Konsole anklickbar machen, können Sie Ihre Anwendungsbereitstellung schnell überprüfen.

**Anmerkung**  
Die App-URL wird mit der Aktion **Deploy to Amazon ECS** nicht unterstützt.

Um diese Funktion zu aktivieren, fügen Sie Ihrer Aktion eine Ausgabevariable mit einem Namen hinzu`appurl`, der oder enthält`endpointurl`. Sie können einen Namen mit oder ohne verbindenden Bindestrich (`-`), Unterstrich (`_`) oder Leerzeichen (` `) verwenden. Bei der Zeichenfolge wird nicht zwischen Groß- und Kleinschreibung unterschieden. Setzen Sie den Wert der Variablen auf die `https` URL `http` oder die URL Ihrer bereitgestellten Anwendung.

**Anmerkung**  
Wenn Sie eine bestehende Ausgabevariable so aktualisieren`app url`, dass sie die `endpoint url` Zeichenfolge oder die Zeichenfolge enthält, aktualisieren Sie alle Verweise auf diese Variable, sodass sie den neuen Variablennamen verwenden.

Ausführliche Schritte finden Sie in einem der folgenden Verfahren:
+ [Um die App-URL in der Aktion „AWS CDK Bereitstellen“ anzuzeigen](#deploy-app-url-cdk)
+ [Um die App-URL in der Aktion „ CloudFormation Stack bereitstellen“ anzuzeigen](#deploy-app-url-cfn)
+ [Um die App-URL in allen anderen Aktionen anzuzeigen](#deploy-app-url-other)

Wenn Sie mit der Konfiguration der URL fertig sind, stellen Sie sicher, dass sie wie erwartet aussieht, indem Sie die folgenden Anweisungen befolgen:
+ [Um zu überprüfen, ob die Anwendungs-URL hinzugefügt wurde](#deploy-app-url-verify)<a name="deploy-app-url-cdk"></a>

**Um die App-URL in der Aktion „AWS CDK Bereitstellen“ anzuzeigen**

1. Wenn Sie die Aktion „**AWS CDK Bereitstellen**“ verwenden, fügen Sie Ihrem AWS CDK Anwendungscode ein `CfnOutput` Konstrukt (bei dem es sich um ein Schlüssel-Wert-Paar handelt) hinzu:
   + Der Schlüsselname muss oder mit oder `endpointurl` ohne einen verbindenden Bindestrich (`-`), Unterstrich () oder Leerzeichen (`_`) enthalten`appurl`. ` ` Bei der Zeichenfolge wird nicht zwischen Groß- und Kleinschreibung unterschieden.
   + Der Wert muss die `https` URL `http` oder der URL Ihrer bereitgestellten Anwendung sein.

   Ihr AWS CDK Code könnte beispielsweise so aussehen:

   ```
   import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
   import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
   import * as s3 from 'aws-cdk-lib/aws-s3';
   import { Construct } from 'constructs';
   import * as cdk from 'aws-cdk-lib';
   export class HelloCdkStack extends Stack {
     constructor(scope: Construct, id: string, props?: StackProps) {
       super(scope, id, props);
       const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
         removalPolicy: RemovalPolicy.DESTROY,
       });
       new CfnOutput(this, 'APP-URL', {
         value: https://mycompany.myapp.com,
         description: 'The URL of the deployed application',
         exportName: 'myApp',
       });
       ...
     }
   }
   ```

   Weitere Informationen zu dem `CfnOutput` Konstrukt finden Sie unter [Interface CfnOutputProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutputProps.html) in der *AWS Cloud Development Kit (AWS CDK) API-Referenz*.

1. Speichern Sie Ihren Code und geben Sie ihn ein.

1. Fahren Sie mit [Um zu überprüfen, ob die Anwendungs-URL hinzugefügt wurde](#deploy-app-url-verify) fort.<a name="deploy-app-url-cfn"></a>

**Um die App-URL in der Aktion „ CloudFormation Stack bereitstellen“ anzuzeigen**

1. Wenn Sie die Aktion ** CloudFormation Stack bereitstellen** verwenden, fügen Sie dem `Outputs` Abschnitt in Ihrer CloudFormation Vorlage oder AWS SAM Vorlage eine Ausgabe mit den folgenden Eigenschaften hinzu:
   + Der Schlüssel (auch logische ID genannt) muss oder mit oder `endpointurl` ohne einen verbindenden Bindestrich (`-`), Unterstrich (`_`) oder Leerzeichen (` `) enthalten`appurl`. Bei der Zeichenfolge wird nicht zwischen Groß- und Kleinschreibung unterschieden.
   + Der Wert muss die `https` URL `http` oder der URL Ihrer bereitgestellten Anwendung sein.

   Ihre CloudFormation Vorlage könnte beispielsweise so aussehen:

   ```
   "Outputs" : {
     "APP-URL" : {
       "Description" : "The URL of the deployed app",
       "Value" : "https://mycompany.myapp.com",
       "Export" : {
         "Name" : "My App"
       }
     }
   }
   ```

   Weitere Informationen zu CloudFormation [Ausgaben](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html) finden Sie im *AWS CloudFormation Benutzerhandbuch* unter Ausgaben.

1. Speichern Sie Ihren Code und geben Sie ihn ein.

1. Fahren Sie mit [Um zu überprüfen, ob die Anwendungs-URL hinzugefügt wurde](#deploy-app-url-verify) fort.<a name="deploy-app-url-other"></a>

**Um die App-URL in allen anderen Aktionen anzuzeigen**

Wenn Sie eine andere Aktion verwenden, um Ihre Anwendung bereitzustellen, z. B. die Build-Aktion oder **GitHub Aktionen**, gehen Sie wie folgt vor, damit die App-URL angezeigt wird.

1. Definieren Sie eine Umgebungsvariable im `Steps` Abschnitt `Inputs` oder der Aktion in der Workflow-Definitionsdatei. Die Variable muss die folgenden Eigenschaften haben:
   + Die `name` muss oder `appurl``endpointurl`, mit oder ohne einen verbindenden Bindestrich (`-`), Unterstrich (`_`) oder Leerzeichen (` `) enthalten. Bei der Zeichenfolge wird nicht zwischen Groß- und Kleinschreibung unterschieden.
   + Der Wert muss die `https` URL `http` oder der URL Ihrer bereitgestellten Anwendung sein.

   Eine Build-Aktion könnte beispielsweise so aussehen:

   ```
   Build-action:
     Identifier: aws/build@v1
     Inputs:
       Variables:
         - Name: APP-URL
           Value: https://mycompany.myapp.com
   ```

   ... oder das:

   ```
   Actions:
     Build:
       Identifier: aws/build@v1
       Configuration:    
         Steps:
           - Run: APP-URL=https://mycompany.myapp.com
   ```

   Weitere Hinweise zur Definition von Umgebungsvariablen finden Sie unter[Definition einer Variablen](workflows-working-with-variables-define-input.md).

1. Exportieren Sie die Variable.

   Ihre Build-Aktion könnte beispielsweise so aussehen:

   ```
   Build-action:
     ...
     Outputs:
       Variables:
         - APP-URL
   ```

   Hinweise zum Exportieren von Variablen finden Sie unter[Eine Variable exportieren, damit sie von anderen Aktionen verwendet werden kann](workflows-working-with-variables-export-input.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.

1. Fahren Sie mit [Um zu überprüfen, ob die Anwendungs-URL hinzugefügt wurde](#deploy-app-url-verify) fort.<a name="deploy-app-url-verify"></a>

**Um zu überprüfen, ob die Anwendungs-URL hinzugefügt wurde**
+ Starten Sie eine Workflow-Ausführung, falls diese nicht automatisch gestartet wurde. Bei der neuen Ausführung sollte die App-URL als anklickbarer Link im Workflow-Diagramm angezeigt werden. Weitere Informationen zum Starten von Läufen finden Sie unter[Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md). 

# Ein Bereitstellungsziel entfernen
<a name="deploy-remove-target"></a>

Sie können ein Bereitstellungsziel wie einen Amazon ECS-Cluster oder CloudFormation -Stack von der Seite „**Bereitstellungsziele**“ in der CodeCatalyst Konsole entfernen.

**Wichtig**  
Wenn Sie ein Bereitstellungsziel entfernen, wird es aus der CodeCatalyst Konsole entfernt, bleibt aber in dem AWS Service verfügbar, der es hostet (sofern es noch existiert).

Erwägen Sie, ein Bereitstellungsziel zu entfernen, wenn das Ziel veraltet ist. CodeCatalyst Ziele könnten in den folgenden Fällen veraltet sein:
+ Sie haben den Workflow gelöscht, der für das Ziel bereitgestellt wurde.
+ Sie haben den Stack oder Cluster geändert, auf dem Sie die Bereitstellung durchführen. 
+ Sie haben den Stack oder Cluster aus dem CloudFormation oder dem Amazon ECS-Service in der AWS Konsole gelöscht.

**Um ein Bereitstellungsziel zu entfernen**

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 Environments aus.**

1. Wählen Sie den Namen der Umgebung aus, die das Bereitstellungsziel enthält, das Sie entfernen möchten. Informationen zu Umgebungen finden Sie unter[Einsatz in AWS-Konten und VPCs](deploy-environments.md).

1. Wählen Sie die Registerkarte **Bereitstellungsziele**.

1. Wählen Sie das Optionsfeld neben dem Bereitstellungsziel, das Sie entfernen möchten.

1. Wählen Sie **Remove (Entfernen)** aus.

   Das Ziel wird von der Seite entfernt.

# Verfolgen des Bereitstellungsstatus nach Commit
<a name="track-changes"></a>

Zu jedem Zeitpunkt im Entwicklungszyklus ist es wichtig, den Bereitstellungsstatus bestimmter Commits zu kennen, z. B. Bugfixes, neue Funktionen oder andere wichtige Änderungen. Stellen Sie sich die folgenden Szenarien vor, in denen die Fähigkeit zur Nachverfolgung des Bereitstellungsstatus für Entwicklungsteams hilfreich ist:
+ Als Entwickler haben Sie einen Fehler behoben und möchten den Status der Implementierung in den Bereitstellungsumgebungen Ihres Teams melden.
+ Als Release-Manager möchten Sie eine Liste der bereitgestellten Commits einsehen, um deren Bereitstellungsstatus nachzuverfolgen und zu melden.

CodeCatalyst bietet eine Ansicht, anhand derer Sie auf einen Blick feststellen können, wo und in welcher Umgebung einzelne Commits oder Änderungen implementiert wurden. Diese Ansicht beinhaltet: 
+ Eine Liste von Commits.
+ Der Status der Bereitstellungen, die die Commits enthalten.
+ Die Umgebungen, in denen die Commits erfolgreich bereitgestellt wurden.
+ Der Status aller Tests, die anhand der Commits in Ihrem CI/CD Workflow ausgeführt wurden.

Das folgende Verfahren beschreibt, wie Sie zu dieser Ansicht navigieren und sie verwenden, um Änderungen in Ihrem Projekt nachzuverfolgen.

**Anmerkung**  
Das Verfolgen des Bereitstellungsstatus per Commit wird nur mit [CodeCatalyst Repositorys](source.md) unterstützt. Du kannst diese Funktion nicht mit einem [GitHub Repository, Bitbucket-Repository oder GitLab Projekt-Repository](extensions.md) verwenden.

**Um den Bereitstellungsstatus per Commit zu verfolgen**

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 **Change** Tracking aus.

1. Wählen Sie in den beiden Dropdownlisten oben im Hauptfenster das Quell-Repository und den Branch aus, die die Commits enthalten, deren Release-Status Sie anzeigen möchten.

1. Wähle „Änderungen **anzeigen**“.

   Eine Liste mit Commits wird angezeigt.

   Für jeden Commit können Sie Folgendes einsehen:
   + Commit-Informationen wie ID, Autor, Nachricht und Datum der Übertragung. Weitere Informationen finden Sie unter [Speichern Sie Code mit Quell-Repositorys in und arbeiten Sie gemeinsam daran CodeCatalystSpeichern Sie Code mit Quell-Repositorys und arbeiten Sie gemeinsam daran](source.md).
   + Der Status der Bereitstellungen in jeder Umgebung. Weitere Informationen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md).
   + Ergebnisse der Tests und der Codeabdeckung. Weitere Informationen finden Sie unter [Testen mit WorkflowsTesten mit Workflows](test-workflow-actions.md).
**Anmerkung**  
Die Ergebnisse der Software Composition Analysis (SCA) werden nicht angezeigt.

1. (Optional) Um weitere Informationen zu den Änderungen im Zusammenhang mit einem bestimmten Commit anzuzeigen, einschließlich der neuesten Bereitstellung und detaillierter Informationen zur Codeabdeckung und zum Komponententest, wählen Sie **Details für diesen Commit anzeigen**.

# Bereitstellungsprotokolle anzeigen
<a name="deploy-deployment-logs"></a>

Sie können Protokolle zu bestimmten Bereitstellungsaktionen einsehen, um Probleme in Amazon zu beheben CodeCatalyst.

Sie können Protokolle ausgehend von einem [Workflow](workflow.md) oder einer [Umgebung](deploy-environments.md) anzeigen.

**Um die Protokolle einer Bereitstellungsaktion ausgehend von einem Workflow 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 **Läufe** aus.

1. Wählen Sie die Workflow-Ausführung aus, mit der Ihre Anwendung bereitgestellt wurde.

1. Wählen Sie im Workflow-Diagramm die Aktion aus, deren Protokolle Sie anzeigen möchten.

1. Wählen Sie die Registerkarte **Protokolle** und erweitern Sie die Abschnitte, um die Protokollmeldungen anzuzeigen.

1. Um weitere Protokolle anzuzeigen, wählen Sie die Registerkarte **Zusammenfassung** und dann **Ansicht in CloudFormation** (falls verfügbar), um dort weitere Protokolle anzuzeigen. Möglicherweise müssen Sie sich anmelden bei AWS.

**Um die Protokolle einer Bereitstellungsaktion ausgehend von einer Umgebung 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 Environments aus.**

1. Wählen Sie die Umgebung aus, in der Ihre Anwendung bereitgestellt wurde.

1. Suchen Sie unter **Bereitstellungsaktivität** nach der Spalte **Workflow-Ausführungs-ID** und wählen Sie den Workflow-Lauf aus, der Ihren Stack bereitgestellt hat.

1. Wählen Sie im Workflow-Diagramm die Aktion aus, deren Protokolle Sie anzeigen möchten.

1. Wählen Sie die Registerkarte **Protokolle** und erweitern Sie die Abschnitte, um die Protokollmeldungen anzuzeigen.

1. Um weitere Protokolle anzuzeigen, wählen Sie die Registerkarte **Zusammenfassung** und dann **Ansicht in CloudFormation** (falls verfügbar), um dort weitere Protokolle anzuzeigen. Möglicherweise müssen Sie sich anmelden bei AWS.

# Bereitstellungsinformationen anzeigen
<a name="deploy-view-deployment-info"></a>

Sie können die folgenden Informationen zu einer Bereitstellung in Amazon einsehen CodeCatalyst:
+ Bereitstellungsaktivität, einschließlich Bereitstellungsstatus, Startzeit, Endzeit, Verlauf und Dauer der Ereignisse.
+ Stack-Name AWS-Region, Uhrzeit der letzten Aktualisierung und zugehörige Workflows.
+ Commits und Pull-Requests.
+ Aktionsspezifische Informationen, z. B. CloudFormation Ereignisse und Ausgaben.

[Sie können Bereitstellungsinformationen ausgehend von einem [Workflow](workflow.md), einer [Umgebung](deploy-environments.md) oder einer Workflow-Aktion anzeigen.](workflows-concepts.md#workflows-concepts-actions)

**So zeigen Sie Bereitstellungsinformationen ab einem Workflow an**
+ Gehen Sie zu der Workflow-Ausführung, mit der Ihre Anwendung bereitgestellt wurde. Detaillierte Anweisungen finden Sie unter [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md). 

**Um Bereitstellungsinformationen ausgehend von einer Umgebung 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 Environments aus.**

1. Wählen Sie die Umgebung aus, in der Ihr Stack bereitgestellt wurde, z. B. `Production`

1. Wählen Sie **Deployment Activity** aus, um den Bereitstellungsverlauf Ihrer Stacks, den Status der Bereitstellungen (z. B. **ERFOLGREICH** ODER **FEHLGESCHLAGEN**) und andere bereitstellungsbezogene Informationen einzusehen.

1. Wählen Sie **Bereitstellungsziel** aus, um Informationen zu den Stacks, Clustern oder anderen Zielen anzuzeigen, die in der Umgebung bereitgestellt wurden. Sie können Informationen wie den Stacknamen, die Region, den Anbieter und die Kennung anzeigen.

**Um Bereitstellungsinformationen ab einer Aktion 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 im Workflow-Diagramm die Workflow-Aktion aus, mit der Ihre Anwendung bereitgestellt wurde. Sie könnten beispielsweise wählen **DeployCloudFormationStack**.

1. Im Inhalt des rechten Fensterbereichs finden Sie aktionsspezifische Informationen zur Bereitstellung. 

# Einen Workflow erstellen
<a name="workflows-create-workflow"></a>

Ein *Workflow* ist ein automatisiertes Verfahren, das beschreibt, wie Sie Ihren Code als Teil eines CI/CD-Systems (Continuous Integration and Continuous Delivery) erstellen, testen und bereitstellen. Ein Workflow definiert eine Reihe von Schritten oder *Aktionen*, die während einer Workflow-Ausführung ausgeführt werden sollen. Ein Workflow definiert auch die Ereignisse oder *Auslöser*, die den Start des Workflows auslösen. Um einen Workflow einzurichten, erstellen Sie mit dem [visuellen Editor oder dem YAML-Editor](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) der CodeCatalyst Konsole eine *Workflow-Definitionsdatei*.

**Tipp**  
Um einen kurzen Überblick darüber zu erhalten, wie Sie Workflows in einem Projekt verwenden könnten, [erstellen Sie ein Projekt mit einem Blueprint](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Jeder Blueprint stellt einen funktionierenden Workflow bereit, den Sie überprüfen, ausführen und mit dem Sie experimentieren können.

Verwenden Sie das folgende Verfahren, um einen Workflow in zu erstellen. CodeCatalyst Der Workflow wird als YAML-Datei in einem `~/.codecatalyst/workflows/` Ordner im ausgewählten Quell-Repository gespeichert. Optional können Sie den Workflow in einem Unterordner von speichern, `~/.codecatalyst/workflows/` indem Sie dem Workflow-Dateinamen beim Commit einen Ordnernamen voranstellen. Weitere Informationen finden Sie in den folgenden Anweisungen.

Weitere Informationen zu Workflows finden Sie unter [Erstellen, Testen und Bereitstellen mit WorkflowsMit Workflows erstellen, testen und bereitstellen](workflow.md).

------
#### [ Visual ]<a name="workflows-create"></a>

**Um einen Workflow mit dem Visual Editor zu erstellen**

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 Workflow **erstellen** aus.

   Das Dialogfeld „**Workflow erstellen**“ wird angezeigt.

1. Wählen Sie im Feld **Quell-Repository** ein Quell-Repository aus, in dem sich die Workflow-Definitionsdatei befinden soll. Wenn kein Quell-Repository vorhanden ist, [erstellen Sie eines](source-repositories-create.md).

1. Wählen Sie im Feld **Zweig** einen Zweig aus, in dem sich die Workflow-Definitionsdatei befinden soll.

1. Wählen Sie **Erstellen** aus.

   Amazon CodeCatalyst speichert das Repository und die Branch-Informationen im Speicher, aber der Workflow ist noch nicht festgeschrieben.

1. Wählen Sie **Visual**.

1. Erstellen Sie den Workflow:

   1. (Optional) Wählen Sie im Workflow-Diagramm das Feld **Quelle** und **Auslöser aus**. Ein Bereich mit **Auslösern** wird angezeigt. Wählen Sie **Trigger hinzufügen**, um einen Trigger hinzuzufügen. Weitere Informationen finden Sie unter [Hinzufügen von Triggern zu Workflows](workflows-add-trigger-add.md).

   1. Wählen Sie **\$1 Aktionen** (oben links). Der **Aktionenkatalog** wird angezeigt.

   1. Wählen Sie das Pluszeichen (**\$1**) innerhalb einer Aktion, um sie dem Workflow hinzuzufügen. Verwenden Sie den Bereich auf der rechten Seite, um die Aktion zu konfigurieren. Weitere Informationen finden Sie unter [Aktion zu einem Workflow hinzufügen](workflows-add-action.md).

   1. (Optional) Wählen Sie **Workflow-Eigenschaften** (oben rechts). Ein Bereich mit **den Workflow-Eigenschaften** wird angezeigt. Konfigurieren Sie den Workflow-Namen, den Ausführungsmodus und die Berechnung. Weitere Informationen erhalten Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md) und [Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).

1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.

1. **Wählen Sie „Bestätigen“ und **gehen Sie im Dialogfeld „Workflow bestätigen**“ wie folgt vor:**

   1. Behalten Sie für **Workflow-Dateiname** den Standardnamen bei oder geben Sie einen eigenen ein. Die Datei wird in einem `~/.codecatalyst/workflows/` Ordner im ausgewählten Quell-Repository und Branch gespeichert. Sie können dem Dateinamen einen Ordner oder Unterordner voranstellen. Beispiele:
      + Wenn Sie `my-workflow` (kein Ordner) angeben, wird die Datei als gespeichert `~/.codecatalyst/workflows/my-workflow.yaml`
      + Wenn Sie angeben, wird die Datei `folder/subfolder/my-workflow` gespeichert als `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml`

   1. Behalten Sie für **Commit-Nachricht** die Standardnachricht bei oder geben Sie eine eigene ein.

   1. Wählen Sie für **Repository** und **Branch** das Quell-Repository und den Branch für die Workflow-Definitionsdatei aus. Diese Felder sollten auf das Repository und den Branch gesetzt werden, die Sie zuvor im Dialogfeld **Workflow erstellen** angegeben haben. Sie können das Repository und den Branch jetzt ändern, wenn Sie möchten.
**Anmerkung**  
Nachdem Sie Ihre Workflow-Definitionsdatei übernommen haben, kann sie keinem anderen Repository oder Branch zugeordnet werden. Wählen Sie sie daher sorgfältig aus.

   1. Wählen Sie **Commit**, um die Workflow-Definitionsdatei zu übernehmen.

------
#### [ YAML ]

**Um einen Workflow mit dem YAML-Editor zu erstellen**

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 Workflow **erstellen** aus.

   Das Dialogfeld „**Workflow erstellen**“ wird angezeigt.

1. Wählen Sie im Feld **Quell-Repository** ein Quell-Repository aus, in dem sich die Workflow-Definitionsdatei befinden soll. Wenn kein Quell-Repository vorhanden ist, [erstellen Sie eines](source-repositories-create.md).

1. Wählen Sie im Feld **Zweig** einen Zweig aus, in dem sich die Workflow-Definitionsdatei befinden soll.

1. Wählen Sie **Erstellen** aus.

   Amazon CodeCatalyst speichert das Repository und die Branch-Informationen im Speicher, aber der Workflow ist noch nicht festgeschrieben.

1. Wählen Sie **YAML.**

1. Erstellen Sie den Workflow:

   1. (Optional) Fügen Sie dem YAML-Code einen Trigger hinzu. Weitere Informationen finden Sie unter [Hinzufügen von Triggern zu Workflows](workflows-add-trigger-add.md).

   1. Wählen Sie **\$1 Aktionen** (oben links). Der **Aktionenkatalog** wird angezeigt.

   1. Wählen Sie das Pluszeichen (**\$1**) innerhalb einer Aktion, um sie dem Workflow hinzuzufügen. Verwenden Sie den Bereich auf der rechten Seite, um die Aktion zu konfigurieren. Weitere Informationen finden Sie unter [Aktion zu einem Workflow hinzufügen](workflows-add-action.md).

   1. (Optional) Wählen Sie **Workflow-Eigenschaften** (oben rechts). Ein Bereich mit **den Workflow-Eigenschaften** wird angezeigt. Konfigurieren Sie den Workflow-Namen, den Ausführungsmodus und die Berechnung. Weitere Informationen erhalten Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md) und [Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).

1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.

1. **Wählen Sie „Bestätigen“ und **gehen Sie im Dialogfeld „Workflow bestätigen**“ wie folgt vor:**

   1. Behalten Sie für **Workflow-Dateiname** den Standardnamen bei oder geben Sie einen eigenen ein. Die Datei wird in einem `~/.codecatalyst/workflows/` Ordner im ausgewählten Quell-Repository und Branch gespeichert. Sie können dem Dateinamen einen Ordner oder Unterordner voranstellen. Beispiele:
      + Wenn Sie `my-workflow` (kein Ordner) angeben, wird die Datei als gespeichert `~/.codecatalyst/workflows/my-workflow.yaml`
      + Wenn Sie angeben, wird die Datei `folder/subfolder/my-workflow` gespeichert als `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml`

   1. Behalten Sie für **Commit-Nachricht** die Standardnachricht bei oder geben Sie eine eigene ein.

   1. Wählen Sie für **Repository** und **Branch** das Quell-Repository und den Branch für die Workflow-Definitionsdatei aus. Diese Felder sollten auf das Repository und den Branch gesetzt werden, die Sie zuvor im Dialogfeld **Workflow erstellen** angegeben haben. Sie können das Repository und den Branch jetzt ändern, wenn Sie möchten.
**Anmerkung**  
Nachdem Sie Ihre Workflow-Definitionsdatei übernommen haben, kann sie keinem anderen Repository oder Branch zugeordnet werden. Wählen Sie sie daher sorgfältig aus.

   1. Wählen Sie **Commit**, um die Workflow-Definitionsdatei zu übernehmen.

------

# Einen Workflow ausführen
<a name="workflows-working-runs"></a>

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
<a name="workflows-manually-start"></a>

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
<a name="workflows-add-trigger"></a>

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
<a name="workflows-add-trigger-examples"></a>

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
<a name="workflows-add-trigger-examples-push-simple"></a>

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
<a name="workflows-add-trigger-examples-push-main"></a>

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
<a name="workflows-add-trigger-examples-pull-simple"></a>

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
<a name="workflows-add-trigger-examples-schedule-simple"></a>

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
<a name="workflows-add-trigger-examples-schedule-branches"></a>

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
<a name="workflows-add-trigger-examples-schedule-push-branches"></a>

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
<a name="workflows-add-trigger-examples-pull-branches"></a>

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
<a name="workflows-add-trigger-examples-push-pull-close"></a>

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
<a name="workflows-add-trigger-examples-push-multi"></a>

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
<a name="workflows-add-trigger-examples-manual"></a>

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
<a name="workflows-add-trigger-usecases"></a>

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
<a name="workflows-add-trigger-considerations"></a>

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
<a name="workflows-add-trigger-add"></a>

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 ]<a name="workflows-add-trigger-add-console"></a>

**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
<a name="workflows-manual-only"></a>

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
<a name="workflows-stop"></a>

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
<a name="workflows-gates"></a>

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
<a name="workflows-gates-types"></a>

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?
<a name="workflows-approval-parallel"></a>

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?
<a name="workflows-gates-prevent"></a>

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
<a name="workflows-gate-limitations"></a>

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
<a name="workflows-gates-add"></a>

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
<a name="workflows-gates-depends-on"></a>

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
<a name="workflows-gates-version"></a>

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
<a name="workflows-approval"></a>

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?
<a name="workflows-approval-conditions"></a>

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
<a name="workflows-approval-when"></a>

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?
<a name="workflows-approval-who"></a>

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?
<a name="workflows-approval-notify-methods"></a>

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?
<a name="workflows-approval-prevent"></a>

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“?
<a name="workflows-approval-run-mode"></a>

[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
<a name="workflows-approval-example"></a>

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
<a name="workflows-approval-add"></a>

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 ]<a name="workflows-add-trigger-add-console"></a>

**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
<a name="workflows-approval-notify"></a>

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
<a name="workflows-approval-approve"></a>

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
<a name="approval-ref"></a>

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
<a name="approval.name"></a>

(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
<a name="approval.identifier"></a>

(*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
<a name="approval.dependson"></a>

(*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
<a name="approval.configuration"></a>

(*Approval*/**Configuration**)

(Optional)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften des Gates definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## ApprovalsRequired
<a name="approval.approvals.required"></a>

(*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
<a name="workflows-configure-runs"></a>

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
<a name="workflows-configure-runs-queued"></a>

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
<a name="workflows-configure-runs-superseded"></a>

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
<a name="workflows-configure-runs-parallel"></a>

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
<a name="workflows-configure-runs-configure"></a>

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
<a name="workflows-caching"></a>

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
<a name="workflows-caching.files"></a>

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
<a name="workflows-caching.fallback"></a>

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
<a name="workflows-caching.constraints"></a>

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
<a name="workflows-view-run"></a>

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
<a name="workflows-view-run-single"></a>

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
<a name="workflows-view-run-all"></a>

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
<a name="workflows-view-run-wf"></a>

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
<a name="workflows-view-run-wf-diagram"></a>

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).

# Workflow-Aktionen konfigurieren
<a name="workflows-actions"></a>

Eine *Aktion* ist der Hauptbaustein eines Workflows und definiert eine logische Arbeitseinheit oder Aufgabe, die während einer Workflow-Ausführung ausgeführt werden soll. In der Regel umfasst ein Workflow mehrere Aktionen, die nacheinander oder parallel ausgeführt werden, je nachdem, wie Sie sie konfiguriert haben.

**Topics**
+ [

## Aktionstypen
](#workflows-actions-types)
+ [

# Aktion zu einem Workflow hinzufügen
](workflows-add-action.md)
+ [

# Eine Aktion aus einem Workflow entfernen
](workflows-delete-action.md)
+ [

# Entwicklung einer benutzerdefinierten Aktion
](workflows-custom-action.md)
+ [

# Gruppierung von Aktionen in Aktionsgruppen
](workflows-group-actions.md)
+ [

# Aktionen sequenzieren
](workflows-depends-on.md)
+ [

# Artefakte und Dateien zwischen Aktionen teilen
](workflows-working-artifacts.md)
+ [

# Angabe der zu verwendenden Aktionsversion
](workflows-action-versions.md)
+ [

# Liste der verfügbaren Aktionsversionen
](workflows-action-versions-determine.md)
+ [

# Den Quellcode einer Aktion anzeigen
](workflows-view-source.md)
+ [

# Integration mit GitHub Aktionen
](integrations-github-actions.md)

## Aktionstypen
<a name="workflows-actions-types"></a>

Innerhalb eines CodeCatalyst Amazon-Workflows können Sie die folgenden Aktionstypen verwenden.

**Topics**
+ [

### CodeCatalyst Aktionen
](#workflows-actions-types-cc)
+ [

### CodeCatalyst Aktionen in Labs
](#workflows-actions-types-cc-labs)
+ [

### GitHub Aktionen
](#workflows-actions-types-github)
+ [

### Drittanbieteraktionen
](#workflows-actions-types-3p)

### CodeCatalyst Aktionen
<a name="workflows-actions-types-cc"></a>

Eine *CodeCatalyst Aktion* ist eine Aktion, die vom CodeCatalyst Entwicklungsteam erstellt, verwaltet und umfassend unterstützt wird.

Es gibt CodeCatalyst Aktionen zum Erstellen, Testen und Bereitstellen von Anwendungen sowie zum Ausführen verschiedener Aufgaben, z. B. zum Aufrufen einer Funktion. AWS Lambda 

Die folgenden CodeCatalyst Aktionen sind verfügbar:
+ **Entwicklung**

  Diese Aktion erstellt Ihre Artefakte und führt Ihre Komponententests in einem Docker-Container aus. Weitere Informationen finden Sie unter [Hinzufügen der Build-Aktion](build-add-action.md).
+ **Test**

  Diese Aktion führt Integrations- und Systemtests für Ihre Anwendung oder Artefakte durch. Weitere Informationen finden Sie unter [Testaktion hinzufügen](test-add-action.md).
+ **Amazon S3 veröffentlichen**

  Diese Aktion kopiert Ihre Anwendungsartefakte in einen Amazon S3 S3-Bucket. Weitere Informationen finden Sie unter [Veröffentlichen von Dateien in Amazon S3 mit einem Workflow](s3-pub-action.md).
+ **AWS CDK bootstrap**

  Diese Aktion stellt die Ressourcen bereit, die für die Bereitstellung Ihrer CDK-App AWS CDK benötigt werden. Weitere Informationen finden Sie unter [Bootstrapping einer AWS CDK App mit einem Workflow](cdk-boot-action.md).
+ **AWS CDK bereitstellen**

  Diese Aktion synthetisiert und stellt eine AWS Cloud Development Kit (AWS CDK) App bereit. Weitere Informationen finden Sie unter [Eine AWS CDK App mit einem Workflow bereitstellen](cdk-dep-action.md).
+ **AWS Lambda aufrufen**

  Diese Aktion ruft eine AWS Lambda Funktion auf. Weitere Informationen finden Sie unter [Aufrufen einer Lambda-Funktion mithilfe eines Workflows](lam-invoke-action.md).
+ **GitHub Aktionen**

  Diese Aktion ist eine *CodeCatalyst*Aktion, mit der Sie GitHub Aktionen innerhalb eines CodeCatalyst Workflows ausführen können. Weitere Informationen finden Sie unter [Aufrufen einer Lambda-Funktion mithilfe eines Workflows](lam-invoke-action.md).
+ ** CloudFormation Stapel bereitstellen**

  Diese Aktion stellt CloudFormation Stapel bereit. Weitere Informationen finden Sie unter [Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md).
+ **Auf Amazon ECS bereitstellen**

  Diese Aktion registriert eine Amazon ECS-Aufgabendefinition und stellt sie für einen Amazon ECS-Service bereit. Weitere Informationen finden Sie unter [Bereitstellung auf Amazon ECS mit einem Workflow](deploy-action-ecs.md).
+ **Auf einem Kubernetes-Cluster bereitstellen**

  Diese Aktion stellt eine Anwendung in einem Kubernetes-Cluster bereit. Weitere Informationen finden Sie unter [Bereitstellung auf Amazon EKS mit einem Workflow](deploy-action-eks.md).
+ **Amazon ECS-Aufgabendefinition rendern**

  Diese Aktion fügt einen Container-Image-URI in eine JSON-Datei mit einer Amazon ECS-Aufgabendefinition ein und erstellt so eine neue Aufgabendefinitionsdatei. Weitere Informationen finden Sie unter [Ändern einer Amazon ECS-Aufgabendefinition](render-ecs-action.md).

Die Dokumentation zu CodeCatalyst Aktionen ist in diesem Handbuch und in der Readme-Datei der einzelnen Aktionen verfügbar.

Informationen zu den verfügbaren CodeCatalyst Aktionen und zum Hinzufügen einer Aktion zu einem Workflow finden Sie unter[Aktion zu einem Workflow hinzufügen](workflows-add-action.md).

### CodeCatalyst Aktionen in Labs
<a name="workflows-actions-types-cc-labs"></a>

Eine *CodeCatalyst Labs-Aktion* ist eine Aktion, die Teil von Amazon CodeCatalyst Labs ist, einem Testgelände für experimentelle Anwendungen. CodeCatalyst Labs-Aktionen wurden entwickelt, um Integrationen mit AWS Diensten zu demonstrieren.

Die folgenden CodeCatalyst Labs-Aktionen sind verfügbar:
+ **Auf AWS Amplify Hosting bereitstellen**

  Diese Aktion stellt eine Anwendung für Amplify Hosting bereit.
+ **Bereitstellen auf AWS App Runner**

  Diese Aktion stellt das neueste Image in einem Quell-Image-Repository für App Runner bereit.
+ **Auf Amazon CloudFront und Amazon S3 bereitstellen**

  Diese Aktion stellt eine Anwendung auf CloudFront Amazon S3 bereit.
+ **Bereitstellen mit AWS SAM**

  Diese Aktion stellt Ihre serverlose Anwendung mit AWS Serverless Application Model ()AWS SAM bereit.
+ ** CloudFront Amazon-Cache ungültig machen**

  Diese Aktion macht einen CloudFront Cache für einen bestimmten Satz von Pfaden ungültig.
+ **Ausgehender Webhook**

  Diese Aktion ermöglicht es Benutzern, Nachrichten innerhalb eines Workflows mithilfe einer HTTPS-Anfrage an einen beliebigen Webserver zu senden.
+ **Veröffentlichen auf AWS CodeArtifact**

  Diese Aktion veröffentlicht Pakete in einem CodeArtifact Repository.
+ **Auf Amazon SNS veröffentlichen**

  Diese Aktion ermöglicht es Benutzern, Amazon SNS zu integrieren, indem sie ein Thema erstellen, zu einem Thema veröffentlichen oder ein Thema abonnieren.
+ **Zu Amazon ECR weiterleiten**

  Diese Aktion erstellt und veröffentlicht ein Docker-Image in einem Amazon Elastic Container Registry (Amazon ECR) -Repository.
+ **Mit Amazon CodeGuru Security scannen**

  Diese Aktion erstellt ein ZIP-Archiv mit einem konfigurierten Codepfad und verwendet CodeGuru Security, um einen Codescan durchzuführen.
+ **Terraform Community Edition**

  Diese Aktion führt die Terraform Community Edition und den Betrieb aus. `plan` `apply`

Die Dokumentation für CodeCatalyst Labs-Aktionen ist in der Readme-Datei jeder Aktion verfügbar.

Informationen zum Hinzufügen einer CodeCatalyst Labs-Aktion zu einem Workflow und zum Anzeigen der zugehörigen Readme-Datei finden Sie unter. [Aktion zu einem Workflow hinzufügen](workflows-add-action.md)

### GitHub Aktionen
<a name="workflows-actions-types-github"></a>

Eine *GitHub Aktion* ist einer [CodeCatalyst Aktion](#workflows-actions-types-cc) sehr ähnlich, außer dass sie für die Verwendung mit GitHub Workflows entwickelt wurde. Einzelheiten zu GitHub Aktionen finden Sie in der Dokumentation zu [GitHub Aktionen](https://docs.github.com/en/actions).

Sie können GitHub Aktionen zusammen mit systemeigenen CodeCatalyst Aktionen in einem CodeCatalyst Workflow verwenden.

Der Einfachheit halber bietet die CodeCatalyst Konsole Zugriff auf mehrere beliebte GitHub Aktionen. Sie können auch jede GitHub Aktion verwenden, die im [GitHub Marketplace](https://github.com/marketplace/actions) aufgeführt ist (mit einigen Einschränkungen).

Die Dokumentation zu GitHub Aktionen ist in der Readme-Datei jeder Aktion verfügbar.

Weitere Informationen finden Sie unter [Integration mit GitHub Aktionen](integrations-github-actions.md).

### Drittanbieteraktionen
<a name="workflows-actions-types-3p"></a>

Eine *Drittanbieter-Aktion* ist eine Aktion, die von einem Drittanbieter erstellt und in der CodeCatalyst Konsole verfügbar gemacht wurde. Zu den Aktionen von Drittanbietern gehören beispielsweise die Aktionen **Mend SCA** und **SonarCloud Scan**, die jeweils von Mend bzw. Sonar erstellt wurden.

Die Dokumentation für Aktionen von Drittanbietern ist in der Readme-Datei jeder Aktion verfügbar. Zusätzliche Dokumentation kann auch vom Drittanbieter bereitgestellt werden.

Informationen zum Hinzufügen einer Drittanbieter-Aktion zu einem Workflow und zum Anzeigen der zugehörigen Readme-Datei finden Sie unter[Aktion zu einem Workflow hinzufügen](workflows-add-action.md).

# Aktion zu einem Workflow hinzufügen
<a name="workflows-add-action"></a>

Verwenden Sie die folgenden Anweisungen, um einem Workflow eine Aktion hinzuzufügen und ihn dann zu konfigurieren.

**Um eine Aktion hinzuzufügen und zu konfigurieren**

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 **\$1 Aktionen** aus. Der Aktionenkatalog wird angezeigt.**

1. Führen Sie in der Dropdownliste einen der folgenden Schritte aus:
   + Wählen Sie **Amazon CodeCatalyst** zum Ansehen [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) oder Aktionen [von Drittanbietern](workflows-actions.md#workflows-actions-types-3p).
     + CodeCatalyst Aktionen sind mit der AWS Bezeichnung „**Nach**“ gekennzeichnet.
     + CodeCatalyst Labs-Aktionen haben die Bezeichnung „**Von CodeCatalyst Labs**“.
     + Aktionen von Drittanbietern sind **mit der *vendor* Bezeichnung nach** gekennzeichnet, wobei der Name des Drittanbieters angegeben *vendor* ist.
   + Wählen Sie **GitHub**diese Option, um eine [kuratierte Liste von GitHub Aktionen](integrations-github-action-add-curated.md) anzuzeigen.

1. Suchen Sie im Aktionskatalog nach einer Aktion und führen Sie dann einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zu Ihrem Workflow hinzuzufügen.
   + Wählen Sie den Namen der Aktion, um die zugehörige Readme-Datei aufzurufen.

1. Konfigurieren Sie die Aktion. 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 den folgenden Links.

   Anweisungen zum Hinzufügen von [CodeCatalystAktionen](workflows-actions.md#workflows-actions-types-cc) finden Sie unter:
   + [Hinzufügen der Build-Aktion](build-add-action.md)
   + [Testaktion hinzufügen](test-add-action.md)
   + [Aktion „In Amazon ECS bereitstellen“ hinzufügen](deploy-action-ecs-adding.md)
   + [Aktion „Im Kubernetes-Cluster bereitstellen“ hinzufügen](deploy-action-eks-adding.md)
   + [Aktion „ CloudFormation Stapel bereitstellen“ hinzufügen](deploy-action-cfn-adding.md)
   + [Aktion „AWS CDK Deploy“ hinzufügen](cdk-dep-action-add.md)
   + [Die Aktion „AWS CDK Bootstrap“ hinzufügen](cdk-boot-action-add.md)
   + [Die Aktion „Amazon S3 Publish“ hinzufügen](s3-pub-action-add.md)
   + [Aktion „AWS Lambda Aufrufen“ hinzufügen](lam-invoke-action-add.md)
   + [Aktion „Amazon ECS-Aufgabendefinition rendern“ hinzufügen](render-ecs-action-add.md)

   Anweisungen zum Hinzufügen von [CodeCatalyst Labs-Aktionen](workflows-actions.md#workflows-actions-types-cc-labs) finden Sie unter:
   + Die Readme-Datei der Aktion ist verfügbar. Sie finden die Readme-Datei, indem Sie den Namen der Aktion im Aktionskatalog auswählen.

   Anweisungen zum Hinzufügen von [GitHub Aktionen](workflows-actions.md#workflows-actions-types-github) finden Sie unter:
   + [Integration mit GitHub Aktionen](integrations-github-actions.md)

   Anweisungen zum Hinzufügen [von Aktionen von Drittanbietern](workflows-actions.md#workflows-actions-types-3p) finden Sie unter:
   + Die Readme-Datei der Aktion ist verfügbar. Sie finden die Readme-Datei, indem Sie den Namen der Aktion im Aktionskatalog auswählen.

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.

# Eine Aktion aus einem Workflow entfernen
<a name="workflows-delete-action"></a>

Verwenden Sie die folgenden Anweisungen, um eine Aktion aus einem Workflow zu entfernen.

------
#### [ Visual ]

**Um eine Aktion mit dem Visual Editor zu entfernen**

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 in der Aktion, die Sie entfernen möchten, das vertikale Ellipsensymbol (![\[Ellipsis.\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/images/flows/elipsis.png)) und dann Entfernen aus.**

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 eine Aktion mit dem YAML-Editor zu entfernen**

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 Abschnitt der YAML, der die Aktion enthält, die Sie entfernen möchten.

   Wählen Sie den Abschnitt aus und drücken Sie die Löschtaste auf Ihrer Tastatur.

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

------

# Entwicklung einer benutzerdefinierten Aktion
<a name="workflows-custom-action"></a>

Mit dem Action Development Kit (ADK) können Sie eine benutzerdefinierte CodeCatalyst Aktion entwickeln, die Sie in Ihren Workflows verwenden können. Anschließend können Sie die Aktion im CodeCatalyst Aktionskatalog veröffentlichen, sodass andere CodeCatalyst Benutzer sie anzeigen und in ihren Workflows verwenden können.

**Um eine Aktion zu entwickeln, zu testen und zu veröffentlichen (Aufgaben auf hoher Ebene)**

1. Installieren Sie die erforderlichen Tools und Pakete, die für die Entwicklung einer Aktion erforderlich sind.

1. Erstellen Sie ein CodeCatalyst Repository zum Speichern Ihres Aktionscodes.

1. Initialisieren Sie die Aktion. Dadurch werden die für die Aktion erforderlichen Quelldateien festgelegt, einschließlich einer Aktionsdefinitionsdatei (`action.yml`), die Sie mit Ihrem eigenen Code aktualisieren können.

1. Führen Sie ein Bootstrapping für den Aktionscode durch, um die Tools und Bibliotheken zu erhalten, die zum Erstellen, Testen und Veröffentlichen des Aktionsprojekts erforderlich sind.

1. Erstellen Sie die Aktion auf Ihrem lokalen Computer und übertragen Sie die Änderungen in Ihr CodeCatalyst Repository.

1. Testen Sie die Aktion lokal mit Komponententests und führen Sie den vom ADK generierten Workflow in aus. CodeCatalyst

1. Veröffentlichen Sie die Aktion im CodeCatalyst Aktionskatalog, indem Sie in der Konsole auf die Schaltfläche **Veröffentlichen** klicken. CodeCatalyst 

Eine ausführliche Anleitung finden Sie im [Amazon CodeCatalyst Action Development Kit Developer Guide](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html).

# Gruppierung von Aktionen in Aktionsgruppen
<a name="workflows-group-actions"></a>

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.

**Anmerkung**  
Aktionsgruppen können nicht innerhalb anderer Aktionsgruppen oder Aktionen verschachtelt werden.

**Topics**
+ [

## Definition einer Aktionsgruppe
](#workflows-define-action-group)
+ [

# Beispiel: Definition von zwei Aktionsgruppen
](workflows-group-actions-example.md)

## Definition einer Aktionsgruppe
<a name="workflows-define-action-group"></a>

Verwenden Sie die folgenden Anweisungen, um eine CodeCatalyst Aktionsgruppe zu definieren.

------
#### [ Visual ]

*Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.*

------
#### [ YAML ]

**So definieren Sie eine Gruppe**

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 Code hinzu`Actions`, der dem folgenden ähnelt:

   ```
   Actions:
     action-group-name: 
       Actions:
         action-1:
           Identifier: aws/build@v1
           Configuration:
             ...
         action-2:
           Identifier: aws/build@v1
           Configuration:
             ...
   ```

   Ein weiteres Beispiel finden Sie unter [Beispiel: Definition von zwei Aktionsgruppen](workflows-group-actions-example.md). Weitere Informationen finden Sie in der Beschreibung der `action-group-name` Immobilie in [Aktionen](workflow-reference.md#actions-reference) 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.

------

# Beispiel: Definition von zwei Aktionsgruppen
<a name="workflows-group-actions-example"></a>

Das folgende Beispiel zeigt, wie zwei CodeCatalyst Amazon-Aktionsgruppen definiert werden: `BuildAndTest` und`Deploy`. Die `BuildAndTest` Gruppe umfasst zwei Aktionen (`Build`und`Test`), und die `Deploy` Gruppe umfasst auch zwei Aktionen (`DeployCloudFormationStack`und`DeployToECS`).

```
Actions:
  BuildAndTest: # Action group 1
    Actions:
      Build:
        Identifier: aws/build@v1
        Configuration:
          ...
      Test:
        Identifier: aws/managed-test@v1
        Configuration:
  Deploy: #Action group 2
    Actions:
      DeployCloudFormationStack:
        Identifier: aws/cfn-deploy@v1
        Configuration:
          ...
      DeployToECS:
        Identifier: aws/ecs-deploy@v1
        Configuration:
          ...
```

# Aktionen sequenzieren
<a name="workflows-depends-on"></a>

Wenn Sie einem Workflow Aktionen hinzufügen, werden sie standardmäßig im [Visual Editor](workflow.md#workflow.editors) nebeneinander hinzugefügt. Das bedeutet, dass die Aktionen parallel ausgeführt werden, wenn Sie einen Workflow-Lauf starten. Wenn Sie möchten, dass Aktionen in sequentieller Reihenfolge ausgeführt werden (und vertikal im Visual Editor angezeigt werden), müssen Sie Abhängigkeiten zwischen ihnen einrichten. Sie können beispielsweise eine `Test` Aktion so einrichten, dass sie von der `Build` Aktion abhängt, sodass die Testaktion nach der Build-Aktion ausgeführt wird.

Sie können Abhängigkeiten zwischen Aktionen und Aktionsgruppen einrichten. Sie können one-to-many Abhängigkeiten auch so konfigurieren, dass eine Aktion von mehreren anderen abhängt, bevor sie gestartet wird. Lesen Sie die Richtlinien unter[Abhängigkeiten zwischen Aktionen einrichten](workflows-depends-on-set-up.md), um sicherzustellen, dass Ihr Abhängigkeits-Setup der YAML-Syntax des Workflows entspricht.

**Topics**
+ [

# Beispiele für die Konfiguration von Abhängigkeiten zwischen Aktionen
](workflows-depends-on-examples.md)
+ [

# Abhängigkeiten zwischen Aktionen einrichten
](workflows-depends-on-set-up.md)

# Beispiele für die Konfiguration von Abhängigkeiten zwischen Aktionen
<a name="workflows-depends-on-examples"></a>

Die folgenden Beispiele zeigen, wie Abhängigkeiten zwischen Aktionen und Gruppen in der Workflow-Definitionsdatei konfiguriert werden.

**Topics**
+ [

## Beispiel: Konfiguration einer einfachen Abhängigkeit
](#workflows-depends-on-example-simple)
+ [

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von einer Aktion abhängt
](#workflows-depends-on-example-action-groups-actions)
+ [

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von einer anderen Aktionsgruppe abhängt
](#workflows-depends-on-example-two-action-groups)
+ [

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von mehreren Aktionen abhängt
](#workflows-depends-on-example-advanced)

## Beispiel: Konfiguration einer einfachen Abhängigkeit
<a name="workflows-depends-on-example-simple"></a>

Das folgende Beispiel zeigt, wie eine `Test` Aktion so konfiguriert wird, dass sie von der `Build` Aktion abhängt, die die `DependsOn` Eigenschaft verwendet.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Configuration:
      ...
  Test:
    DependsOn:
      - Build
    Identifier: aws/managed-test@v1
     Configuration:
       ...
```

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von einer Aktion abhängt
<a name="workflows-depends-on-example-action-groups-actions"></a>

Das folgende Beispiel zeigt, wie eine `DeployGroup` Aktionsgruppe so konfiguriert wird, dass sie von der `FirstAction` Aktion abhängt. Beachten Sie, dass sich Aktion und Aktionsgruppe auf derselben Ebene befinden.

```
Actions:
  FirstAction: #An action outside an action group
    Identifier: aws/github-actions-runner@v1
    Configuration:
      ...
  DeployGroup: #An action group containing two actions
    DependsOn: 
      - FirstAction
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von einer anderen Aktionsgruppe abhängt
<a name="workflows-depends-on-example-two-action-groups"></a>

Das folgende Beispiel zeigt, wie eine `DeployGroup` Aktionsgruppe so konfiguriert wird, dass sie von der `BuildAndTestGroup` Aktionsgruppe abhängt. Beachten Sie, dass sich die Aktionsgruppen auf derselben Ebene befinden.

```
Actions:
  BuildAndTestGroup: # Action group 1
    Actions:
      BuildAction:
      ...
      TestAction:
      ...
  DeployGroup: #Action group 2
    DependsOn: 
      - BuildAndTestGroup
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

## Beispiel: Konfiguration einer Aktionsgruppe so, dass sie von mehreren Aktionen abhängt
<a name="workflows-depends-on-example-advanced"></a>

Das folgende Beispiel zeigt, wie eine `DeployGroup` Aktionsgruppe so konfiguriert wird, dass sie von der `SecondAction` Aktion, der Aktion und der `BuildAndTestGroup` Aktionsgruppe abhängt. `FirstAction` Beachten Sie, dass `DeployGroup` sich das auf derselben Ebene wie `FirstAction``SecondAction`, und befindet`BuildAndTestGroup`.

```
Actions:
  FirstAction: #An action outside an action group
    ...
  SecondAction: #Another action 
    ...
  BuildAndTestGroup: #Action group 1
    Actions:
      Build:
      ...
      Test:
      ...
  DeployGroup: #Action group 2
    DependsOn: 
      - FirstAction
      - SecondAction
      - BuildAndTestGroup
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

# Abhängigkeiten zwischen Aktionen einrichten
<a name="workflows-depends-on-set-up"></a>

Verwenden Sie die folgenden Anweisungen, um Abhängigkeiten zwischen Aktionen in einem Workflow einzurichten.

Beachten Sie bei der Konfiguration von Abhängigkeiten die folgenden Richtlinien:
+ Wenn sich eine Aktion innerhalb einer Gruppe befindet, kann diese Aktion nur von anderen Aktionen innerhalb derselben Gruppe abhängen.
+ Aktionen und Aktionsgruppen können von anderen Aktionen und Aktionsgruppen auf *derselben Ebene in der* YAML-Hierarchie abhängen, jedoch *nicht* auf einer anderen Ebene.

------
#### [ Visual ]

**Um Abhängigkeiten mit dem Visual Editor einzurichten**

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, die von einer anderen Aktion abhängt.

1. Wählen Sie die Registerkarte **Eingaben**.

1. Gehen Sie **unter Abhängig von — optional** wie folgt vor:

   Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

   Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.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 Abhängigkeiten mit dem YAML-Editor einzurichten**

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 Aktion, die von einer anderen Aktion abhängt, Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     DependsOn:
       - action-1
   ```

   Weitere Beispiele finden Sie unter [Beispiele für die Konfiguration von Abhängigkeiten zwischen Aktionen](workflows-depends-on-examples.md). Allgemeine Richtlinien finden Sie unter[Abhängigkeiten zwischen Aktionen einrichten](#workflows-depends-on-set-up). Weitere Informationen finden Sie in der Beschreibung der `DependsOn` Immobilie im Abschnitt [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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

------

# Artefakte und Dateien zwischen Aktionen teilen
<a name="workflows-working-artifacts"></a>

Ein *Artefakt* ist die Ausgabe einer Workflow-Aktion und besteht in der Regel aus einem Ordner oder Archiv mit Dateien. Artefakte sind wichtig, weil sie es Ihnen ermöglichen, Dateien und Informationen zwischen Aktionen gemeinsam zu nutzen.

Möglicherweise haben Sie eine Build-Aktion, die eine `sam-template.yml` Datei *generiert*, Sie möchten jedoch, dass eine Bereitstellungsaktion *diese verwendet*. In diesem Szenario würden Sie ein Artefakt verwenden, um es der Build-Aktion zu ermöglichen, die `sam-template.yml` Datei mit der Bereitstellungsaktion gemeinsam zu nutzen. Der Code könnte etwa so aussehen:

```
Actions:
  BuildAction:
    Identifier: aws/build@v1
    Steps:
      - Run: sam package --output-template-file sam-template.yml
    Outputs:
      Artifacts:
        - Name: MYARTIFACT
          Files:
            - sam-template.yml
  DeployAction:
    Identifier: aws/cfn-deploy@v1  
    Inputs:
      Artifacts:
        - MYARTIFACT
    Configuration:
      template: sam-template.yml
```

Im vorherigen Code generiert die Build-Aktion (`BuildAction`) eine `sam-template.yml` Datei und fügt sie dann einem Ausgabeartefakt namens `MYARTIFACT` hinzu. Eine nachfolgende Bereitstellungsaktion (`DeployAction`) wird `MYARTIFACT` als Eingabe angegeben, sodass sie auf die `sam-template.yml` Datei zugreifen kann.

**Topics**
+ [

## Kann ich Artefakte teilen, ohne sie als Ausgaben und Eingaben anzugeben?
](#workflows-working-artifacts-share)
+ [

## Kann ich Artefakte zwischen Workflows teilen?
](#workflows-working-artifacts-share-wf)
+ [

# Beispiele für Artefakte
](workflows-working-artifacts-ex.md)
+ [

# Definition eines Ausgabeartefakts
](workflows-working-artifacts-output.md)
+ [

# Definition eines Eingabeartefakts
](workflows-working-artifacts-refer.md)
+ [

# Referenzieren von Dateien in einem Artefakt
](workflows-working-artifacts-refer-files.md)
+ [

# Artefakte herunterladen
](workflows-download-workflow-outputs.md)

## Kann ich Artefakte teilen, ohne sie als Ausgaben und Eingaben anzugeben?
<a name="workflows-working-artifacts-share"></a>

Ja, Sie können Artefakte zwischen Aktionen gemeinsam nutzen, ohne sie in den `Inputs` Abschnitten `Outputs` und im YAML-Code Ihrer Aktionen anzugeben. Dazu müssen Sie Compute Sharing aktivieren. Weitere Informationen zu Compute Sharing und zur Angabe von Artefakten, wenn es aktiviert ist, finden Sie unter[Rechenleistung für mehrere Aktionen gemeinsam nutzen](compute-sharing.md). 

**Anmerkung**  
Mit der Compute Sharing-Funktion können Sie zwar den YAML-Code Ihres Workflows vereinfachen, indem Sie die `Inputs` Abschnitte `Outputs` und und überflüssig machen, es gibt jedoch Einschränkungen, die Sie beachten sollten, bevor Sie sie aktivieren. Informationen zu diesen Einschränkungen finden Sie unter[Überlegungen zur gemeinsamen Nutzung von Rechenleistung](compute-sharing.md#compare-compute-sharing).

## Kann ich Artefakte zwischen Workflows teilen?
<a name="workflows-working-artifacts-share-wf"></a>

Nein, Sie können Artefakte nicht zwischen verschiedenen Workflows gemeinsam nutzen. Sie können Artefakte jedoch zwischen Aktionen innerhalb desselben Workflows gemeinsam nutzen.

# Beispiele für Artefakte
<a name="workflows-working-artifacts-ex"></a>

Die folgenden Beispiele zeigen, wie Artefakte in der CodeCatalyst Amazon-Workflow-Definitionsdatei ausgegeben, eingegeben und referenziert werden.

**Topics**
+ [

## Beispiel: Ausgabe eines Artefakts
](#workflows-working-artifacts-ex-basic)
+ [

## Beispiel: Eingabe eines Artefakts, das durch eine andere Aktion generiert wurde
](#workflows-working-artifacts-ex-ref)
+ [

## Beispiel: Referenzieren von Dateien in mehreren Artefakten
](#workflows-working-artifacts-ex-ref-file)
+ [

## Beispiel: Referenzieren einer Datei in einem einzigen Artefakt
](#workflows-working-artifacts-ex-ref-file-one)
+ [

## Beispiel: Verweisen auf eine Datei in einem Artefakt, wenn a vorhanden ist WorkflowSource
](#workflows-working-artifacts-ex-ref-file-wf-source)
+ [

## Beispiel: Referenzieren einer Datei in einem Artefakt, wenn eine Aktionsgruppe vorhanden ist
](#workflows-working-artifacts-ex-groups)

## Beispiel: Ausgabe eines Artefakts
<a name="workflows-working-artifacts-ex-basic"></a>

Das folgende Beispiel zeigt, wie ein Artefakt ausgegeben wird, das zwei .jar-Dateien enthält.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Outputs:
      Artifacts:
        - Name: ARTIFACT1
          Files:
            - build-output/file1.jar
            - build-output/file2.jar
```

## Beispiel: Eingabe eines Artefakts, das durch eine andere Aktion generiert wurde
<a name="workflows-working-artifacts-ex-ref"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie ein aufgerufenes Artefakt ausgeben und `ARTIFACT4` in `BuildActionA` dieses eingeben. `BuildActionB`

```
Actions:
  BuildActionA:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ARTIFACT4
          Files:
            - build-output/file1.jar
            - build-output/file2.jar
  BuildActionB:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ARTIFACT4
    Configuration:
```

## Beispiel: Referenzieren von Dateien in mehreren Artefakten
<a name="workflows-working-artifacts-ex-ref-file"></a>

Das folgende Beispiel zeigt`BuildActionC`, wie Sie zwei Artefakte mit dem Namen `ART5` und `ART6` in ausgeben und dann auf zwei Dateien mit den Namen `file5.txt` (in Artifact`ART5`) und `file6.txt` (in Artifact`ART6`) in `BuildActionD` (unter`Steps`) verweisen.

**Anmerkung**  
Weitere Informationen zum Referenzieren von Dateien finden Sie unter. [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md)

**Anmerkung**  
Das Beispiel zeigt zwar, dass das `$CATALYST_SOURCE_DIR_ART5` Präfix verwendet wird, Sie könnten es aber weglassen. Das liegt daran, dass `ART5` es die *primäre Eingabe* ist. Weitere Informationen zur primären Eingabe finden Sie unter[Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md). 

```
Actions:
  BuildActionC:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART5
          Files:
            - build-output/file5.txt
        - Name: ART6
          Files:
            - build-output/file6.txt
  BuildActionD:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ART5
        - ART6
    Configuration:
      Steps:
        - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt
        - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt
```

## Beispiel: Referenzieren einer Datei in einem einzigen Artefakt
<a name="workflows-working-artifacts-ex-ref-file-one"></a>

Das folgende Beispiel zeigt, wie Sie ein Artefakt mit dem Namen `ART7` in `BuildActionE` ausgeben und dann auf `file7.txt` (im Artefakt`ART7`) in `BuildActionF` (unter) verweisen. `Steps`

Beachten Sie, dass für die Referenz kein `$CATALYST_SOURCE_DIR_` *artifact-name* Präfix vor dem `build-output` Verzeichnis erforderlich ist, wie dies in der Fall war. [Beispiel: Referenzieren von Dateien in mehreren Artefakten](#workflows-working-artifacts-ex-ref-file) Dies liegt daran, dass unter nur ein Element angegeben ist`Inputs`.

**Anmerkung**  
Weitere Informationen zum Verweisen auf Dateien finden Sie unter[Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

```
Actions:
  BuildActionE:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART7
          Files:
            - build-output/file7.txt
  BuildActionF:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ART7
    Configuration:
      Steps:
        - run: cd build-output && cat file7.txt
```

## Beispiel: Verweisen auf eine Datei in einem Artefakt, wenn a vorhanden ist WorkflowSource
<a name="workflows-working-artifacts-ex-ref-file-wf-source"></a>

Das folgende Beispiel zeigt, wie Sie ein Artefakt mit dem Namen `ART8` in `BuildActionG` ausgeben und dann auf `file8.txt` (in Artefakt`ART8`) in `BuildActionH` (unter) verweisen. `Steps`

Beachten Sie, dass für die Referenz das `$CATALYST_SOURCE_DIR_` *artifact-name* Präfix erforderlich ist, wie in. [Beispiel: Referenzieren von Dateien in mehreren Artefakten](#workflows-working-artifacts-ex-ref-file) Das liegt daran, dass unter `Inputs` (eine Quelle und ein Artefakt) mehrere Elemente angegeben sind. Sie benötigen also das Präfix, um anzugeben, wo nach der Datei gesucht werden soll.

**Anmerkung**  
Weitere Informationen zum Verweisen auf Dateien finden Sie unter. [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md)

```
Actions:
  BuildActionG:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART8
          Files:
            - build-output/file8.txt
  BuildActionH:
    Identifier: aws/build@v1  
    Inputs:
      Sources:
        - WorkflowSource
      Artifacts:
        - ART8
    Configuration:
      Steps:
        - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt
```

## Beispiel: Referenzieren einer Datei in einem Artefakt, wenn eine Aktionsgruppe vorhanden ist
<a name="workflows-working-artifacts-ex-groups"></a>

Das folgende Beispiel zeigt, wie Sie ein Artefakt mit dem Namen `ART9` in `ActionGroup1` ausgeben und dann `file9.txt` (im Artefakt`ART9`) in referenzieren. `ActionI` `ActionJ`

Weitere Informationen zum Verweisen auf Dateien finden Sie unter. [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md)

```
Actions:
  ActionGroup1:
    Actions:
      ActionI:
        Identifier: aws/build@v1
        Outputs:
          Artifacts:
            - Name: ART9
              Files:
                - build-output/file9.yml
      ActionJ:
        Identifier: aws/cfn-deploy@v1 
        Inputs:
          Sources:
            - WorkflowSource
          Artifacts:
            - ART9
        Configuration:
          template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml
```

# Definition eines Ausgabeartefakts
<a name="workflows-working-artifacts-output"></a>

Verwenden Sie die folgenden Anweisungen, um ein Artefakt zu definieren, das eine CodeCatalyst Amazon-Aktion ausgeben soll. Dieses Artefakt steht dann für andere Aktionen zur Verfügung.

**Anmerkung**  
Nicht alle Aktionen unterstützen Ausgabeartefakte. Um festzustellen, ob Ihre Aktion sie unterstützt, führen Sie die folgenden Anweisungen für den visuellen Editor durch und prüfen Sie, ob die Aktion auf der Registerkarte **Ausgaben** die Schaltfläche **Ausgabeartefakte** enthält. Falls ja, werden Ausgabeartefakte unterstützt. 

------
#### [ Visual ]

**Um ein Ausgabeartefakt mit dem visuellen Editor zu definieren**

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, die das Artefakt erzeugen soll.

1. Wählen Sie die Registerkarte **Outputs**.

1. Wählen Sie unter **Artefakte** die Option **Artefakt hinzufügen** aus.

1. Wählen Sie „**Artefakt hinzufügen**“ und geben Sie wie folgt Informationen in die Felder ein.

    **Name des Build-Artefakts** 

   Geben Sie den Namen eines Artefakts an, das durch die Aktion generiert wurde. Artefaktnamen müssen innerhalb eines Workflows eindeutig sein und sind auf alphanumerische Zeichen (a-z, A-Z, 0-9) und Unterstriche (\$1) beschränkt. Leerzeichen, Bindestriche (-) und andere Sonderzeichen sind nicht zulässig. Sie können keine Anführungszeichen verwenden, um Leerzeichen, Bindestriche und andere Sonderzeichen in Namen von Ausgabeartefakten zuzulassen.

   Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

    **Dateien, die von Build erstellt wurden** 

   Geben Sie die Dateien an, die in dem Artefakt CodeCatalyst enthalten sind, das durch die Aktion ausgegeben wird. Diese Dateien werden durch die Workflow-Aktion generiert, wenn sie ausgeführt wird, und sind auch in Ihrem Quell-Repository verfügbar. Dateipfade können sich in einem Quell-Repository oder einem Artefakt aus einer früheren Aktion befinden und sind relativ zum Quell-Repository oder Artefakt-Stamm. Sie können Glob-Muster verwenden, um Pfade anzugeben. Beispiele:
   + Um eine einzelne Datei anzugeben, die sich im Stammverzeichnis Ihres Build-Speicherorts oder Quell-Repository-Speicherorts befindet, verwenden Sie`my-file.jar`.
   + Um eine einzelne Datei in einem Unterverzeichnis anzugeben, verwenden Sie `directory/my-file.jar` oder`directory/subdirectory/my-file.jar`.
   + Um alle Dateien anzugeben, verwenden Sie`"**/*"`. Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
   + Um alle Dateien und Verzeichnisse in einem Verzeichnis mit dem Namen anzugeben`directory`, verwenden Sie. `"directory/**/*"` Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
   + Um alle Dateien in einem Verzeichnis mit dem Namen`directory`, aber nicht in einem seiner Unterverzeichnisse anzugeben, verwenden Sie. `"directory/*"` 
**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder ein anderes Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

   Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).
**Anmerkung**  
Möglicherweise müssen Sie dem Dateipfad ein Präfix hinzufügen, um anzugeben, in welchem Artefakt oder in welcher Quelle das Objekt gefunden werden soll. Weitere Informationen erhalten Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.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 ein Ausgabeartefakt mit dem YAML-Editor zu definieren**

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:
     Outputs:
       Artifacts:
         - Name: artifact-name
           Files:
             - file-path-1
             - file-path-2
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Artefakte](workflows-working-artifacts-ex.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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

------

# Definition eines Eingabeartefakts
<a name="workflows-working-artifacts-refer"></a>

Wenn Sie ein Artefakt verwenden möchten, das durch eine andere CodeCatalyst Amazon-Aktion generiert wurde, müssen Sie es als Eingabe für die aktuelle Aktion angeben. Möglicherweise können Sie mehrere Artefakte als Eingabe angeben — das hängt von der Aktion ab. Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

**Anmerkung**  
Sie können nicht auf Artefakte aus anderen Workflows verweisen.

Verwenden Sie die folgenden Anweisungen, um ein Artefakt aus einer anderen Aktion als Eingabe für die aktuelle Aktion anzugeben.

**Voraussetzung**  
Bevor Sie beginnen, stellen Sie sicher, dass Sie das Artefakt aus der anderen Aktion ausgegeben haben. Weitere Informationen finden Sie unter [Definition eines Ausgabeartefakts](workflows-working-artifacts-output.md). Wenn Sie das Artefakt ausgeben, steht es anderen Aktionen zur Verfügung.

------
#### [ Visual ]

**Um ein Artefakt als Eingabe für eine Aktion anzugeben (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 die Aktion aus, für die Sie ein Artefakt als Eingabe angeben möchten.

1. Wählen Sie **Eingaben**.

1. Gehen Sie **unter Artefakte — optional** wie folgt vor:

   Geben Sie Artefakte aus früheren Aktionen an, die Sie als Eingabe für diese Aktion bereitstellen möchten. Diese Artefakte müssen bereits in früheren Aktionen als Ausgabeartefakte definiert sein.

   Wenn Sie keine Eingabeartefakte angeben, müssen Sie mindestens ein Quell-Repository unter angeben`action-name/Inputs/Sources`.

   Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).
**Anmerkung**  
Wenn die Dropdownliste **Artefakte — optional** nicht verfügbar ist (visueller Editor) oder wenn Sie bei der Validierung Ihres YAML (YAML-Editors) Fehler erhalten, kann das daran liegen, dass die Aktion nur eine Eingabe unterstützt. Versuchen Sie in diesem Fall, die Quelleingabe 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 ein Artefakt als Eingabe für eine Aktion anzugeben (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 in der Aktion, in der Sie das Artefakt als Eingabe angeben möchten, Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     Inputs:
       Artifacts:
         - artifact-name
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Artefakte](workflows-working-artifacts-ex.md).

1. (Optional) Wählen Sie **Validieren** aus, 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**.

------

# Referenzieren von Dateien in einem Artefakt
<a name="workflows-working-artifacts-refer-files"></a>

Wenn Sie eine Datei haben, die sich in einem Artefakt befindet, und Sie in einer Ihrer CodeCatalyst Amazon-Workflow-Aktionen auf diese Datei verweisen müssen, gehen Sie wie folgt vor.

**Anmerkung**  
Siehe auch [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md).

------
#### [ Visual ]

*Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.*

------
#### [ YAML ]

**Um Dateien in einem Artefakt zu referenzieren (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 in der Aktion, in der Sie auf eine Datei verweisen möchten, Code hinzu, der dem folgenden ähnelt:

   ```
   Actions:
     My-action:
       Inputs:
         Sources:
           - WorkflowSource
         Artifacts:
           - artifact-name  
       Configuration:
         template: artifact-path/path/to/file.yml
   ```

   Ersetzen Sie im vorherigen Code:
   + *artifact-name*mit dem Namen des Artefakts.
   + *artifact-path*mit einem Wert aus der folgenden Tabelle.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html)

   Beispiele finden Sie unter [Beispiele für Artefakte](workflows-working-artifacts-ex.md).
**Anmerkung**  
Sie können das weglassen *artifact-path* und einfach den Dateipfad relativ zum Artefakt-Stammverzeichnis angeben, wenn:  
Die Aktion, bei der Sie die Referenz angeben, umfasst nur ein Element unter `Inputs` (z. B. ein Eingabeartefakt und keine Quelle).
Die Datei, auf die Sie verweisen möchten, befindet sich in der primären Eingabe. Die *primäre Eingabe* ist entweder das `WorkflowSource` oder das erste aufgeführte Eingabeartefakt, falls keines vorhanden ist. `WorkflowSource`

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

------

# Artefakte herunterladen
<a name="workflows-download-workflow-outputs"></a>

Sie können Artefakte, die durch Ihre CodeCatalyst Amazon-Workflow-Aktionen generiert wurden, zur Fehlerbehebung herunterladen und überprüfen. Es gibt zwei Arten von Artefakten, die Sie herunterladen können:
+ **Quellartefakte** — Ein Artefakt, das einen Snapshot des Inhalts des Quell-Repositorys enthält, so wie er zu Beginn der Ausführung vorhanden war.
+ **Workflow-Artefakte** — Ein Artefakt, das in der `Outputs` Eigenschaft der Konfigurationsdatei Ihres Workflows definiert ist.

**Um die vom Workflow ausgegebenen Artefakte herunterzuladen**

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. Wählen Sie unter dem Namen des Laufs die Option **Artifacts** aus.

1. Wähle neben einem Artefakt die Option **Herunterladen** aus. Eine Archivdatei wird heruntergeladen. Ihr Dateiname besteht aus sieben zufälligen Zeichen.

1. Extrahieren Sie das Archiv mit einem Archivextraktionsprogramm Ihrer Wahl.

# Angabe der zu verwendenden Aktionsversion
<a name="workflows-action-versions"></a>

Wenn Sie einem Workflow eine Aktion hinzufügen, CodeCatalyst fügt Amazon der Workflow-Definitionsdatei standardmäßig die Vollversion im folgenden Format hinzu:

 `vmajor.minor.patch` 

Beispiel:

```
My-Build-Action:
  Identifier: aws/build@v1.0.0
```

Sie können die Vollversion in der `Identifier` Eigenschaft kürzen, sodass der Workflow immer die neueste Neben- oder Patch-Version der Aktion verwendet.

Wenn Sie beispielsweise Folgendes angeben:

```
My-CloudFormation-Action:
  Identifier: aws/cfn-deploy@v1.0
```

... und die neueste Patch-Version ist`1.0.4`, dann wird die Aktion verwendet`1.0.4`. Wenn beispielsweise eine neuere Version veröffentlicht wird`1.0.5`, dann wird die Aktion verwendet`1.0.5`. Wenn beispielsweise eine Nebenversion veröffentlicht wird`1.1.0`, wird die Aktion weiterhin verwendet`1.0.5`.

Ausführliche Anweisungen zur Angabe von Versionen finden Sie in einem der folgenden Themen.

Verwenden Sie die folgenden Anweisungen, um anzugeben, welche Version einer Aktion Ihr Workflow verwenden soll. Sie können die neueste Haupt- oder Nebenversion oder eine bestimmte Patch-Version angeben.

Wir empfehlen, die neueste Neben- oder Patch-Version einer Aktion zu verwenden.

------
#### [ Visual ]

 *Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.* 

------
#### [ YAML ]

**Um einen Workflow so zu konfigurieren, dass er die neueste Version einer Aktion oder eine bestimmte Patch-Version verwendet**

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 die Aktion, deren Version Sie bearbeiten möchten.

1. Suchen Sie die `Identifier` Eigenschaft der Aktion und legen Sie die Version auf eine der folgenden Optionen fest:
   + action-identifier @v *major* — Verwenden Sie diese Syntax, damit der Workflow eine bestimmte Hauptversion verwendet und die neuesten Neben- und Patch-Versionen automatisch ausgewählt werden können.
   + Aktionskennung @v. *major* *minor*— Verwenden Sie diese Syntax, damit der Workflow eine bestimmte Nebenversion verwendet und die neueste Patch-Version automatisch ausgewählt wird.
   + Aktionskennung @v. *major* *minor*. *patch* — Verwenden Sie diese Syntax, damit der Workflow eine bestimmte Patch-Version verwendet.
**Anmerkung**  
Wenn Sie nicht sicher sind, welche Versionen verfügbar sind, finden Sie weitere Informationen unter[Liste der verfügbaren Aktionsversionen](workflows-action-versions-determine.md).
**Anmerkung**  
Sie können die Hauptversion nicht weglassen.

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

------

# Liste der verfügbaren Aktionsversionen
<a name="workflows-action-versions-determine"></a>

Ermitteln Sie anhand der folgenden Anweisungen, welche Versionen einer Aktion für Sie in einem Workflow verfügbar sind.

------
#### [ Visual ]

**Um festzustellen, welche Aktionsversionen verfügbar sind**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Wählen Sie Ihr Projekt.

1. Suchen Sie die Aktion, deren Versionen Sie sich ansehen möchten:

   1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

   1. Wählen Sie den Namen eines beliebigen Workflows oder erstellen Sie einen. Informationen zum Erstellen eines Workflows finden Sie unter[Einen Workflow erstellen](workflows-create-workflow.md).

   1. Wählen Sie **Bearbeiten** aus.

   1. Wählen Sie links oben **\$1 Aktionen** aus, um den Aktionskatalog zu öffnen.

   1. Wählen Sie in der Drop-down-Liste **Amazon CodeCatalyst** zum Ansehen CodeCatalyst, CodeCatalyst Labs und Aktionen von Drittanbietern oder wählen Sie, ob Sie kuratierte GitHub Aktionen anzeigen **GitHub**möchten.

   1. Suchen Sie nach einer Aktion und wählen Sie ihren Namen. Wählen Sie nicht das Pluszeichen (**\$1**).

      Details zur Aktion werden angezeigt.

1. Wählen Sie im Dialogfeld mit den Aktionsdetails oben rechts die Dropdownliste **Versionen** aus, um eine Liste der verfügbaren Versionen der Aktion anzuzeigen.

------
#### [ YAML ]

 *Nicht verfügbar. Wählen Sie „visuell“, um die Anweisungen des visuellen Editors anzuzeigen.* 

------

# Den Quellcode einer Aktion anzeigen
<a name="workflows-view-source"></a>

Sie können den Quellcode einer Aktion einsehen, um sicherzustellen, dass er keinen riskanten Code, Sicherheitslücken oder andere Fehler enthält.

Folgen Sie den folgenden Anweisungen, um den Quellcode einer Aktion [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), einer Aktion von [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) oder eines [Drittanbieters einzusehen](workflows-actions.md#workflows-actions-types-3p).

**Anmerkung**  
Um den Quellcode einer [GitHubAktion](workflows-actions.md#workflows-actions-types-github) einzusehen, gehen Sie auf die Seite der Aktion im [GitHub Marketplace](https://github.com/marketplace/actions). Die Seite enthält einen Link zum Repository der Aktion, wo Sie den Quellcode der Aktion finden können.

**Anmerkung**  
Sie können den Quellcode der folgenden CodeCatalyst Aktionen nicht anzeigen: [Build](build-workflow-actions.md), [Test](test-workflow-actions.md), [GitHub Actions](integrations-github-action-add.md).

**Anmerkung**  
AWS unterstützt oder garantiert nicht den Aktionscode von GitHub Aktionen oder Aktionen Dritter.<a name="workflows-to-view-source-cc"></a>

**Um den Quellcode einer Aktion einzusehen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Wählen Sie Ihr Projekt.

1. Suchen Sie die Aktion, deren Code Sie sich ansehen möchten:

   1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

   1. Wählen Sie den Namen eines beliebigen Workflows oder erstellen Sie einen. Informationen zum Erstellen eines Workflows finden Sie unter[Einen Workflow erstellen](workflows-create-workflow.md).

   1. Wählen Sie **Bearbeiten** aus.

   1. Wählen Sie links oben **\$1 Aktionen** aus, um den Aktionskatalog zu öffnen.

   1. Wählen Sie in der Drop-down-Liste **Amazon CodeCatalyst** zum Ansehen CodeCatalyst, CodeCatalyst Labs und Aktionen von Drittanbietern aus.

   1. Suchen Sie nach einer Aktion und wählen Sie ihren Namen. Wählen Sie nicht das Pluszeichen (**\$1**).

      Details zur Aktion werden angezeigt.

1. Wählen Sie im Dialogfeld mit den Aktionsdetails unten die Option **Herunterladen** aus.

   Es wird eine Seite mit dem Amazon S3 S3-Bucket angezeigt, in dem sich der Quellcode der Aktion befindet. Informationen zu Amazon S3 finden Sie unter [Was ist Amazon S3?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) im *Amazon Simple Storage Service-Benutzerhandbuch*.

1. Prüfen Sie den Code, um sicherzustellen, dass er Ihren Qualitäts- und Sicherheitserwartungen entspricht. 

# Integration mit GitHub Aktionen
<a name="integrations-github-actions"></a>

Eine *GitHub Aktion* ist einer [CodeCatalyst Aktion](workflows-actions.md#workflows-actions-types-cc) sehr ähnlich, außer dass sie für die Verwendung mit GitHub Workflows entwickelt wurde. Einzelheiten zu GitHub Aktionen finden Sie in der Dokumentation zu [GitHub Aktionen](https://docs.github.com/en/actions).

Sie können GitHub Aktionen zusammen mit systemeigenen CodeCatalyst Aktionen in einem CodeCatalyst Workflow verwenden.

Es gibt zwei Möglichkeiten, einem CodeCatalyst Workflow eine GitHub Aktion hinzuzufügen:
+ Sie können die GitHub Aktion aus einer kuratierten Liste in der CodeCatalyst Konsole auswählen. Es sind mehrere beliebte GitHub Aktionen verfügbar. Weitere Informationen finden Sie unter [Eine kuratierte Aktion GitHub hinzufügen](integrations-github-action-add-curated.md).
+ Wenn die GitHub Aktion, die Sie verwenden möchten, in der CodeCatalyst Konsole nicht verfügbar ist, können Sie sie mithilfe der Aktion **GitHub Aktionen** hinzufügen.

  Eine ***GitHub Aktionen-Aktion*** ist eine *CodeCatalyst Aktion*, die eine GitHub Aktion umschließt und sie mit CodeCatalyst Workflows kompatibel macht.

  Hier ist ein Beispiel für eine **GitHub Actions-Aktion**, die die [Super-Linter-Action umschließt:](https://github.com/marketplace/actions/super-linter) GitHub

  ```
  Actions:
    GitHubAction:
      Identifier: aws/github-actions-runner@v1
      Configuration:
        Steps:
          - name: Lint Code Base
            uses: github/super-linter@v4
            env:
              VALIDATE_ALL_CODEBASE: "true"
              DEFAULT_BRANCH: main
  ```

  Im vorherigen Code umschließt die Aktion CodeCatalyst **GitHub Aktionen** (identifiziert durch`aws/github-actions-runner@v1`) die Super-Linter-Aktion (identifiziert durch`github/super-linter@v4`), sodass sie in einem Workflow funktioniert. CodeCatalyst 

  Weitere Informationen finden Sie unter [Aktion „GitHub Aktionen“ hinzufügen](integrations-github-action-add.md).

Alle GitHub Aktionen — sowohl kuratierte als auch nicht — müssen in eine **GitHub Aktionsaktion** () `aws/github-actions-runner@v1` eingeschlossen werden, wie im vorherigen Beispiel gezeigt. Der Wrapper ist erforderlich, damit die Aktion ordnungsgemäß funktioniert. 

**Topics**
+ [

## Wie unterscheiden sich GitHub Aktionen von CodeCatalyst Aktionen?
](#integrations-github-actions-how-different)
+ [

## Können GitHub Aktionen mit anderen CodeCatalyst Aktionen im Workflow interagieren?
](#integrations-github-actions-interactions.title)
+ [

## Welche GitHub Aktionen kann ich verwenden?
](#integrations-github-actions-supported)
+ [

## Einschränkungen von GitHub Aktionen in CodeCatalyst
](#integrations-github-actions-limitations)
+ [

## Wie füge ich eine GitHub Aktion hinzu (allgemeine Schritte)?
](#integrations-github-actions-how-to)
+ [

## Wird die GitHub Aktion ausgeführt GitHub?
](#integrations-github-actions-where-it-runs)
+ [

## Kann ich auch GitHub Workflows verwenden?
](#integrations-github-actions-workflows-support.title)
+ [

## Von der Aktion „GitHub Aktionen“ verwendetes Runtime-Image
](#integrations-github-actions-runtime)
+ [

# Tutorial: Lint-Code mit einer GitHub Aktion
](integrations-github-action-tutorial.md)
+ [

# Aktion „GitHub Aktionen“ hinzufügen
](integrations-github-action-add.md)
+ [

# Eine kuratierte Aktion GitHub hinzufügen
](integrations-github-action-add-curated.md)
+ [

# GitHub Ausgabeparameter exportieren
](integrations-github-action-export.md)
+ [

# Referenzieren von GitHub Ausgabeparametern
](integrations-github-action-referencing.md)
+ [

# Aktion 'GitHub Aktionen' YAML
](github-action-ref.md)

## Wie unterscheiden sich GitHub Aktionen von CodeCatalyst Aktionen?
<a name="integrations-github-actions-how-different"></a>

GitHub Aktionen, die innerhalb eines CodeCatalyst Workflows verwendet werden, haben nicht die gleiche Zugriffs- und Integrationsebene mit AWS den CodeCatalyst Funktionen (wie [Umgebungen](deploy-environments.md) und [Probleme](issues.md)) wie CodeCatalyst Aktionen.

## Können GitHub Aktionen mit anderen CodeCatalyst Aktionen im Workflow interagieren?
<a name="integrations-github-actions-interactions.title"></a>

Ja. GitHub Aktionen können beispielsweise Variablen, die von anderen CodeCatalyst Aktionen erzeugt wurden, als Eingabe verwenden und auch Ausgabeparameter und Artefakte gemeinsam mit CodeCatalyst Aktionen verwenden. Weitere Informationen erhalten Sie unter [GitHub Ausgabeparameter exportieren](integrations-github-action-export.md) und [Referenzieren von GitHub Ausgabeparametern](integrations-github-action-referencing.md).

## Welche GitHub Aktionen kann ich verwenden?
<a name="integrations-github-actions-supported"></a>

Sie können jede GitHub Aktion verwenden, die über die CodeCatalyst Konsole verfügbar ist, und jede GitHub Aktion, die im [GitHubMarketplace](https://github.com/marketplace/actions) verfügbar ist. Wenn Sie sich für eine GitHub Aktion aus dem Marketplace entscheiden, beachten Sie die folgenden [Einschränkungen](#integrations-github-actions-limitations).

## Einschränkungen von GitHub Aktionen in CodeCatalyst
<a name="integrations-github-actions-limitations"></a>
+ GitHub Aktionen können nicht mit dem CodeCatalyst [Lambda-Compute-Typ](workflows-working-compute.md#compute.types) verwendet werden.
+ GitHub Aktionen werden auf dem Docker-Image der Laufzeitumgebung [vom November 2022](build-images.md#build.previous-image) ausgeführt, das ältere Tools enthält. Weitere Informationen über das Image und die Tools finden Sie unter. [Angabe von Images für die Laufzeitumgebung](build-images.md)
+ GitHub Aktionen, die intern auf den [`github`Kontext](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) angewiesen sind oder auf GitHub spezifische Ressourcen verweisen, funktionieren nicht in. CodeCatalyst Die folgenden Aktionen funktionieren beispielsweise nicht in CodeCatalyst:
  + Aktionen, die versuchen, GitHub Ressourcen hinzuzufügen, zu ändern oder zu aktualisieren. Beispiele hierfür sind Aktionen, die Pull-Requests aktualisieren oder Probleme in verursachen GitHub.
  + Fast alle Aktionen sind in [https://github.com/actions](https://github.com/actions) aufgeführt.
+ GitHub Aktionen, bei denen es sich um [Docker-Container-Aktionen](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions) handelt, funktionieren, müssen jedoch vom Docker-Standardbenutzer (root) ausgeführt werden. Führen Sie die Aktion nicht als Benutzer 1001 aus. (Zum Zeitpunkt des Schreibens arbeitet der Benutzer 1001 in GitHub, aber nicht in CodeCatalyst.) Weitere Informationen finden Sie im Thema [USER](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) unter [Dockerfile-Unterstützung für GitHub Aktionen](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions).

Eine Liste der über die CodeCatalyst Konsole verfügbaren GitHub Aktionen finden Sie unter. [Eine kuratierte Aktion GitHub hinzufügen](integrations-github-action-add-curated.md)

## Wie füge ich eine GitHub Aktion hinzu (allgemeine Schritte)?
<a name="integrations-github-actions-how-to"></a>

Die allgemeinen Schritte zum Hinzufügen einer GitHub Aktion zu einem CodeCatalyst Workflow lauten wie folgt:

1. In Ihrem CodeCatalyst Projekt **erstellen Sie einen Workflow**. In diesem Workflow definieren Sie, wie Ihre Anwendung erstellt, getestet und bereitgestellt werden soll. Weitere Informationen finden Sie unter [Erste Schritte mit Workflows](workflows-getting-started.md).

1. Im Workflow **fügen Sie eine kuratierte GitHub Aktion** hinzu oder Sie **fügen die Aktion GitHub Aktionen** hinzu.

1. Sie führen einen der folgenden Schritte aus:
   + Wenn Sie eine kuratierte Aktion hinzufügen möchten, konfigurieren Sie sie. Weitere Informationen finden Sie unter [Eine kuratierte Aktion GitHub hinzufügen](integrations-github-action-add-curated.md).
   + Wenn Sie eine nicht kuratierte Aktion hinzufügen möchten, **fügen Sie innerhalb der Aktion **GitHubAktionen** den YAML-Code der GitHub Aktion** ein. Du findest diesen Code auf der Detailseite deiner ausgewählten GitHub Aktion im [GitHubMarketplace](https://github.com/marketplace/actions). Sie müssen den Code wahrscheinlich leicht modifizieren, damit er funktioniert CodeCatalyst. Weitere Informationen finden Sie unter [Aktion „GitHub Aktionen“ hinzufügen](integrations-github-action-add.md).

1. (Optional) Innerhalb des Workflows **fügen Sie weitere Aktionen** wie die Build- und Testaktionen hinzu. Weitere Informationen finden Sie unter [Erstellen, Testen und Bereitstellen mit WorkflowsMit Workflows erstellen, testen und bereitstellen](workflow.md).

1. Sie **starten den Workflow** entweder manuell oder automatisch über einen Trigger. Der Workflow führt die GitHub Aktion und alle anderen Aktionen im Workflow aus. Weitere Informationen finden Sie unter [Manuelles Starten einer Workflow-Ausführung](workflows-manually-start.md).

Eine ausführliche Anleitung finden Sie unter:
+ [Eine kuratierte Aktion GitHub hinzufügen](integrations-github-action-add-curated.md).
+ [Aktion „GitHub Aktionen“ hinzufügen](integrations-github-action-add.md).

## Wird die GitHub Aktion ausgeführt GitHub?
<a name="integrations-github-actions-where-it-runs"></a>

Nein. Die GitHub Aktion wird unter Verwendung CodeCatalyst des [Laufzeitumgebungsabbilds](workflows-working-compute.md) ausgeführt. CodeCatalyst

## Kann ich auch GitHub Workflows verwenden?
<a name="integrations-github-actions-workflows-support.title"></a>

Nein.

## Von der Aktion „GitHub Aktionen“ verwendetes Runtime-Image
<a name="integrations-github-actions-runtime"></a>

Die Aktion CodeCatalyst **GitHub Aktionen** wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Tutorial: Lint-Code mit einer GitHub Aktion
<a name="integrations-github-action-tutorial"></a>

In diesem Tutorial fügen Sie die [ GitHub Super-Linter-Aktion](https://github.com/marketplace/actions/super-linter) zu einem CodeCatalyst Amazon-Workflow hinzu. Die Super-Linter-Aktion untersucht den Code, findet Bereiche, in denen der Code Fehler, Formatierungsprobleme und verdächtige Konstrukte aufweist, und gibt die Ergebnisse dann an die Konsole aus). CodeCatalyst Nachdem Sie den Linter zu Ihrem Workflow hinzugefügt haben, führen Sie den Workflow aus, um eine Node.js -Beispielanwendung () zu linten. `app.js` Anschließend beheben Sie die gemeldeten Probleme und führen den Workflow erneut aus, um zu überprüfen, ob die Korrekturen erfolgreich waren.

**Tipp**  
[Erwägen Sie, Super-Linter zu verwenden, um YAML-Dateien wie Vorlagen zu verlinken.CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)

**Topics**
+ [

## Voraussetzungen
](#integrations-github-action-tutorial-prereqs)
+ [

## Schritt 1: Erstellen Sie ein Quell-Repository
](#integrations-github-action-tutorial-create-source-repo)
+ [

## Schritt 2: Fügen Sie eine Datei app.js hinzu
](#integrations-github-action-tutorial-add-appjs)
+ [

## Schritt 3: Erstellen Sie einen Workflow, der die Super-Linter-Aktion ausführt
](#integrations-github-action-tutorial-create-workflow)
+ [

## Schritt 4: Probleme beheben, die der Super-Linter gefunden hat
](#integrations-github-action-tutorial-fix-probs)
+ [

## Bereinigen
](#integrations-github-action-tutorial-cleanup)

## Voraussetzungen
<a name="integrations-github-action-tutorial-prereqs"></a>

Bevor Sie beginnen, benötigen Sie:
+ Ein CodeCatalyst **Leerzeichen** mit einem verbundenen AWS-Konto. Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ Ein leeres Projekt in Ihrem CodeCatalyst Bereich namens`codecatalyst-linter-project`. Wählen Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  ```
  ```

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).

## Schritt 1: Erstellen Sie ein Quell-Repository
<a name="integrations-github-action-tutorial-create-source-repo"></a>

In diesem Schritt erstellen Sie ein Quell-Repository in CodeCatalyst. In diesem Repository speichern Sie die Quelldatei der Beispielanwendung für dieses Tutorial. `app.js`

Weitere Informationen zu Quell-Repositorys finden Sie unter[Erstellen eines Quell-Repositorys](source-repositories-create.md).

**Um ein Quell-Repository zu erstellen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Navigieren Sie zu Ihrem Projekt,`codecatalyst-linter-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Source Repositories** aus. 

1. Wählen **Sie Repository hinzufügen** und anschließend **Repository erstellen** aus.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   codecatalyst-linter-source-repository
   ```

1. Wählen Sie **Erstellen** aus.

## Schritt 2: Fügen Sie eine Datei app.js hinzu
<a name="integrations-github-action-tutorial-add-appjs"></a>

In diesem Schritt fügen Sie Ihrem Quell-Repository eine `app.js` Datei hinzu. Der `app.js` enthält Funktionscode, der einige Fehler enthält, die der Linter finden wird.

**Um die Datei app.js hinzuzufügen**

1. Wählen Sie in der CodeCatalyst Konsole Ihr Projekt aus,`codecatalyst-linter-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Source Repositories** aus.

1. Wählen Sie aus der Liste der Quell-Repositorys Ihr Repository aus. `codecatalyst-linter-source-repository`

1. Wählen Sie unter **Dateien** die Option **Datei erstellen** aus.

1. Geben Sie in das Textfeld den folgenden Code ein:

   ```
   // const axios = require('axios')
   // const url = 'http://checkip.amazonaws.com/';
   let response;
   /**
    *
    * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
    * @param {Object} event - API Gateway Lambda Proxy Input Format
    *
    * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html 
    * @param {Object} context
    *
    * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
    * @returns {Object} object - API Gateway Lambda Proxy Output Format
    *
    */
   exports.lambdaHandler = async (event, context) => {
     try {
       // const ret = await axios(url);
       response = {
         statusCode: 200,
         'body': JSON.stringify({
           message: 'hello world'
           // location: ret.data.trim()
         })
       }
     } catch (err) {
       console.log(err)
       return err
     }
   
       return response
   }
   ```

1. Geben Sie als **Dateiname** ein`app.js`. Behalten Sie die anderen Standardoptionen bei.

1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt eine Datei mit dem Namen erstellt`app.js`.

## Schritt 3: Erstellen Sie einen Workflow, der die Super-Linter-Aktion ausführt
<a name="integrations-github-action-tutorial-create-workflow"></a>

In diesem Schritt erstellen Sie einen Workflow, der die Super-Linter-Aktion ausführt, wenn Sie Code in Ihr Quell-Repository übertragen. Der Workflow besteht aus den folgenden Bausteinen, die Sie in einer YAML-Datei definieren:
+ **Ein Trigger** — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ **Eine Aktion „GitHub Aktionen“ — Beim** Auslösen führt die Aktion **GitHub Aktionen** die Super-Linter-Aktion aus, die wiederum alle Dateien in Ihrem Quell-Repository überprüft. Findet der Linter ein Problem, schlägt die Workflow-Aktion fehl. 

**Um einen Workflow zu erstellen, der die Super-Linter-Aktion ausführt**

1. Wählen Sie in der CodeCatalyst Konsole Ihr Projekt aus,. `codecatalyst-linter-project`

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.** 

1. Wählen Sie Workflow **erstellen** aus.

1. Wählen Sie für **Quell-Repository** die Option`codecatalyst-linter-source-repository`.

1. Wählen Sie für **Branch** die Option`main`.

1. Wählen Sie **Erstellen** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie das folgende YAML hinzu:

   ```
   Name: codecatalyst-linter-workflow
   SchemaVersion: "1.0"
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     SuperLinterAction:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           github-action-code
   ```

   Ersetzen Sie den Code im vorherigen Code *github-action-code* durch den Super-Linter-Aktionscode, wie in den folgenden Schritten dieses Verfahrens beschrieben.

1. Gehen Sie auf die [Super-Linter-Seite](https://github.com/marketplace/actions/super-linter) im GitHub Marketplace.

1. Suchen Sie unter `steps:` (Kleinbuchstaben) nach dem Code und fügen Sie ihn in den CodeCatalyst Workflow unter `Steps:` (Großbuchstaben) ein.

   Passen Sie den GitHub Aktionscode an die CodeCatalyst Standards an, wie im folgenden Code gezeigt.

   Ihr CodeCatalyst Workflow sieht jetzt wie folgt aus:

   ```
   Name: codecatalyst-linter-workflow
   SchemaVersion: "1.0"
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     SuperLinterAction:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           - name: Lint Code Base
             uses: github/super-linter@v4
             env:
               VALIDATE_ALL_CODEBASE: "true"
               DEFAULT_BRANCH: main
   ```

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit**, geben Sie eine **Commit-Nachricht** ein, wählen Sie Ihr `codecatalyst-linter-source-repository` **Repository** aus und wählen Sie erneut **Commit** aus.

   Sie haben jetzt einen Workflow erstellt. Eine Workflow-Ausführung wird aufgrund des oben im Workflow definierten Triggers automatisch gestartet.

**Um die laufende Workflow-Ausführung anzuzeigen**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie den Workflow aus, den Sie gerade erstellt haben:. `codecatalyst-linter-workflow`

1. Wählen Sie im Workflow-Diagramm **SuperLinterAction**.

1. Warten Sie, bis die Aktion fehlschlägt. Dieser Fehler wird erwartet, weil der Linter Probleme im Code gefunden hat.

1. Lassen Sie die CodeCatalyst Konsole geöffnet und gehen Sie zu[Schritt 4: Probleme beheben, die der Super-Linter gefunden hat](#integrations-github-action-tutorial-fix-probs).

## Schritt 4: Probleme beheben, die der Super-Linter gefunden hat
<a name="integrations-github-action-tutorial-fix-probs"></a>

Der Super-Linter sollte Probleme im `app.js` Code sowie in der `README.md` Datei gefunden haben, die in Ihrem Quell-Repository enthalten ist.

**Um die Probleme zu beheben, die der Linter gefunden hat**

1. Wählen Sie in der CodeCatalyst Konsole die Registerkarte **Logs** und dann **Lint Code Base** aus.

   Die Protokolle, die die Super-Linter-Aktion generiert hat, werden angezeigt.

1. Scrollen Sie in den Super-Linter-Protokollen nach unten bis etwa Zeile 90, wo Sie den Beginn der Probleme finden. Sie sehen etwa wie folgt aus: 

   ```
   /github/workspace/hello-world/app.js:3:13: Extra semicolon.
   /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
   /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
   /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
   /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
   ```

1. Korrigieren Sie `app.js` und `README.md` in Ihrem Quell-Repository und übernehmen Sie Ihre Änderungen. 
**Tipp**  
Um das zu beheben`README.md`, füge `markdown` es dem Codeblock wie folgt hinzu:  

   ```
   ```markdown
   Setup examples:
   ...
   ```
   ```

   Ihre Änderungen starten automatisch eine weitere Workflow-Ausführung. Warten Sie, bis der Workflow abgeschlossen ist. Wenn Sie alle Probleme behoben haben, sollte der Workflow erfolgreich sein.

## Bereinigen
<a name="integrations-github-action-tutorial-cleanup"></a>

Bereinigen Sie in CodeCatalyst , um Spuren dieses Tutorials aus Ihrer Umgebung zu entfernen.

**Zum Aufräumen in CodeCatalyst**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Löschen`codecatalyst-linter-source-repository`.

1. Löschen`codecatalyst-linter-workflow`.

In diesem Tutorial haben Sie gelernt, wie Sie die GitHub Super-Linter-Aktion zu einem CodeCatalyst Workflow hinzufügen, um Code zu vereinfachen.

# Aktion „GitHub Aktionen“ hinzufügen
<a name="integrations-github-action-add"></a>

Eine ***GitHub Aktionsaktion*** ist eine *CodeCatalyst Aktion*, die eine GitHub Aktion umschließt und sie mit Workflows kompatibel macht. CodeCatalyst 

Weitere Informationen finden Sie unter [Integration mit GitHub Aktionen](integrations-github-actions.md).

Gehen Sie folgendermaßen vor, um die Aktion **GitHub Aktionen** zu einem Workflow hinzuzufügen.

**Tipp**  
Ein Tutorial, das Ihnen zeigt, wie Sie die Aktion **GitHub Aktionen** verwenden, finden Sie unter[Tutorial: Lint-Code mit einer GitHub Aktion](integrations-github-action-tutorial.md).

------
#### [ Visual ]

**So fügen Sie die Aktion „GitHub Aktionen“ mit dem visuellen Editor hinzu**

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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste die Option **GitHub**.

1. Suchen Sie nach der Aktion **GitHub Aktionen** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **GitHub Aktionen**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion 'GitHub Aktionen' YAML](github-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „GitHub Aktionen“ 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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste die Option **GitHub**.

1. Suchen Sie nach der Aktion **GitHub Aktionen** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **GitHub Aktionen**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion 'GitHub Aktionen' YAML](github-action-ref.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.

------

## GitHub Aktionsdefinition 'Aktionen'
<a name="integrations-github-action-add-definition"></a>

Die Aktion „**GitHub Aktionen**“ ist als eine Reihe von YAML-Eigenschaften in Ihrer Workflow-Definitionsdatei definiert. Informationen zu diesen Eigenschaften finden Sie [Aktion 'GitHub Aktionen' YAML](github-action-ref.md) in der[YAML-Workflow-Definition](workflow-reference.md).

# Eine kuratierte Aktion GitHub hinzufügen
<a name="integrations-github-action-add-curated"></a>

Eine *kuratierte GitHub Aktion* ist eine GitHub Aktion, die in der CodeCatalyst Konsole verfügbar gemacht wird und als Beispiel für die Verwendung einer GitHub Aktion innerhalb eines CodeCatalyst Workflows dient.

Kuratierte GitHub Aktionen sind in der [Aktion „ CodeCatalyst-authored **GitHub Actions**](integrations-github-action-add.md)“ zusammengefasst, die durch die ID identifiziert wird. `aws/github-actions-runner@v1` [Die kuratierte GitHub Aktion OSS sieht zum Beispiel wie folgt aus: TruffleHog ](https://github.com/marketplace/actions/trufflehog-oss) 

```
Actions:
  TruffleHogOSS_e8:
    Identifier: aws/github-actions-runner@v1
    Inputs:
      Sources:
        - WorkflowSource # This specifies that the action requires this Workflow as a source
    Configuration:
      Steps:
        - uses: trufflesecurity/trufflehog@v3.16.0
          with:
            path: ' ' # Required; description: Repository path
            base: ' ' # Required; description: Start scanning from here (usually main branch).
            head: ' ' # Optional; description: Scan commits until here (usually dev branch).
            extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```

Im vorherigen Code umschließt die Aktion CodeCatalyst **GitHub Aktionen** (identifiziert durch`aws/github-actions-runner@v1`) die TruffleHog OSS-Aktion (identifiziert durch`trufflesecurity/trufflehog@v3.16.0`), sodass sie in einem CodeCatalyst Workflow funktioniert.

Um diese Aktion zu konfigurieren, würden Sie die leeren Zeichenfolgen unter `with:` durch Ihre eigenen Werte ersetzen. Beispiel:

```
Actions:
  TruffleHogOSS_e8:
    Identifier: aws/github-actions-runner@v1
    Inputs:
      Sources:
        - WorkflowSource # This specifies that the action requires this Workflow as a source
    Configuration:
      Steps:
        - uses: trufflesecurity/trufflehog@v3.16.0
          with:
            path: ./
            base: main # Required; description: Start scanning from here (usually main branch).
            head: HEAD # Optional; description: Scan commits until here (usually dev branch).
            extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```

Gehen Sie wie folgt vor, um einem Workflow eine kuratierte GitHub Aktion hinzuzufügen. Allgemeine Informationen zur Verwendung von GitHub Aktionen in einem CodeCatalyst Workflow finden Sie unter[Integration mit GitHub Aktionen](integrations-github-actions.md).

**Anmerkung**  
Wenn Sie Ihre GitHub Aktion nicht in der Liste der kuratierten Aktionen sehen, können Sie sie trotzdem mit der Aktion **GitHub Aktionen** zu Ihrem Workflow hinzufügen. Weitere Informationen finden Sie unter [Aktion „GitHub Aktionen“ hinzufügen](integrations-github-action-add.md).

------
#### [ Visual ]

**Um eine kuratierte GitHub Aktion mit dem visuellen 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste die Option **GitHub**.

1. Suchen oder suchen Sie nach einer GitHub Aktion und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie den Namen der GitHub Aktion. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld gehen Sie wie folgt vor:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben**, **Konfiguration** und **Ausgaben** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion 'GitHub Aktionen' YAML](github-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), das für die Aktion **GitHubAktionen** verfügbar ist, da es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

   Informationen zu den Konfigurationsoptionen, die für die kuratierte GitHub Aktion verfügbar sind, finden Sie in der zugehörigen Dokumentation.

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 eine kuratierte GitHub Aktion 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. Wählen Sie links oben **\$1 Aktionen aus, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste die Option **GitHub**.

1. Suchen oder suchen Sie nach einer GitHub Aktion und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie den Namen der GitHub Aktion. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld gehen Sie wie folgt vor:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen Eigenschaften, die für die Aktion **GitHub Aktionen** verfügbar sind, finden Sie in. [Aktion 'GitHub Aktionen' YAML](github-action-ref.md)

   Informationen zu den Konfigurationsoptionen, die für die kuratierte GitHub Aktion verfügbar sind, finden Sie in der zugehörigen Dokumentation.

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.

------

# GitHub Ausgabeparameter exportieren
<a name="integrations-github-action-export"></a>

Sie können [GitHub Ausgabeparameter](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter) in Ihren CodeCatalyst Workflows verwenden.

**Anmerkung**  
Ein anderes Wort für *Ausgabeparameter* ist *variabel*. Da in der Dokumentation der Begriff *Ausgabeparameter GitHub * verwendet wird, werden wir diesen Begriff auch verwenden.

Verwenden Sie die folgenden Anweisungen, um einen GitHub Ausgabeparameter aus einer GitHub Aktion zu exportieren, sodass er für andere CodeCatalyst Workflow-Aktionen verfügbar ist.

**Um einen GitHub Ausgabeparameter zu exportieren**

1. Öffnen Sie einen Workflow und wählen Sie **Bearbeiten**. Weitere Informationen finden Sie unter [Einen Workflow erstellen](workflows-create-workflow.md).

1. Fügen Sie in der Aktion **GitHub Aktionen**, die den Ausgabeparameter generiert, den Sie exportieren möchten, einen `Outputs` Abschnitt mit einer zugrunde liegenden `Variables` Eigenschaft hinzu, die wie folgt aussieht:

   ```
   Actions:
     MyGitHubAction:
       Identifier: aws/github-actions-runner@v1
       Outputs:
         Variables:
           - 'step-id_output-name'
   ```

   Ersetze:
   + *step-id*mit dem Wert der `id:` Eigenschaft im `steps` Abschnitt der GitHub Aktion.
   + *output-name*mit dem Namen des GitHub Ausgabeparameters.

**Beispiel**  
Das folgende Beispiel zeigt Ihnen, wie Sie einen GitHub Ausgabeparameter namens exportieren`SELECTEDCOLOR`.

   ```
   Actions:
     MyGitHubAction:
       Identifier: aws/github-actions-runner@v1
       Outputs:
         Variables:
           - 'random-color-generator_SELECTEDCOLOR'
       Configuration:
         Steps:
           - name: Set selected color
             run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
             id: random-color-generator
   ```

# Referenzieren von GitHub Ausgabeparametern
<a name="integrations-github-action-referencing"></a>

Verwenden Sie die folgenden Anweisungen, um auf einen GitHub Ausgabeparameter zu verweisen.

**Um auf einen GitHub Ausgabeparameter zu verweisen**

1. Führen Sie die Schritte unter [GitHub Ausgabeparameter exportieren](integrations-github-action-export.md) aus.

   Der GitHub Ausgabeparameter ist jetzt für die Verwendung in anderen Aktionen verfügbar.

1. Notieren Sie sich den `Variables` Wert des Ausgabeparameters. Er enthält einen Unterstrich (\$1).

1. Verwenden Sie für den Ausgabeparameter die folgende Syntax:

   ```
   ${action-name.output-name}
   ```

   Ersetzen Sie:
   + *action-name*mit dem Namen der CodeCatalyst **GitHub Aktion**, die den Ausgabeparameter erzeugt (verwenden Sie nicht das `name` oder der GitHub Aktion`id`).
   + *output-name*mit dem `Variables` Wert des Ausgabeparameters, den Sie zuvor notiert haben.

   **Beispiel**

   ```
   BuildActionB:
     Identifier: aws/build@v1
     Configuration:
       Steps:
         - Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
   ```

**Beispiel mit Kontext**  
Das folgende Beispiel zeigt Ihnen, wie Sie eine `SELECTEDCOLOR` Variable eingeben`GitHubActionA`, ausgeben und dann in darauf verweisen`BuildActionB`.

   ```
   Actions:
     GitHubActionA:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           - name: Set selected color
             run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
             id: random-color-generator
       Outputs:
         Variables:
         - 'random-color-generator_SELECTEDCOLOR'
         
      BuildActionB:
       Identifier: aws/build@v1
       Configuration:
         Steps:
           - Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
   ```

# Aktion 'GitHub Aktionen' YAML
<a name="github-action-ref"></a>

Im Folgenden finden Sie die YAML-Definition der Aktion **GitHubAktionen**.

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).

Wählen Sie im folgenden Code eine YAML-Eigenschaft aus, um eine Beschreibung zu erhalten.

**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 action definition starts here.
  action-name:
    Identifier:  aws/github-actions-runner@v1
    DependsOn:
      - dependent-action-name-1
    Compute:
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Inputs:
      Sources:
        - source-name-1
        - source-name-2
      Artifacts:
        - artifact-name
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2   
    Outputs:
      Artifacts:
        - Name: output-artifact-1
          Files: 
            - github-output/artifact-1.jar
            - "github-output/build*"
        - Name: output-artifact-2
          Files:
            - github-output/artifact-2.1.jar
            - github-output/artifact-2.2.jar
      Variables:
        - variable-name-1
        - variable-name-2
      AutoDiscoverReports:
        Enabled: true | false
        ReportNamePrefix: AutoDiscovered
        IncludePaths:
          - "**/*"
        ExcludePaths:
          - node_modules/cdk/junit.xml
        SuccessCriteria:
          PassRate: percent
          LineCoverage: percent
          BranchCoverage: percent
          Vulnerabilities:
            Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
            Number: whole-number
      Reports:
        report-name-1:
          Format: format
          IncludePaths:
            - "*.xml"
          ExcludePaths:
            - report2.xml
            - report3.xml
          SuccessCriteria:
            PassRate: percent
            LineCoverage: percent
            BranchCoverage: percent
            Vulnerabilities:
              Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
              Number: whole-number
    Configuration      
      Steps:
        - github-actions-code
```

## Aktionsname
<a name="github.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/*action-name*

## Identifier
<a name="github.identifier"></a>

(*action-name*/**Identifier**)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

`aws/github-actions-runner@v1`Für **GitHubAktionen** verwenden.

Entsprechende Benutzeroberfläche: *action-name* **Workflow-Diagram/aws/ @v1 label github-actions-runner**

## DependsOn
<a name="github.depends-on"></a>

(*action-name*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="github.computename"></a>

(*action-name*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Fleet
<a name="github.computefleet"></a>

(*action-name*/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`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Compute Fleet“ — optional**

## Timeout
<a name="github.timeout"></a>

(*action-name*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Environment
<a name="github.environment"></a>

(*action-name*/**Environment**)

(Optional)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="github.environment.name"></a>

(*action-name*/Environment/**Name**)

(Erforderlich, falls [Environment](#github.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="github.environment.connections"></a>

(*action-name*/Environment/**Connections**)

(Optional)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Ist tab/Environment/What die Konfiguration aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Name
<a name="github.environment.connections.name"></a>

(*action-name*/Environment/Connections/**Name**)

(Erforderlich, falls enthalten[Connections](#github.environment.connections))

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Ist tab/Environment/What die Konfiguration aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Role
<a name="github.environment.connections.role"></a>

(*action-name*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#github.environment.connections))

Geben Sie den Namen der IAM-Rolle an, die diese Aktion verwendet, um auf AWS Dienste wie Amazon S3 und Amazon ECR zuzugreifen und diese zu nutzen. Stellen Sie sicher, dass diese Rolle zu Ihrer AWS-Konto Verbindung in Ihrem Bereich hinzugefügt wird. Informationen zum Hinzufügen einer IAM-Rolle zu einer Kontoverbindung finden Sie unter[Hinzufügen von IAM-Rollen zu Kontoverbindungen](ipa-connect-account-addroles.md).

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der Konsole aufgeführt ist. CodeCatalyst Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

**Warnung**  
Beschränken Sie die Berechtigungen auf diejenigen, die für die **GitHub Aktion Aktion** erforderlich sind. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.

Entsprechende Benutzeroberfläche: tab/Environment/What Die Konfiguration ist aktiviert*my-environment*? **/Dreipunktmenü/ Rolle wechseln**

## Inputs
<a name="github.inputs"></a>

(*action-name*/**Inputs**)

(Optional)

`Inputs`In diesem Abschnitt werden die Daten definiert, die eine Aktion während einer Workflow-Ausführung benötigt.

**Anmerkung**  
Pro **GitHub Aktionsaktion** sind maximal vier Eingaben (eine Quelle und drei Artefakte) zulässig. Variablen werden auf diese Summe nicht angerechnet.

Wenn Sie auf Dateien verweisen müssen, die sich in unterschiedlichen Eingaben befinden (z. B. eine Quelle und ein Artefakt), ist die Quelleingabe die primäre Eingabe und das Artefakt die sekundäre Eingabe. Verweise auf Dateien in sekundären Eingaben benötigen ein spezielles Präfix, um sie von der primären Eingabe zu unterscheiden. Details hierzu finden Sie unter [Beispiel: Referenzieren von Dateien in mehreren Artefakten](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“**

## Sources
<a name="github.inputs.sources"></a>

(*action-name*/Inputs/**Sources**)

(Optional)

Geben Sie die Labels an, die die Quell-Repositorys repräsentieren, die für die Aktion benötigt werden. Derzeit wird nur die Bezeichnung, die das Quell-Repository darstellt`WorkflowSource`, in dem Ihre Workflow-Definitionsdatei gespeichert ist, unterstützt.

Wenn Sie eine Quelle weglassen, müssen Sie mindestens ein Eingabeartefakt unter angeben. `action-name/Inputs/Artifacts`

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="github.inputs.artifacts"></a>

(*action-name*/Inputs/**Artifacts**)

(Optional)

Geben Sie Artefakte aus früheren Aktionen an, die Sie als Eingabe für diese Aktion bereitstellen möchten. Diese Artefakte müssen bereits in früheren Aktionen als Ausgabeartefakte definiert sein.

Wenn Sie keine Eingabeartefakte angeben, müssen Sie mindestens ein Quell-Repository unter angeben`action-name/Inputs/Sources`.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Anmerkung**  
Wenn die Dropdownliste **Artefakte — optional** nicht verfügbar ist (visueller Editor) oder wenn Sie bei der Validierung Ihres YAML (YAML-Editors) Fehler erhalten, liegt das möglicherweise daran, dass die Aktion nur eine Eingabe unterstützt. Versuchen Sie in diesem Fall, die Quelleingabe zu entfernen.

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Artefakte“ — optional**

## Variables - input
<a name="github.inputs.variables"></a>

(*action-name*/Inputs/**Variables**)

(Optional)

Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Variablen“ — optional**

## Outputs
<a name="github.outputs"></a>

(*action-name*/**Outputs**)

(Optional)

Definiert die Daten, die von der Aktion während einer Workflow-Ausführung ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts - output
<a name="github.outputs.artifacts"></a>

(*action-name*/Outputs/**Artifacts**)

(Optional)

Geben Sie den Namen eines Artefakts an, das durch die Aktion generiert wurde. Artefaktnamen müssen innerhalb eines Workflows eindeutig sein und sind auf alphanumerische Zeichen (a-z, A-Z, 0-9) und Unterstriche (\$1) beschränkt. Leerzeichen, Bindestriche (-) und andere Sonderzeichen sind nicht zulässig. Sie können keine Anführungszeichen verwenden, um Leerzeichen, Bindestriche und andere Sonderzeichen in Namen von Ausgabeartefakten zuzulassen.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte**

## Name
<a name="github.outputs.artifacts.name"></a>

(*action-name*/Outputs/Artifacts/**Name**)

(Erforderlich, wenn [Artifacts - output](#github.outputs.artifacts) es enthalten ist)

Geben Sie den Namen eines Artefakts an, das durch die Aktion generiert wurde. Artefaktnamen müssen innerhalb eines Workflows eindeutig sein und sind auf alphanumerische Zeichen (a-z, A-Z, 0-9) und Unterstriche (\$1) beschränkt. Leerzeichen, Bindestriche (-) und andere Sonderzeichen sind nicht zulässig. Sie können keine Anführungszeichen verwenden, um Leerzeichen, Bindestriche und andere Sonderzeichen in Namen von Ausgabeartefakten zuzulassen.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

**Entsprechende Benutzeroberfläche: Gibt den Namen des tab/Artifacts/Add Artefakts aus/Den Namen des Build-Artefakts**

## Files
<a name="github.outputs.artifacts.files"></a>

(*action-name*/Outputs/Artifacts/**Files**)

(Erforderlich, wenn es enthalten ist) [Artifacts - output](#github.outputs.artifacts)

Geben Sie die Dateien an, die in dem Artefakt CodeCatalyst enthalten sind, das von der Aktion ausgegeben wird. Diese Dateien werden durch die Workflow-Aktion generiert, wenn sie ausgeführt wird, und sind auch in Ihrem Quell-Repository verfügbar. Dateipfade können sich in einem Quell-Repository oder einem Artefakt aus einer früheren Aktion befinden und sind relativ zum Quell-Repository oder Artefakt-Stamm. Sie können Glob-Muster verwenden, um Pfade anzugeben. Beispiele:
+ Um eine einzelne Datei anzugeben, die sich im Stammverzeichnis Ihres Build-Speicherorts oder Quell-Repository-Speicherorts befindet, verwenden Sie`my-file.jar`.
+ Um eine einzelne Datei in einem Unterverzeichnis anzugeben, verwenden Sie `directory/my-file.jar` oder`directory/subdirectory/my-file.jar`.
+ Um alle Dateien anzugeben, verwenden Sie`"**/*"`. Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
+ Um alle Dateien und Verzeichnisse in einem Verzeichnis mit dem Namen anzugeben`directory`, verwenden Sie. `"directory/**/*"` Das `**` Glob-Muster gibt an, dass es einer beliebigen Anzahl von Unterverzeichnissen entspricht.
+ Um alle Dateien in einem Verzeichnis mit dem Namen`directory`, aber nicht in einem seiner Unterverzeichnisse anzugeben, verwenden Sie. `"directory/*"` 

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder ein anderes Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Anmerkung**  
Möglicherweise müssen Sie dem Dateipfad ein Präfix hinzufügen, um anzugeben, in welchem Artefakt oder in welcher Quelle das Objekt gefunden werden soll. Weitere Informationen erhalten Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

**Entsprechende Benutzeroberfläche: Gibt tab/Artifacts/Add Artefakte/Dateien aus, die von build erzeugt wurden**

## Variables - output
<a name="github.outputs.variables"></a>

(*action-name*/Outputs/**Variables**)

(Optional)

Geben Sie die Variablen an, die die Aktion exportieren soll, damit sie für nachfolgende Aktionen verfügbar sind.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Variablen/Variable hinzufügen**

## Variablenname-1
<a name="github.outputs.variables.name"></a>

**(Variablenname-1 *action-name*/Outputs/Variables)**

(Optional)

Geben Sie den Namen einer Variablen an, die von der Aktion exportiert werden soll. Diese Variable muss bereits im `Steps` Abschnitt `Inputs` oder derselben Aktion definiert sein.

Weitere Hinweise zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Entsprechende Benutzeroberfläche: Gibt tab/Variables/Add Variable/ Namen aus**

## AutoDiscoverReports
<a name="github.outputs.autodiscover"></a>

(*action-name*/Outputs/**AutoDiscoverReports**)

(Optional)

Definiert die Konfiguration für die Auto-Discovery-Funktion.

Wenn Sie die automatische Erkennung aktivieren, werden alle `Inputs` an die Aktion übergebenen sowie alle von der Aktion selbst generierten Dateien CodeCatalyst durchsucht, wobei nach Test-, Codeabdeckungs- und SCA-Berichten (Software Composition Analysis) gesucht wird. Wandelt jeden gefundenen Bericht in einen CodeCatalyst Bericht um. CodeCatalyst Ein *CodeCatalyst Bericht* ist ein Bericht, der vollständig in den CodeCatalyst Service integriert ist und über die Konsole angezeigt und bearbeitet werden kann. CodeCatalyst 

**Anmerkung**  
Standardmäßig überprüft die automatische Erkennungsfunktion alle Dateien. Mithilfe der Eigenschaften [IncludePaths](#github.reports.includepaths) oder [ExcludePaths](#github.reports.excludepaths) können Sie einschränken, welche Dateien überprüft werden. 

Entsprechende Benutzeroberfläche: *keine*

## Enabled
<a name="github.outputs.autodiscover.enabled"></a>

(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)

(Optional)

Aktivieren oder deaktivieren Sie die automatische Erkennungsfunktion.

Gültige Werte sind `true` oder `false`.

Wenn `Enabled` es weggelassen wird, ist `true` die Standardeinstellung.

**Entsprechende Benutzeroberfläche: Registerkarte „Ausgaben/Berichte“/Berichte automatisch erkennen**

## ReportNamePrefix
<a name="github.outputs.autodiscover.reportnameprefix"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)

(Erforderlich, wenn es enthalten und aktiviert [AutoDiscoverReports](#github.outputs.autodiscover) ist)

Geben Sie ein Präfix an, das allen gefundenen Berichten CodeCatalyst vorangestellt wird, um die zugehörigen CodeCatalyst Berichte zu benennen. Wenn Sie beispielsweise das Präfix von `AutoDiscovered` angeben und zwei Testberichte CodeCatalyst automatisch erkennen, erhalten die zugehörigen CodeCatalyst Berichte den Namen `TestSuiteOne.xml` `AutoDiscoveredTestSuiteOne` und`TestSuiteTwo.xml`. `AutoDiscoveredTestSuiteTwo`

**Entsprechende Benutzeroberfläche: Gibt tab/Reports/Automatically Erkennungsberichte/Berichtspräfix aus**

## IncludePaths
<a name="github.reports.includepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)

(Erforderlich, wenn [AutoDiscoverReports](#github.outputs.autodiscover) es enthalten und aktiviert ist, oder wenn [Reports](#github.configuration.reports) es enthalten ist)

Geben Sie die Dateien und Dateipfade an, CodeCatalyst die bei der Suche nach Rohberichten berücksichtigt werden. Wenn Sie beispielsweise angeben`"/test/report/*"`, wird das gesamte [Build-Image](build-images.md), das von der Aktion verwendet wurde, nach dem `/test/report/*` Verzeichnis CodeCatalyst durchsucht. Wenn das Verzeichnis gefunden CodeCatalyst wird, wird in diesem Verzeichnis nach Berichten gesucht.

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder andere Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Wenn diese Eigenschaft weggelassen wird, ist die Standardeinstellung`"**/*"`, was bedeutet, dass die Suche alle Dateien in allen Pfaden umfasst.

**Anmerkung**  
Bei manuell konfigurierten Berichten `IncludePaths` muss es sich um ein Glob-Muster handeln, das einer einzelnen Datei entspricht.

Entsprechende Benutzeroberfläche:
+ **Gibt Pfade tab/Reports/Automatically discover reports/'Include/exclude aus/Pfade einschließen**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /'Pfade einschließen/ausschließen'/ Pfade *report-name-1* einschließen**

## ExcludePaths
<a name="github.reports.excludepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**)

(Optional)

Geben Sie die Dateien und Dateipfade an, die bei der Suche nach Rohberichten ausgeschlossen werden sollen. CodeCatalyst Wenn Sie beispielsweise angeben`"/test/my-reports/**/*"`, CodeCatalyst wird nicht nach Dateien im `/test/my-reports/` Verzeichnis gesucht. Um alle Dateien in einem Verzeichnis zu ignorieren, verwenden Sie das `**/*` Glob-Muster.

**Anmerkung**  
Wenn Ihr Dateipfad ein oder mehrere Sternchen (`*`) oder andere Sonderzeichen enthält, schließen Sie den Pfad in doppelte Anführungszeichen () ein. `""` Weitere Hinweise zu Sonderzeichen finden Sie unter. [Richtlinien und Konventionen zur Syntax](workflow-reference.md#workflow.terms.syntax.conv)

Entsprechende Benutzeroberfläche:
+ **Gibt tab/Reports/Automatically discover reports/'Include/exclude Pfade aus/Pfade ausschließen**
+ **Gibt Berichte tab/Reports/Manually konfigurieren/ /'Pfade einschließen/ausschließen'/ Pfade ausschließen/ Pfade ausschließen *report-name-1***

## SuccessCriteria
<a name="github.reports.successcriteria"></a>

(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**)

(Optional)

Geben Sie die Erfolgskriterien für die Berichte Test, Codeabdeckung, Software Composition Analysis (SCA) und Static Analysis (SA) an.

Weitere Informationen finden Sie unter [Erfolgskriterien für Berichte konfigurieren](test-config-action.md#test.success-criteria).

Entsprechende Benutzeroberfläche:
+ **Ergebnisse: tab/Reports/Automatically Entdeckungsberichte/Erfolgskriterien**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte// Erfolgskriterien *report-name-1***

## PassRate
<a name="github.reports.successcriteria.passrate"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)

(Optional)

Geben Sie den Prozentsatz der Tests in einem Testbericht an, die bestanden werden müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Erfolgsquote werden nur auf Testberichte angewendet. Weitere Informationen zu Testberichten finden Sie unter[Testberichte](test-workflow-actions.md#test-reports).

Entsprechende Benutzeroberfläche:
+ **Gibt tab/Reports/Automatically discover reports/Success Kriterien/Erfolgsquote aus**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /Erfolgskriterien/ Erfolgsquote *report-name-1***

## LineCoverage
<a name="github.reports.successcriteria.linecoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)

(Optional)

Geben Sie den Prozentsatz der Zeilen in einem Bericht über die Codeabdeckung an, die abgedeckt sein müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Zu den gültigen Werten gehören Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Leitungsabdeckung werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

Entsprechende Benutzeroberfläche:
+ **Gibt tab/Reports/Automatically discover reports/Success Kriterien/Leitungsabdeckung aus**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /Erfolgskriterien/ Leitungsabdeckung *report-name-1***

## BranchCoverage
<a name="github.reports.successcriteria.branchcoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)

(Optional)

Geben Sie den Prozentsatz der Zweige in einem Bericht zur Codeabdeckung an, die abgedeckt werden müssen, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Gültige Werte beinhalten Dezimalzahlen. Zum Beispiel: `50`, `60.5`. Die Kriterien für die Abdeckung von Filialen werden nur auf Berichte zur Codeabdeckung angewendet. Weitere Informationen zu Berichten über die Codeabdeckung finden Sie unter[Code-Abdeckungsberichte](test-workflow-actions.md#test-code-coverage-reports).

Entsprechende Benutzeroberfläche:
+ tab/Reports/Automatically discover reports/Success**Ausgabekriterien/Abdeckung der Filialen**
+ **Ausgaben tab/Reports/Manually konfigurieren Berichte/ /Erfolgskriterien/ Abdeckung *report-name-1* der Filialen**

## Vulnerabilities
<a name="github.reports.successcriteria.vulnerabilities"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)

Oder

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)

(Optional)

Geben Sie die maximale Anzahl und den Schweregrad der Sicherheitslücken an, die im SCA-Bericht zulässig sind, damit der zugehörige CodeCatalyst Bericht als bestanden markiert wird. Um Sicherheitslücken zu spezifizieren, müssen Sie Folgendes angeben:
+ Der Mindestschweregrad der Sicherheitsanfälligkeiten, die Sie in die Zählung einbeziehen möchten. Gültige Werte, vom höchsten bis zum geringsten Schweregrad, sind: `CRITICAL``HIGH`,`MEDIUM`,,`LOW`,`INFORMATIONAL`.

  Wenn Sie beispielsweise wählen `HIGH``HIGH`, werden alle `CRITICAL` Sicherheitslücken gezählt.
+ Die maximale Anzahl von Sicherheitslücken mit dem angegebenen Schweregrad, die Sie zulassen möchten. Wenn diese Zahl überschritten wird, wird der CodeCatalyst Bericht als fehlgeschlagen markiert. Gültige Werte sind ganze Zahlen.

Die Kriterien für Sicherheitslücken werden nur auf SCA-Berichte angewendet. Weitere Informationen zu SCA-Berichten finden Sie unter[Berichte zur Analyse der Softwarezusammensetzung](test-workflow-actions.md#test-sca-reports).

Verwenden Sie die `Severity` Eigenschaft, um den Mindestschweregrad anzugeben. Verwenden Sie die `Number` Eigenschaft, um die maximale Anzahl von Sicherheitslücken anzugeben.

Weitere Informationen zu SCA-Berichten finden Sie unter[Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).

Entsprechende Benutzeroberfläche:
+ **Gibt tab/Reports/Automatically discover reports/Success Kriterien/Sicherheitslücken aus**
+ **Ausgaben tab/Reports/Manually konfigurieren *report-name-1* Berichte/ /Erfolgskriterien/ Sicherheitslücken**

## Reports
<a name="github.configuration.reports"></a>

(*action-name*/Outputs/**Reports** )

(Optional)

Ein Abschnitt, der die Konfiguration für Testberichte spezifiziert.

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Berichte**

## Berichtsname-1
<a name="github.configuration.reports.report-name-1"></a>

**(Berichtsname-1) *action-name* /Outputs/Reports/**

(Erforderlich, falls enthalten) [Reports](#github.configuration.reports)

Der Name, den Sie dem CodeCatalyst Bericht geben möchten, der aus Ihren Rohberichten generiert wird.

**Entsprechende Benutzeroberfläche: Ausgaben, Berichte tab/Reports/Manually konfigurieren/Berichtsname**

## Format
<a name="github.configuration.reports.name.testresults.format"></a>

(*action-name*/Outputs/Reports/*report-name-1*/**Format**)

(Erforderlich, falls enthalten[Reports](#github.configuration.reports))

Geben Sie das Dateiformat an, das Sie für Ihre Berichte verwenden. Mögliche Werte können sein wie folgt.
+ Für Testberichte:
  + Geben Sie für Cucumber JSON **Cucumber** (visueller Editor) oder `CUCUMBERJSON` (YAML-Editor) an.
  + Geben Sie für JUnit XML **JUnit**(visueller Editor) oder `JUNITXML` (YAML-Editor) an.
  + Geben Sie für NUnit XML **NUnit**(visueller Editor) oder `NUNITXML` (YAML-Editor) an.
  + Geben Sie für NUnit 3-XML **NUnit3**(visueller Editor) oder `NUNIT3XML` (YAML-Editor) an.
  + Geben Sie für Visual Studio TRX **Visual Studio TRX** (visueller Editor) oder `VISUALSTUDIOTRX` (YAML-Editor) an.
  + Geben Sie für TestNG XML **TestNG** (visueller Editor) oder `TESTNGXML` (YAML-Editor) an.
+ Für Berichte zur Codeabdeckung:
  + Geben Sie für Clover-XML **Clover** (visueller Editor) oder `CLOVERXML` (YAML-Editor) an.
  + Geben Sie für Cobertura XML **Cobertura (visueller Editor) oder (YAML-Editor**) an. `COBERTURAXML`
  + Geben Sie für JaCoCo XML **JaCoCo**(visueller Editor) oder `JACOCOXML` (YAML-Editor) an.
  + Geben Sie für SimpleCov JSON, das von [simplecov und nicht von simplecov-json](https://github.com/simplecov-ruby/simplecov) [generiert wurde, Simplecov](https://github.com/vicentllongo/simplecov-json) (visueller Editor) oder (**YAML-Editor**) an. `SIMPLECOV`
+ Für SCA-Berichte (Software Composition Analysis):
  + Geben Sie für SARIF **SARIF** (Visual Editor) oder `SARIFSCA` (YAML-Editor) an.

**Entsprechende Benutzeroberfläche: Gibt den tab/Reports/Manually configure reports/Add *report-name-1* Bericht/ Berichtstyp und das **Berichtsformat** aus**

## Configuration
<a name="github.configuration"></a>

(*action-name*/**Configuration**)

(Erforderlich) Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können. 

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## Steps
<a name="github.configuration.steps"></a>

(*action-name*/Configuration/**Steps**)

(Erforderlich) 

Geben Sie Ihren GitHub Aktionscode so an, wie er auf der Detailseite der Aktion im [GitHub Marketplace](https://github.com/marketplace) angezeigt wird. Fügen Sie den Code gemäß den folgenden Richtlinien hinzu:

1. Fügen Sie den Code aus dem `steps:` Abschnitt „ GitHub Aktion“ in den `Steps:` Abschnitt des CodeCatalyst Workflows ein. Der Code beginnt mit einem Bindestrich (-) und sieht wie folgt aus.

   GitHub Code zum Einfügen:

   ```
   - name: Lint Code Base
     uses: github/super-linter@v4
     env:
       VALIDATE_ALL_CODEBASE: false
       DEFAULT_BRANCH: master
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
   ```

1. Überprüfen Sie den Code, den Sie gerade eingefügt haben, und ändern Sie ihn nach Bedarf, sodass er den Standards entspricht CodeCatalyst. **Bei dem vorherigen Codeblock könnten Sie beispielsweise den Code entfernen und den fett *red italics* formatierten Code hinzufügen.**

   CodeCatalyst Workflow-Yaml:

   ```
   Steps:      
      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: mastermain
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
   ```

1. Für zusätzlichen Code, der in der GitHub Aktion enthalten ist, aber nicht im `steps:` Abschnitt vorhanden ist, fügen Sie ihn dem CodeCatalyst Workflow hinzu, indem Sie den Code CodeCatalyst -equivalent verwenden. Sie können den lesen[YAML-Workflow-Definition](workflow-reference.md), um einen Einblick zu erhalten, wie Sie Ihren GitHub Code portieren CodeCatalyst könnten. Detaillierte Migrationsschritte würden den Rahmen dieses Leitfadens sprengen.

Hier ist ein Beispiel für die Angabe von Dateipfaden in einer **GitHub Aktionsaktion**:

```
Steps:
  - name: Lint Code Base
    uses: github/super-linter@v4
    ...
  - run: cd /sources/WorkflowSource/MyFolder/  && cat file.txt
  - run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/  && cat file2.txt
```

Weitere Informationen zum Angeben von Dateipfaden finden Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md) und[Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**GitHub Aktionen**“ YAML

# Konfiguration von Compute- und Runtime-Images
<a name="workflows-working-compute"></a>

In einem CodeCatalyst Workflow können Sie das Image der Rechen- und Laufzeitumgebung angeben, das zur Ausführung von Workflow-Aktionen CodeCatalyst verwendet wird.

*Compute* bezieht sich auf die Rechenengine (die CPU, den Arbeitsspeicher und das Betriebssystem), die CodeCatalyst zur Ausführung von Workflow-Aktionen verwaltet und gewartet wird.

**Anmerkung**  
Wenn Compute als Eigenschaft des Workflows definiert ist, kann es nicht als Eigenschaft einer Aktion in diesem Workflow definiert werden. Ebenso kann Compute, wenn es als Eigenschaft einer Aktion definiert ist, nicht im Workflow definiert werden.

Ein *Laufzeitumgebungs-Image* ist ein Docker-Container, in dem Workflow-Aktionen CodeCatalyst ausgeführt werden. Der Docker-Container wird auf der von Ihnen ausgewählten Rechenplattform ausgeführt und umfasst ein Betriebssystem und zusätzliche Tools, die für eine Workflow-Aktion möglicherweise erforderlich sind, z. B. Node.js und .tar. AWS CLI

**Topics**
+ [

## Berechnungstypen
](#compute.types)
+ [

## Flotten berechnen
](#compute.fleets)
+ [

## Eigenschaften von On-Demand-Flotten
](#compute.on-demand)
+ [

## Eigenschaften von bereitgestellten Flotten
](#compute.provisioned-fleets)
+ [

# Eine bereitgestellte Flotte erstellen
](projects-create-compute-resource.md)
+ [

# Eine bereitgestellte Flotte bearbeiten
](edit-compute-resource.md)
+ [

# Löschen einer bereitgestellten Flotte
](delete-compute-resource.md)
+ [

# Zuweisen einer Flotte oder Rechenleistung zu einer Aktion
](workflows-assign-compute-resource.md)
+ [

# Rechenleistung für mehrere Aktionen gemeinsam nutzen
](compute-sharing.md)
+ [

# Angabe von Images für die Laufzeitumgebung
](build-images.md)

## Berechnungstypen
<a name="compute.types"></a>

CodeCatalyst bietet die folgenden Berechnungstypen:
+ Amazon EC2
+ AWS Lambda

Amazon EC2 bietet optimierte Flexibilität bei Aktionsläufen und Lambda bietet optimierte Startgeschwindigkeiten von Aktionen. Lambda unterstützt aufgrund einer geringeren Startlatenz schnellere Workflow-Aktionsausführungen. Mit Lambda können Sie grundlegende Workflows ausführen, mit denen serverlose Anwendungen mit gemeinsamen Laufzeiten erstellt, getestet und bereitgestellt werden können. Zu diesen Laufzeiten gehören Node.js, Python, Java, .NET und Go. Es gibt jedoch einige Anwendungsfälle, die Lambda nicht unterstützt, und wenn sie Sie betreffen, verwenden Sie den Amazon EC2 EC2-Compute-Typ:
+ Lambda unterstützt keine Laufzeitumgebungsbilder aus einer bestimmten Registrierung.
+ Lambda unterstützt keine Tools, für die Root-Rechte erforderlich sind. Verwenden Sie für Tools wie `yum` oder `rpm` den Datentyp Amazon EC2 oder andere Tools, für die keine Root-Rechte erforderlich sind.
+ Lambda unterstützt keine Docker-Builds oder -Läufe. Die folgenden Aktionen, die Docker-Images verwenden, werden nicht unterstützt: AWS CloudFormation Stack bereitstellen, In Amazon ECS bereitstellen, Veröffentlichen in Amazon S3, AWS CDK Bootstrap, AWS CDK Bereitstellen, AWS Lambda Aufrufen und Aktionen. GitHub Docker-basierte GitHub Aktionen, die innerhalb CodeCatalyst GitHub der Actions-Aktion ausgeführt werden, werden von Lambda Compute ebenfalls nicht unterstützt. Sie können Alternativen verwenden, für die keine Root-Rechte erforderlich sind, z. B. Podman.
+ Lambda unterstützt das Schreiben in Dateien außerhalb `/tmp` nicht. Bei der Konfiguration Ihrer Workflow-Aktionen können Sie Ihre Tools neu konfigurieren, um sie zu installieren oder in die Sie schreiben möchten. `/tmp` Wenn Sie über eine Build-Aktion verfügen, die installiert wird`npm`, stellen Sie sicher, dass Sie sie für die Installation unter konfigurieren. `/tmp`
+ Lambda unterstützt keine Laufzeiten von mehr als 15 Minuten.

## Flotten berechnen
<a name="compute.fleets"></a>

CodeCatalyst bietet die folgenden Rechenflotten an:
+ On-Demand-Flotten
+ Bereitgestellte Flotten

Bei On-Demand-Flotten stellt der Workflow beim Start einer Workflow-Aktion die benötigten Ressourcen bereit. Die Maschinen werden zerstört, wenn die Aktion abgeschlossen ist. Sie zahlen nur für die Anzahl der Minuten, für die Sie Ihre Aktionen ausführen. On-Demand-Flotten werden vollständig verwaltet und verfügen über automatische Skalierungsfunktionen zur Bewältigung von Nachfragespitzen.

CodeCatalyst bietet auch bereitgestellte Flotten an, die Maschinen enthalten, die von Amazon EC2 betrieben werden und von verwaltet werden. CodeCatalyst Bei bereitgestellten Flotten konfigurieren Sie eine Reihe von dedizierten Maschinen für die Ausführung Ihrer Workflow-Aktionen. Diese Maschinen bleiben im Leerlauf und sind bereit, Aktionen sofort zu verarbeiten. Mit bereitgestellten Flotten sind Ihre Maschinen immer in Betrieb und es fallen Kosten an, solange sie bereitgestellt werden.

**Um eine Flotte zu erstellen, zu aktualisieren oder zu löschen, benötigen Sie die Rolle eines **Space-Administrators oder eines Projektadministrators**.**

## Eigenschaften von On-Demand-Flotten
<a name="compute.on-demand"></a>

CodeCatalyst stellt die folgenden On-Demand-Flotten bereit:

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-working-compute.html)

**Anmerkung**  
Die Spezifikationen für On-Demand-Flotten variieren je nach Ihrer Abrechnungsstufe. Weitere Informationen finden Sie unter [ – Preise](https://codecatalyst.aws/explore/pricing).

Wenn keine Flotte ausgewählt ist, CodeCatalyst verwendet`Linux.x86-64.Large`.

## Eigenschaften von bereitgestellten Flotten
<a name="compute.provisioned-fleets"></a>

Eine bereitgestellte Flotte enthält die folgenden Eigenschaften: 

**Betriebssystem**  
Das Betriebssystem. Die folgenden Betriebssysteme sind verfügbar:  
+ Amazon Linux 2
+ Windows Server 2022
**Anmerkung**  
Windows-Flotten werden nur in der Build-Aktion unterstützt. Andere Aktionen unterstützen Windows derzeit nicht.

**Architektur**  
Die Prozessorarchitektur. Die folgenden Architekturen sind verfügbar:  
+ x86\$164
+ Arm64

**Typ der Maschine**  
Der Maschinentyp für jede Instanz. Die folgenden Maschinentypen sind verfügbar:      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-working-compute.html)

**Capacity (Kapazität)**  
Die anfängliche Anzahl der Maschinen, die der Flotte zugewiesen wurden. Sie definiert die Anzahl der Aktionen, die parallel ausgeführt werden können.

**Skalierungsmodus**  
Definiert das Verhalten, wenn die Anzahl der Aktionen die Flottenkapazität überschreitet.    
**Stellen Sie bei Bedarf zusätzliche Kapazität bereit**  
Zusätzliche Maschinen werden bei Bedarf eingerichtet, die bei Ausführung neuer Aktionen automatisch hochskaliert werden und nach Abschluss der Aktionen wieder auf die Basiskapazität herunterskaliert werden. Dadurch können zusätzliche Kosten entstehen, da Sie für jeden laufenden Computer minutengenau zahlen.  
**Warten Sie, bis zusätzliche Flottenkapazität verfügbar ist**  
Aktionsläufe werden in eine Warteschlange gestellt, bis eine Maschine verfügbar ist. Dadurch werden zusätzliche Kosten begrenzt, da keine zusätzlichen Maschinen zugewiesen werden.

# Eine bereitgestellte Flotte erstellen
<a name="projects-create-compute-resource"></a>

Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu erstellen.

**Anmerkung**  
Bereitgestellte Flotten werden nach 2 Wochen Inaktivität deaktiviert. Wenn sie erneut verwendet werden, werden sie automatisch reaktiviert. Diese Reaktivierung kann jedoch zu einer Latenz führen.

**Um eine bereitgestellte Flotte zu erstellen**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**

1. Wählen Sie **Create Provisioned Fleet** aus.

1. Geben Sie im Textfeld **Name der bereitgestellten Flotte** einen Namen für Ihre Flotte ein.

1. **Wählen Sie im Dropdownmenü Betriebssystem das Betriebssystem aus.**

1. Wählen Sie im Drop-down-Menü **Maschinentyp** den Maschinentyp für Ihre Maschine aus.

1. Geben Sie im Textfeld **Kapazität** die maximale Anzahl von Maschinen in der Flotte ein.

1. Wählen Sie **im Drop-down-Menü Skalierungsmodus** das gewünschte Überlaufverhalten aus. Weitere Informationen zu diesen Feldern finden Sie unter [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets).

1. Wählen Sie **Erstellen** aus.

Nachdem Sie die bereitgestellte Flotte erstellt haben, können Sie sie einer Aktion zuweisen. Weitere Informationen finden Sie unter [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md).

# Eine bereitgestellte Flotte bearbeiten
<a name="edit-compute-resource"></a>

Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu bearbeiten.

**Anmerkung**  
Bereitgestellte Flotten werden nach 2 Wochen Inaktivität deaktiviert. Wenn sie erneut verwendet werden, werden sie automatisch reaktiviert. Diese Reaktivierung kann jedoch zu einer Latenz führen.

**Um eine bereitgestellte Flotte zu bearbeiten**

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**

1. Wählen Sie in der Liste **Bereitgestellte Flotte** die Flotte aus, die Sie bearbeiten möchten.

1. Wählen Sie **Bearbeiten** aus.

1. Geben Sie im Textfeld **Kapazität** die maximale Anzahl von Maschinen in der Flotte ein.

1. Wählen Sie **im Drop-down-Menü Skalierungsmodus** das gewünschte Überlaufverhalten aus. Weitere Informationen zu diesen Feldern finden Sie unter [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets).

1. Wählen Sie **Speichern**.

# Löschen einer bereitgestellten Flotte
<a name="delete-compute-resource"></a>

Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu löschen.

**Um eine bereitgestellte Flotte zu löschen**
**Warnung**  
Bevor Sie eine bereitgestellte Flotte löschen, entfernen Sie sie aus allen Aktionen, indem Sie die `Fleet` Eigenschaft aus dem YAML-Code der Aktion löschen. Jede Aktion, die nach dem Löschen weiterhin auf eine bereitgestellte Flotte verweist, schlägt fehl, wenn die Aktion das nächste Mal ausgeführt wird.

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**

1. Wählen Sie in der Liste **Bereitgestellte Flotte** die Flotte aus, die Sie löschen möchten.

1. Wählen Sie **Löschen** aus.

1. Geben Sie ein**delete**, um den Löschvorgang zu bestätigen.

1. Wählen Sie **Löschen** aus.

# Zuweisen einer Flotte oder Rechenleistung zu einer Aktion
<a name="workflows-assign-compute-resource"></a>

Standardmäßig verwenden Workflow-Aktionen die `Linux.x86-64.Large` On-Demand-Flotte mit einem Amazon EC2 EC2-Berechnungstyp. Wenn Sie stattdessen eine bereitgestellte Flotte oder eine andere On-Demand-Flotte verwenden möchten`Linux.x86-64.2XLarge`, verwenden Sie beispielsweise die folgenden Anweisungen.

------
#### [ Visual ]

**Bevor Sie beginnen**
+ Wenn Sie eine bereitgestellte Flotte zuweisen möchten, müssen Sie zuerst die bereitgestellte Flotte erstellen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md).

**Um einer Aktion eine bereitgestellte Flotte oder einen anderen Flottentyp zuzuweisen**

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, der Sie Ihre bereitgestellte Flotte oder Ihren neuen Flottentyp zuweisen möchten.

1. Wählen Sie die Registerkarte **Konfiguration** aus.

1. Gehen **Sie in Compute Fleet** wie folgt vor:

   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`

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 ]

**Bevor Sie beginnen**
+ Wenn Sie eine bereitgestellte Flotte zuweisen möchten, müssen Sie zuerst die bereitgestellte Flotte erstellen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md).

**Um einer Aktion eine bereitgestellte Flotte oder einen anderen Flottentyp zuzuweisen**

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 die Aktion, der Sie Ihre bereitgestellte Flotte oder Ihren neuen Flottentyp zuweisen möchten.

1. Fügen Sie in der Aktion eine `Compute` Eigenschaft hinzu und legen Sie `Fleet` sie auf den Namen Ihrer Flotte oder Ihres On-Demand-Flottentyps fest. Weitere Informationen finden Sie in der Beschreibung der `Fleet` Immobilie im Abschnitt [Aktionen erstellen und testen YAML](build-action-ref.md) Für Ihre Aktion.

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.

------

# Rechenleistung für mehrere Aktionen gemeinsam nutzen
<a name="compute-sharing"></a>

Standardmäßig werden Aktionen in einem Workflow auf separaten Instanzen in einer [Flotte](workflows-working-compute.md#compute.fleets) ausgeführt. Dieses Verhalten sorgt für isolierte und vorhersehbare Aktionen in Bezug auf den Status der Eingaben. Das Standardverhalten erfordert eine explizite Konfiguration, um Kontext wie Dateien und Variablen zwischen Aktionen gemeinsam zu nutzen. 

Compute Sharing ist eine Funktion, mit der Sie alle Aktionen in einem Workflow auf derselben Instanz ausführen können. Die Nutzung von Compute Sharing kann zu schnelleren Workflow-Laufzeiten führen, da weniger Zeit für die Bereitstellung von Instanzen aufgewendet wird. Sie können Dateien (Artefakte) auch ohne zusätzliche Workflow-Konfiguration zwischen Aktionen gemeinsam nutzen.

Wenn ein Workflow mithilfe von Compute Sharing ausgeführt wird, ist eine Instanz in der Standardflotte oder in der angegebenen Flotte für die Dauer aller Aktionen in diesem Workflow reserviert. Wenn der Workflow-Lauf abgeschlossen ist, wird die Instanzreservierung freigegeben.

**Topics**
+ [

## Mehrere Aktionen auf gemeinsam genutztem Computer ausführen
](#how-to-compute-share)
+ [

## Überlegungen zur gemeinsamen Nutzung von Rechenleistung
](#compare-compute-sharing)
+ [

## Compute Sharing einschalten
](#compute-sharing-steps)
+ [

## Beispiele
](#compute-sharing-examples)

## Mehrere Aktionen auf gemeinsam genutztem Computer ausführen
<a name="how-to-compute-share"></a>

Sie können das `Compute` Attribut in der Definition YAML auf Workflow-Ebene verwenden, um sowohl die Flotten- als auch die Compute-Sharing-Eigenschaften von Aktionen anzugeben. Sie können Computing-Eigenschaften auch mit dem Visual Editor in CodeCatalyst konfigurieren. Um eine Flotte anzugeben, legen Sie den Namen einer vorhandenen Flotte fest, legen Sie den Berechnungstyp auf **EC2**fest und aktivieren Sie die gemeinsame Nutzung von Rechenressourcen.

**Anmerkung**  
Compute Sharing wird nur unterstützt, wenn der Compute-Typ auf eingestellt ist **EC2**, und sie wird für das Betriebssystem Windows Server 2022 nicht unterstützt. Weitere Informationen zu Rechenflotten, Compute-Typen und Eigenschaften finden Sie unter[Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).

**Anmerkung**  
Wenn Sie das kostenlose Kontingent nutzen und die `Linux.x86-64.2XLarge` Flotte `Linux.x86-64.XLarge` oder manuell in der Workflow-Definition YAML angeben, wird die Aktion trotzdem auf der Standardflotte () `Linux.x86-64.Large` ausgeführt. Weitere Informationen zur Verfügbarkeit von Rechenleistung und zu den Preisen finden Sie in der [Tabelle mit den Tarifoptionen](https://codecatalyst.aws/explore/pricing). 

Wenn Compute Sharing aktiviert ist, wird der Ordner, der die Workflow-Quelle enthält, automatisch in alle Aktionen kopiert. Sie müssen keine Ausgabeartefakte konfigurieren und sie in einer Workflow-Definition (YAML-Datei) nicht als Eingabeartefakte referenzieren. Als Workflow-Autor müssen Sie Umgebungsvariablen mithilfe von Eingaben und Ausgaben verknüpfen, genau wie Sie es ohne Compute Sharing tun würden. Wenn Sie Ordner für Aktionen außerhalb der Workflow-Quelle gemeinsam nutzen möchten, sollten Sie das Zwischenspeichern von Dateien in Betracht ziehen. Weitere Informationen erhalten Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md) und [Zwischenspeichern von Dateien zwischen Workflow-Läufen](workflows-caching.md).

Das Quell-Repository, in dem sich Ihre Workflow-Definitionsdatei befindet, ist anhand der Bezeichnung gekennzeichnet. `WorkflowSource` Wenn Sie Compute Sharing verwenden, wird die Workflow-Quelle in der ersten Aktion heruntergeladen, die darauf verweist, und automatisch für nachfolgende Aktionen im Workflow-Lauf zur Verfügung gestellt. Alle Änderungen, die durch eine Aktion an dem Ordner, der die Workflow-Quelle enthält, vorgenommen werden, z. B. durch Hinzufügen, Ändern oder Entfernen von Dateien, sind auch in den nachfolgenden Aktionen im Workflow sichtbar. Sie können in jeder Ihrer Workflow-Aktionen auf Dateien verweisen, die sich im Workflow-Quellordner befinden, genauso wie Sie es ohne Compute Sharing tun können. Weitere Informationen finden Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md).

**Anmerkung**  
Compute-Sharing-Workflows müssen eine strikte Reihenfolge von Aktionen angeben, sodass parallel Aktionen nicht festgelegt werden können. Ausgabeartefakte können zwar bei jeder Aktion in der Sequenz konfiguriert werden, Eingabeartefakte werden jedoch nicht unterstützt.

## Überlegungen zur gemeinsamen Nutzung von Rechenleistung
<a name="compare-compute-sharing"></a>

Sie können Workflows mit Compute Sharing ausführen, um Workflow-Ausführungen zu beschleunigen und den Kontext zwischen Aktionen in einem Workflow, die dieselbe Instanz verwenden, gemeinsam zu nutzen. Beachten Sie Folgendes, um festzustellen, ob die Nutzung von Compute Sharing für Ihr Szenario geeignet ist:


|   | Compute-Sharing | Ohne gemeinsame Nutzung von Rechenleistung | 
| --- | --- | --- | 
|  Datenverarbeitung  |  Amazon EC2  |  Amazon EC2, AWS Lambda  | 
|  Bereitstellung von Instanzen  |  Aktionen werden auf derselben Instanz ausgeführt  |  Aktionen werden auf separaten Instanzen ausgeführt  | 
|  Betriebssystem  |  Amazon Linux 2  |  Amazon Linux 2, Windows Server 2022 (nur Build-Aktion)  | 
|  Dateien referenzieren  |  `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/`  |  `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/`  | 
|  Workflow-Struktur  |  Aktionen können nur sequentiell ausgeführt werden  |  Aktionen können parallel ausgeführt werden  | 
|  Zugreifen auf Daten über Workflow-Aktionen hinweg  |  Greifen Sie auf die zwischengespeicherte Workflow-Quelle zu () `WorkflowSource`  |  Greifen Sie auf Ausgaben gemeinsam genutzter Artefakte zu (erfordert zusätzliche Konfiguration)  | 

## Compute Sharing einschalten
<a name="compute-sharing-steps"></a>

Gehen Sie wie folgt vor, um Compute Sharing für einen Workflow zu aktivieren.

------
#### [ Visual ]

**Um Compute Sharing mit dem Visual Editor zu aktivieren**

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.

1. Wählen Sie **Edit** (Bearbeiten) aus.

1. Wählen Sie **Visual**.

1. Wählen Sie **Workflow-Eigenschaften**.

1. Wählen Sie aus dem Dropdownmenü **Berechnungstyp** die Option **EC2**.

1. (Optional) Wählen Sie im Dropdownmenü **Compute fleet — optional** eine Flotte aus, die Sie für die Ausführung von Workflow-Aktionen verwenden möchten. Sie können eine On-Demand-Flotte wählen oder eine bereitgestellte Flotte erstellen und auswählen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md) und [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md) 

1. Schalten Sie den Schalter um, um Compute Sharing zu aktivieren und die Aktionen im Workflow auf derselben Flotte ausführen zu lassen.

1. (Optional) Wählen Sie den Ausführungsmodus für den Workflow. Weitere Informationen finden Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md).

1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.

------
#### [ YAML ]

**Um Compute Sharing mit dem YAML-Editor zu aktivieren**

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.

1. Wählen Sie **Edit** (Bearbeiten) aus.

1. Wählen Sie **YAML.**

1. Aktivieren Sie Compute Sharing und setzen Sie das `SharedInstance` Feld auf `TRUE` und `Type` bis`EC2`. Stellen `Fleet` Sie eine Rechenflotte ein, die Sie zum Ausführen von Workflow-Aktionen verwenden möchten. Sie können eine On-Demand-Flotte wählen oder eine bereitgestellte Flotte erstellen und auswählen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md) und [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md)

   Fügen Sie in einem Workflow-YAML Code hinzu, der dem folgenden ähnelt:

   ```
     Name: MyWorkflow
     SchemaVersion: "1.0"
     Compute: # Define compute configuration.
       Type: EC2
       Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet.
       SharedInstance: true # Turn on compute sharing. Default is False.
     Actions:
       BuildFirst:
         Identifier: aws/build@v1
         Inputs:
           Sources:
             - WorkflowSource
         Configuration:
           Steps:
             - Run: ...
             ...
   ```

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.

------

## Beispiele
<a name="compute-sharing-examples"></a>

**Topics**
+ [

### Beispiel: Amazon S3 Publish
](#compute-share-s3)

### Beispiel: Amazon S3 Publish
<a name="compute-share-s3"></a>

Die folgenden Workflow-Beispiele zeigen, wie Sie die Amazon Amazon S3 S3-Aktion „Veröffentlichen“ auf zwei Arten ausführen können: zuerst mithilfe von Eingabeartefakten und dann mithilfe von Compute Sharing. Bei Compute Sharing werden die Eingabeartefakte nicht benötigt, da Sie auf die zwischengespeicherten `WorkflowSource` zugreifen können. Darüber hinaus wird das Ausgabeartefakt in der Build-Aktion nicht mehr benötigt. Die S3-Aktion „Veröffentlichen“ ist so konfiguriert, dass sie die explizite `DependsOn` Eigenschaft zur Verwaltung sequentieller Aktionen verwendet. Die Build-Aktion muss erfolgreich ausgeführt werden, damit die S3-Aktion „Veröffentlichen“ ausgeführt werden kann.
+ Ohne Compute-Sharing müssen Sie Eingabeartefakte verwenden und die Ausgaben mit nachfolgenden Aktionen teilen:

  ```
  Name: S3PublishUsingInputArtifact
  SchemaVersion: "1.0"
  Actions:
    Build:
      Identifier: aws/build@v1
      Outputs:
        Artifacts:
          - Name: ArtifactToPublish
            Files: [output.zip]
      Inputs:
        Sources:
          - WorkflowSource
      Configuration:
        Steps:
          - Run: ./build.sh # Build script that generates output.zip
    PublishToS3:
      Identifier: aws/s3-publish@v1
      Inputs:
        Artifacts:
        - ArtifactToPublish
      Environment:
        Connections:
          - Role: codecatalyst-deployment-role
            Name: dev-deployment-role
        Name: dev-connection
      Configuration:
        SourcePath: output.zip
        DestinationBucketName: amzn-s3-demo-bucket
  ```
+ Wenn Sie Compute Sharing mit der Einstellung `SharedInstance` auf verwenden`TRUE`, können Sie mehrere Aktionen auf derselben Instanz ausführen und Artefakte gemeinsam nutzen, indem Sie eine einzige Workflow-Quelle angeben. Eingabeartefakte sind nicht erforderlich und können nicht angegeben werden:

  ```
  Name: S3PublishUsingComputeSharing
  SchemaVersion: "1.0"
  Compute: 
    Type: EC2
    Fleet: dev-fleet
    SharedInstance: TRUE
  Actions:
    Build:
      Identifier: aws/build@v1
      Inputs:
        Sources:
          - WorkflowSource
      Configuration:
        Steps:
          - Run: ./build.sh # Build script that generates output.zip
    PublishToS3:
      Identifier: aws/s3-publish@v1
      DependsOn: 
        - Build
      Environment:
        Connections:
          - Role: codecatalyst-deployment-role
            Name: dev-deployment-role
        Name: dev-connection
      Configuration:
        SourcePath: output.zip
        DestinationBucketName: amzn-s3-demo-bucket
  ```

# Angabe von Images für die Laufzeitumgebung
<a name="build-images"></a>

Ein *Laufzeitumgebungs-Image* ist ein Docker-Container, in dem Workflow-Aktionen CodeCatalyst ausgeführt werden. Der Docker-Container wird auf der von Ihnen ausgewählten Rechenplattform ausgeführt und umfasst ein Betriebssystem und zusätzliche Tools, die für eine Workflow-Aktion möglicherweise erforderlich sind, z. B. Node.js und .tar. AWS CLI

Standardmäßig werden Workflow-Aktionen auf einem der [aktiven Images](#build-curated-images) ausgeführt, die von bereitgestellt und verwaltet werden. CodeCatalyst Nur Build- und Testaktionen unterstützen benutzerdefinierte Images. Weitere Informationen finden Sie unter [Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](#build-images-specify).

**Topics**
+ [

## Aktive Bilder
](#build-curated-images)
+ [

## Was ist, wenn ein aktives Bild nicht die Tools enthält, die ich benötige?
](#build-images-more-tools)
+ [

## Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion
](#build-images-specify)
+ [

## Beispiele
](#workflows-working-custom-image-ex)

## Aktive Bilder
<a name="build-curated-images"></a>

*Aktive Images* sind Runtime-Umgebungs-Images, die vollständig von Tools unterstützt werden CodeCatalyst und vorinstallierte Tools enthalten. Derzeit gibt es zwei Gruppen aktiver Images: eines wurde im März 2024 veröffentlicht, das andere wurde im November 2022 veröffentlicht.

Ob für eine Aktion ein Bild vom März 2024 oder vom November 2022 verwendet wird, hängt von der Aktion ab:
+ Build- und Testaktionen, die am oder nach dem 26. März 2024 zu einem Workflow hinzugefügt werden, enthalten in ihrer YAML-Definition einen `Container` Abschnitt, der explizit ein [Bild vom März 2024](#build.default-image) spezifiziert. Sie können den `Container` Abschnitt optional entfernen, um zum Bild vom [November 2022](#build.previous-image) zurückzukehren.
+ Build- und Testaktionen, die vor dem 26. März 2024 zu einem Workflow hinzugefügt wurden, enthalten *keinen* `Container` Abschnitt in ihrer YAML-Definition und verwenden daher ein Image [vom November 2022](#build.previous-image). Sie können das Image vom November 2022 behalten oder es aktualisieren. Um das Image zu aktualisieren, öffnen Sie die Aktion im Visual Editor, wählen Sie die Registerkarte **Konfiguration** und wählen Sie dann das Bild vom März 2024 aus der Dropdownliste **Docker-Image der Laufzeitumgebung** aus. Durch diese Auswahl wird der YAML-Definition der Aktion ein `Container` Abschnitt hinzugefügt, der mit dem entsprechenden Bild vom März 2024 gefüllt ist.
+ Für alle anderen Aktionen wird entweder ein Bild [vom November 2022 oder ein Bild](#build.previous-image) [vom März 2024](#build.default-image) verwendet. Weitere Informationen finden Sie in der Dokumentation der Aktion. 

**Topics**
+ [

### Bilder vom März 2024
](#build.default-image)
+ [

### Bilder vom November 2022
](#build.previous-image)

### Bilder vom März 2024
<a name="build.default-image"></a>

Die Bilder vom März 2024 sind die neuesten Bilder, die von bereitgestellt wurden CodeCatalyst. Pro type/fleet Rechenkombination gibt es ein Bild vom März 2024.

Die folgende Tabelle zeigt die Tools, die auf jedem Image vom März 2024 installiert sind.


**Image-Tools vom März 2024**  

| Tool | CodeCatalyst Amazon EC2 für Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda für Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 für Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda für Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` | 
| --- | --- | --- | --- | --- | 
| AWS CLI | 2.15.17 | 2,15,17 | 2,15,17 | 2,15,17 | 
| AWS Copilot CLI | 1.32.1 | 1,32,1 | 1,32,1 | 1,32,1 | 
| Docker | 24,9 | – | 24,9 | – | 
| Docker Compose | 2.23.3 | – | 2.23.3 | – | 
| Git | 2,43,0 | 2,43,0 | 2,43,0 | 2,43,0 | 
| Go | 1,21,5 | 1,21,5 | 1,21,5 | 1,21,5 | 
| Gradle | 8,5 | 8,5 | 8,5 | 8,5 | 
| Java | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 | 
| Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 | 
| Node.js | 18,19,0 | 18,19,0 | 18,19,0 | 18,19,0 | 
| NPM | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 | 
| Python | 3.9,18 | 3.9,18 | 3.9,18 | 3.9,18 | 
| Python3 | 3.11,6 | 3.11.6 | 3.11.6 | 3.11.6 | 
| pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 | 
| .NET | 8.0.100 | 8,0,100 | 8,0,100 | 8,0,100 | 

### Bilder vom November 2022
<a name="build.previous-image"></a>

Pro type/fleet Rechenkombination gibt es ein Bild vom November 2022. Es ist auch ein Windows-Image vom November 2022 mit der Build-Aktion verfügbar, wenn Sie eine [bereitgestellte Flotte](workflows-working-compute.md#compute.fleets) konfiguriert haben.

In der folgenden Tabelle sind die Tools aufgeführt, die auf den einzelnen Images vom November 2022 installiert sind.


**Image-Tools für November 2022**  

| Tool | CodeCatalyst Amazon EC2 für Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda für Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 für Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda für Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 für Windows x86\$164 - `CodeCatalystWindows_x86_64:2022_11` | 
| --- | --- | --- | --- | --- | --- | 
| AWS CLI | 2.15,17 | 2,15,17 | 2,15,17 | 2,15,17 | 2.13,19 | 
| AWS Copilot CLI | 0.6.0 | 0.6.0 | – | – | 1.30.1 | 
| Docker | 23,01 | – | 23,0,1 | – | – | 
| Docker Compose | 2.16.0 | – | 2.16.0 | – | – | 
| Git | 2.40.0 | 2.40.0 | 2,39,2 | 2,39,2 | 2,42,0 | 
| Go | 1.20.2 | 1.20.2 | 1,20,1 | 1,20,1 | 1,19 | 
| Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 | 
| Java | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 | 
| Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 | 
| Node.js | 16.20,2 | 16,20,2 | 16,19,1 | 16,14,2 | 16,20,0 | 
| NPM | 8.19,4 | 8.19,4 | 8.19,3 | 8.5.0 | 8.19,4 | 
| Python | 3.9,15 | 2.7,18 | 3.11.2 | 2.7.18 | 3.9.13 | 
| Python3 | – | 3.9,15 | – | 3.11.2 | – | 
| pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 | 
| .NET | 6,0,407 | 6,0,407 | 6,0,406 | 6,0,406 | 6,0,414 | 

## Was ist, wenn ein aktives Bild nicht die Tools enthält, die ich benötige?
<a name="build-images-more-tools"></a>

Wenn keines der von Ihnen bereitgestellten [aktiven Bilder](#build-curated-images) die Tools CodeCatalyst enthält, die Sie benötigen, haben Sie mehrere Optionen:
+ Sie können ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen, das die erforderlichen Tools enthält. Weitere Informationen finden Sie unter [Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](#build-images-specify).
**Anmerkung**  
 Wenn Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen möchten, stellen Sie sicher, dass in Ihrem benutzerdefinierten Image Git installiert ist. 
+ Sie können die Build- oder Testaktion Ihres Workflows die Tools installieren lassen, die Sie benötigen.

  Sie könnten beispielsweise die folgenden Anweisungen in den `Steps` Abschnitt des YAML-Codes der Build- oder Testaktion aufnehmen:

  ```
  Configuration:
    Steps:
      - Run: ./setup-script
  ```

  Die *setup-script* Anweisung würde dann das folgende Skript ausführen, um den Node-Paketmanager (npm) zu installieren:

  ```
  #!/usr/bin/env bash
  echo "Setting up environment"
  
  touch ~/.bashrc
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
  source ~/.bashrc 
  nvm install v16.1.0
  source ~/.bashrc
  ```

  Weitere Hinweise zur Build-Aktion YAML finden Sie unter. [Aktionen erstellen und testen YAML](build-action-ref.md)

## Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion
<a name="build-images-specify"></a>

Wenn Sie kein von bereitgestelltes [Active-Image](#build-curated-images) verwenden möchten CodeCatalyst, können Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen. Wenn du ein benutzerdefiniertes Image bereitstellen möchtest, stelle sicher, dass Git darin installiert ist. Das Image kann sich in Docker Hub, Amazon Elastic Container Registry oder einem beliebigen öffentlichen Repository befinden.

Informationen zum Erstellen eines benutzerdefinierten Docker-Images finden Sie unter [Containerisieren einer Anwendung](https://docs.docker.com/get-started/02_our_app/) in der Docker-Dokumentation.

Verwenden Sie die folgenden Anweisungen, um Ihr benutzerdefiniertes Docker-Image für die Laufzeitumgebung einer Aktion zuzuweisen. Nachdem Sie ein Image angegeben haben, CodeCatalyst wird es auf Ihrer Rechenplattform bereitgestellt, wenn die Aktion gestartet wird.

**Anmerkung**  
Die folgenden Aktionen unterstützen keine Docker-Images für benutzerdefinierte Laufzeitumgebungen: **Deploy CloudFormation Stack**, **Deploy to ECS** und **GitHub Actions**. Docker-Images für benutzerdefinierte Laufzeitumgebungen unterstützen auch nicht den Compute-Typ **Lambda**.

------
#### [ Visual ]

**So weisen Sie mit dem Visual Editor ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zu**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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, die Ihr benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden soll.

1. Wählen Sie die Registerkarte **Konfiguration** aus.

1. Füllen Sie unten die folgenden Felder aus.

   **Docker-Image für die Laufzeitumgebung — optional**

   Geben Sie die Registrierung an, in der Ihr Image gespeichert ist. Gültige Werte sind:
   + `CODECATALYST`(YAML-Editor)

     Das Bild wird in der CodeCatalyst Registrierung gespeichert.
   + **Docker Hub** (visueller Editor) oder `DockerHub` (YAML-Editor)

     Das Bild wird in der Docker Hub-Image-Registry gespeichert.
   + **Andere Registrierung** (visueller Editor) oder `Other` (YAML-Editor)

     Das Bild wird in einer benutzerdefinierten Bildregistrierung gespeichert. Jede öffentlich verfügbare Registrierung kann verwendet werden.
   + **Amazon Elastic Container Registry** (visueller Editor) oder `ECR` (YAML-Editor)

     Das Bild wird in einem Image-Repository der Amazon Elastic Container Registry gespeichert. Um ein Bild in einem Amazon ECR-Repository zu verwenden, benötigt diese Aktion Zugriff auf Amazon ECR. Um diesen Zugriff zu aktivieren, müssen Sie eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) erstellen, die die folgenden Berechtigungen und eine benutzerdefinierte Vertrauensrichtlinie umfasst. (Sie können eine bestehende Rolle so ändern, dass sie die Berechtigungen und die Richtlinie einbezieht, wenn Sie möchten.)

     Die IAM-Rolle muss die folgenden Berechtigungen in ihrer Rollenrichtlinie enthalten:
     + `ecr:BatchCheckLayerAvailability`
     + `ecr:BatchGetImage`
     + `ecr:GetAuthorizationToken`
     + `ecr:GetDownloadUrlForLayer`

     Die IAM-Rolle muss die folgende benutzerdefinierte Vertrauensrichtlinie enthalten:

     Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) im *IAM-Benutzerhandbuch*.

     Nachdem Sie die Rolle erstellt haben, müssen Sie sie der Aktion über eine Umgebung zuweisen. Weitere Informationen finden Sie unter [Eine Umgebung mit einer Aktion verknüpfen](deploy-environments-add-app-to-environment.md).

   **ECR-Bild-URL****, **Docker Hub-Bild oder Bild-URL****

   Geben Sie eines der folgenden Elemente an:
   + Wenn Sie eine `CODECATALYST` Registrierung verwenden, legen Sie für das Image eines der folgenden [aktiven](#build-curated-images) Images fest:
     + `CodeCatalystLinux_x86_64:2024_03`
     + `CodeCatalystLinux_x86_64:2022_11`
     + `CodeCatalystLinux_Arm64:2024_03`
     + `CodeCatalystLinux_Arm64:2022_11`
     + `CodeCatalystLinuxLambda_x86_64:2024_03`
     + `CodeCatalystLinuxLambda_x86_64:2022_11`
     + `CodeCatalystLinuxLambda_Arm64:2024_03`
     + `CodeCatalystLinuxLambda_Arm64:2022_11`
     + `CodeCatalystWindows_x86_64:2022_11`
   + Wenn Sie eine Docker Hub-Registry verwenden, legen Sie für das Image den Namen des Docker Hub-Images und das optionale Tag fest.

     Beispiel: `postgres:latest`
   + Wenn Sie eine Amazon ECR-Registrierung verwenden, setzen Sie das Bild auf die Amazon ECR-Registrierungs-URI.

     Beispiel: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
   + Wenn Sie eine benutzerdefinierte Registrierung verwenden, setzen Sie das Bild auf den Wert, der von der benutzerdefinierten Registrierung erwartet wird.

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 mit dem YAML-Editor ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zuzuweisen**

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 die Aktion, der Sie ein Docker-Image für die Laufzeitumgebung zuweisen möchten.

1. Fügen Sie in der Aktion einen `Container` Abschnitt und die zugrunde liegenden `Registry` `Image` Eigenschaften hinzu. Weitere Informationen finden Sie in der Beschreibung der `Container` `Registry` und den `Image` Eigenschaften in der [Aktionen](workflow-reference.md#actions-reference) Für Ihre Aktion.

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

------

## Beispiele
<a name="workflows-working-custom-image-ex"></a>

Die folgenden Beispiele zeigen, wie Sie einer Aktion in der Workflow-Definitionsdatei ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zuweisen.

**Topics**
+ [

### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Amazon ECR hinzuzufügen
](#workflows-working-custom-image-ex-ecr-node18)
+ [

### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen
](#workflows-working-custom-image-ex-docker-node18)

### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Amazon ECR hinzuzufügen
<a name="workflows-working-custom-image-ex-ecr-node18"></a>

Das folgende Beispiel zeigt, wie Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden, um Unterstützung für Node.js 18 mit [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux) hinzuzufügen.

```
Configuration:
  Container:
    Registry: ECR
    Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```

### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen
<a name="workflows-working-custom-image-ex-docker-node18"></a>

[Das folgende Beispiel zeigt, wie Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen.](https://hub.docker.com/_/node)

```
Configuration:
  Container:
    Registry: DockerHub
    Image: node:18.18.2
```

# Quell-Repositorys mit Workflows verbinden
<a name="workflows-sources"></a>

Eine *Quelle*, auch *Eingabequelle* genannt, ist ein Quell-Repository, mit dem eine [Workflow-Aktion](workflows-actions.md) eine Verbindung herstellt, um die Dateien abzurufen, die sie für ihre Operationen benötigt. Beispielsweise kann eine Workflow-Aktion eine Verbindung zu einem Quell-Repository herstellen, um Anwendungsquelldateien für die Erstellung einer Anwendung abzurufen.

CodeCatalyst Workflows unterstützen die folgenden Quellen:
+ CodeCatalyst Quell-Repositorys — Weitere Informationen finden Sie unter[Speichern Sie Code mit Quell-Repositorys in und arbeiten Sie gemeinsam daran CodeCatalystSpeichern Sie Code mit Quell-Repositorys und arbeiten Sie gemeinsam daran](source.md).
+ GitHub Repositorys, Bitbucket-Repositorys und GitLab Projekt-Repositorys — Weitere Informationen findest du unter. [Fügen Sie Funktionen zu Projekten mit Erweiterungen hinzu in CodeCatalystFügen Sie Funktionen zu Projekten mit Erweiterungen hinzu](extensions.md)

**Topics**
+ [

# Quell-Repository einer Workflow-Datei angeben
](workflows-sources-specify-workflow-def.md)
+ [

# Quell-Repository einer Workflow-Aktion angeben
](workflows-sources-specify-action.md)
+ [

# Quell-Repository-Dateien referenzieren
](workflows-sources-reference-files.md)
+ [

# Variablen BranchName '' und CommitId ''
](workflows-sources-variables.md)

# Quell-Repository einer Workflow-Datei angeben
<a name="workflows-sources-specify-workflow-def"></a>

Verwenden Sie die folgenden Anweisungen, um das CodeCatalyst Quell-Repository anzugeben, in dem Sie Ihre Workflow-Definitionsdatei speichern möchten. Wenn du lieber ein GitHub Repository, Bitbucket-Repository oder GitLab Projekt-Repository angeben möchtest, siehe stattdessen[Fügen Sie Funktionen zu Projekten mit Erweiterungen hinzu in CodeCatalystFügen Sie Funktionen zu Projekten mit Erweiterungen hinzu](extensions.md).

Das Quell-Repository, in dem sich deine Workflow-Definitionsdatei befindet, ist durch das Label, gekennzeichnet. `WorkflowSource`

**Anmerkung**  
Sie geben das Quell-Repository an, in dem sich Ihre Workflow-Definitionsdatei befindet, wenn Sie Ihre Workflow-Definitionsdatei zum ersten Mal übertragen. Nach diesem Commit sind das Repository und die Workflow-Definitionsdatei dauerhaft miteinander verknüpft. Die einzige Möglichkeit, das Repository nach dem ersten Commit zu ändern, besteht darin, den Workflow in einem anderen Repository neu zu erstellen.

**Um das Quell-Repository anzugeben, in dem die Workflow-Definitionsdatei gespeichert werden soll**

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 **Workflow erstellen** und erstellen Sie den Workflow. Weitere Informationen finden Sie unter [Einen Workflow erstellen](workflows-create-workflow.md).

   Während der Workflow-Erstellung können Sie das CodeCatalyst Repository, den Zweig und den Ordner angeben, in dem Sie Ihre Workflow-Definitionsdatei speichern möchten.

# Quell-Repository einer Workflow-Aktion angeben
<a name="workflows-sources-specify-action"></a>

Verwenden Sie die folgenden Anweisungen, um ein Quell-Repository anzugeben, das mit einer Workflow-Aktion verwendet werden soll. Beim Start bündelt die Aktion die Dateien im konfigurierten Quell-Repository zu einem Artefakt, lädt das Artefakt in das [Docker-Image der Laufzeitumgebung](build-images.md) herunter, in dem die Aktion ausgeführt wird, und schließt dann die Verarbeitung mit den heruntergeladenen Dateien ab.

**Anmerkung**  
Derzeit können Sie innerhalb einer Workflow-Aktion nur ein Quell-Repository angeben, nämlich das Quell-Repository, in dem sich die Workflow-Definitionsdatei befindet (im `.codecatalyst/workflows/` Verzeichnis oder einem seiner Unterverzeichnisse). Dieses Quell-Repository wird durch das Label dargestellt. `WorkflowSource`

------
#### [ Visual ]

**Um das Quell-Repository anzugeben, das eine Aktion verwenden soll (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 die Aktion aus, für die Sie die Quelle angeben möchten.

1. Wählen Sie **Eingaben**.

1. Gehen Sie **unter Quellen — optional** wie folgt vor:

   Geben Sie die Labels an, die die Quell-Repositorys repräsentieren, die für die Aktion benötigt werden. Derzeit wird nur die Bezeichnung, die das Quell-Repository darstellt`WorkflowSource`, in dem Ihre Workflow-Definitionsdatei gespeichert ist, unterstützt.

   Wenn Sie eine Quelle weglassen, müssen Sie mindestens ein Eingabeartefakt unter angeben. `action-name/Inputs/Artifacts`

   Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.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 das Quell-Repository anzugeben, das eine Aktion verwenden soll (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 in einer Aktion Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
    Inputs:
      Sources:
        - WorkflowSource
   ```

   Weitere Informationen finden Sie in der Beschreibung der `Sources` Eigenschaft unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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

------

# Quell-Repository-Dateien referenzieren
<a name="workflows-sources-reference-files"></a>

Wenn Sie über Dateien verfügen, die sich in einem Quell-Repository befinden, und Sie in einer Ihrer Workflow-Aktionen auf diese Dateien verweisen müssen, gehen Sie wie folgt vor.

**Anmerkung**  
Siehe auch [Referenzieren von Dateien in einem Artefakt](workflows-working-artifacts-refer-files.md).

**Um auf eine Datei zu verweisen, die in einem Quell-Repository gespeichert ist**
+ Fügen Sie in der Aktion, in der Sie auf eine Datei verweisen möchten, Code hinzu, der dem folgenden ähnelt:

  ```
  Actions:
    My-action:
      Inputs:
        Sources:
          - WorkflowSource
        Configuration:
          Steps:
          - run: cd my-app && cat file1.jar
  ```

  Im vorherigen Code sucht die Aktion im Verzeichnis im `my-app` Stammverzeichnis des `WorkflowSource` Quell-Repositorys nach der `file1.jar` Datei und zeigt sie an.

# Variablen BranchName '' und CommitId ''
<a name="workflows-sources-variables"></a>

Die CodeCatalyst Quelle erzeugt `BranchName` und legt `CommitId` Variablen fest, wenn Ihr Workflow ausgeführt wird. Diese werden als *vordefinierte Variablen* bezeichnet. In der folgenden Tabelle finden Sie Informationen zu diesen Variablen.

Informationen zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  CommitId  |  Die Commit-ID, die den Status des Repositorys zum Zeitpunkt des Starts der Workflow-Ausführung darstellt. Beispiel: `example3819261db00a3ab59468c8b` Weitere Informationen finden Sie auch unter: [Beispiel: Verweisen auf die vordefinierte CommitId Variable ""](workflows-predefined-examples.md#workflows-working-with-variables-ex-refer-action).  | 
|  BranchName  |  Der Name des Branches, für den die Workflow-Ausführung gestartet wurde. Beispiele: `main`, `feature/branch`, `test-LiJuan`. Weitere Informationen finden Sie auch unter: [Beispiel: Verweisen auf die vordefinierte BranchName Variable ""](workflows-predefined-examples.md#workflows-working-with-variables-ex-branch).  | 

# Paket-Repositorys mit Workflows verbinden
<a name="workflows-packages"></a>

Ein *Paket* ist ein Paket, das sowohl Software als auch die Metadaten enthält, die für die Installation der Software und die Auflösung aller Abhängigkeiten erforderlich sind. CodeCatalyst unterstützt das npm-Paketformat.

Ein Paket besteht aus:
+ Ein Name (`webpack`ist zum Beispiel der Name eines beliebten npm-Pakets)
+ Ein optionaler [Namespace](packages-concepts.md#packages-concepts-package-namespaces) (zum Beispiel in) `@types` `@types/node`
+ Eine Reihe von [Versionen](packages-concepts.md#packages-concepts-package-versions) (zum Beispiel, `1.0.0``1.0.1`,`1.0.2`)
+ Metadaten auf Paketebene (z. B. npm dist-Tags)

In CodeCatalyst können Sie Pakete in Paket-Repositorys veröffentlichen und Pakete aus CodeCatalyst Paket-Repositorys in Ihren Workflows verwenden. Sie können eine Build- oder Testaktion mit einem CodeCatalyst Paket-Repository konfigurieren, um den npm-Client einer Aktion automatisch so zu konfigurieren, dass Pakete aus dem angegebenen Repository gesendet und abgerufen werden.

Weitere Informationen zu Paketen finden Sie unter[Veröffentlichen und teilen Sie Softwarepakete in CodeCatalyst](packages.md).

**Anmerkung**  
Derzeit unterstützen Build- und Testaktionen CodeCatalyst Paket-Repositorys.

**Topics**
+ [

# Tutorial: Aus einem Paket-Repository abrufen
](packages-tutorial.md)
+ [

# CodeCatalyst Paket-Repositorys in Workflows angeben
](workflows-package-specify-action.md)
+ [

# Verwenden von Autorisierungstoken in Workflow-Aktionen
](workflows-package-export-token.md)
+ [

# Beispiele: Paket-Repositorys in Workflows
](workflows-working-packages-ex.md)

# Tutorial: Aus einem Paket-Repository abrufen
<a name="packages-tutorial"></a>

In diesem Tutorial erfahren Sie, wie Sie einen Workflow erstellen, der eine Anwendung ausführt, deren Abhängigkeiten aus einem [CodeCatalyst Paket-Repository](packages-concepts.md#packages-concepts-repository) abgerufen werden. Bei der Anwendung handelt es sich um eine einfache Node.js App, die eine „Hello World“ -Meldung in die CodeCatalyst Protokolle druckt. Die Anwendung hat eine einzige Abhängigkeit: das [Lodash](https://www.npmjs.com/package/lodash) npm-Paket. Das `lodash` Paket wird verwendet, um eine `hello-world` Zeichenfolge in umzuwandeln. `Hello World` Sie werden Version 4.17.20 dieses Pakets verwenden.

Nachdem Sie Ihre Anwendung und Ihren Workflow eingerichtet haben, konfigurieren Sie so CodeCatalyst , dass zusätzliche Versionen von nicht `lodash` aus der öffentlichen externen Registrierung ([npmjs.com](https://www.npmjs.com/)) in das CodeCatalyst Paket-Repository importiert werden. Anschließend testen Sie, ob weitere Versionen von erfolgreich blockiert `lodash` wurden.

Am Ende dieses Tutorials sollten Sie ein gutes Verständnis dafür haben, wie ein Workflow mit Paket-Repositorys interagiert, sowohl innerhalb als auch außerhalb CodeCatalyst, um Pakete abzurufen. Sie sollten auch die behind-the-scenes Interaktionen verstehen, die zwischen npm, Ihrem Paket-Repository, Ihrem Workflow und der Datei Ihrer Anwendung auftreten. `package.json` 

**Topics**
+ [

## Voraussetzungen
](#packages-tutorial-prereqs)
+ [

## Schritt 1: Erstellen Sie ein Quell-Repository
](#packages-tutorial-source-repo)
+ [

## Schritt 2: Erstellen Sie die CodeCatalyst Paket-Repositorys und das Gateway
](#packages-tutorial-package-repo)
+ [

## Schritt 3: Erstellen Sie die Anwendung „Hello World“
](#packages-tutorial-create-app)
+ [

## Schritt 4: Erstellen Sie einen Workflow, der „Hello World“ ausführt
](#packages-tutorial-create-workflow)
+ [

## Schritt 5: Überprüfen Sie den Workflow
](#packages-tutorial-verify)
+ [

## Schritt 6: Blockieren Sie Importe von npmjs.com
](#packages-tutorial-block)
+ [

## Schritt 7: Testen Sie die Blockierungsfunktion
](#packages-tutorial-test-block)
+ [

## Bereinigen
](#packages-tutorial-cleanup)

## Voraussetzungen
<a name="packages-tutorial-prereqs"></a>

Bevor Sie beginnen:
+ Sie benötigen ein CodeCatalyst **Leerzeichen.** Weitere Informationen finden Sie unter [Erstellen einer Umgebung](spaces-create.md).
+ In deinem CodeCatalyst Space benötigst du ein leeres Projekt mit dem Namen:

  ```
  codecatalyst-package-project
  ```

  Verwenden Sie die Option **Von vorne beginnen**, um dieses Projekt zu erstellen.

  Weitere Informationen finden Sie unter [Ein leeres Projekt in Amazon erstellen CodeCatalyst](projects-create.md#projects-create-empty).

## Schritt 1: Erstellen Sie ein Quell-Repository
<a name="packages-tutorial-source-repo"></a>

In diesem Schritt erstellen Sie ein Quell-Repository in CodeCatalyst. In diesem Repository werden die Quelldateien des Tutorials gespeichert, z. B. die `package.json` Dateien `index.js` und.

Weitere Hinweise zu Quell-Repositorys finden Sie unter[Erstellen eines Quell-Repositorys](source-repositories-create.md).

**Um ein Quell-Repository zu erstellen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Navigieren Sie zu Ihrem Projekt,`codecatalyst-package-project`.

1. Wählen Sie im Navigationsbereich **Code** und dann **Quell-Repositories** aus. 

1. Wählen **Sie Repository hinzufügen** und anschließend **Repository erstellen** aus.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   hello-world-app
   ```

1. Wählen Sie **Erstellen** aus.

## Schritt 2: Erstellen Sie die CodeCatalyst Paket-Repositorys und das Gateway
<a name="packages-tutorial-package-repo"></a>

In diesem Schritt erstellen Sie ein Paket-Repository in Ihrem CodeCatalyst Projekt und verbinden es mit einem Gateway-Repository, ebenfalls in Ihrem CodeCatalyst Projekt. Später importieren Sie die Abhängigkeit des Tutorials von npmjs.com in beide Repositorys. `lodash`

Das Gateway-Repository ist der „Klebstoff“, der dein Paket-Repository mit dem öffentlichen npmjs.com CodeCatalyst verbindet.

Weitere Informationen zu Paket-Repositorys finden Sie unter. [Veröffentlichen und teilen Sie Softwarepakete in CodeCatalyst](packages.md)

**Anmerkung**  
In dieser praktischen Einführung werden die Begriffe *CodeCatalyst Paket-Repository* und *Gateway-Repository* verwendet, um sich auf die beiden Repositorys zu beziehen, die Sie CodeCatalyst im folgenden Verfahren erstellen.

**Um CodeCatalyst Paket- und Gateway-Repositorys zu erstellen**

1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus. 

1. Wählen Sie **Paket-Repository erstellen**.

1. Geben Sie im Feld **Repository-Name** Folgendes ein:

   ```
   codecatalyst-package-repository
   ```

1. Wählen Sie **\$1 Upstream-Repositorys auswählen**.

1. Wählen Sie **Gateway-Repositorys**.

1. Wählen Sie in dem **npm-public-registry-gateway**Feld **Create** aus.

1. Wählen Sie **Select (Auswählen)**.

1. Wählen Sie **Erstellen** aus.

   CodeCatalyst erstellt ein Paket-Repository namens`codecatalyst-package-repository`, das mit einem Gateway-Repository verbunden ist. Das Gateway-Repository ist mit der Registrierung npmjs.com verbunden.

## Schritt 3: Erstellen Sie die Anwendung „Hello World“
<a name="packages-tutorial-create-app"></a>

In diesem Schritt erstellen Sie eine „Hello World“ -Anwendung Node.js und importieren deren Abhängigkeit (`lodash`) in Ihre Gateway- und Paket-Repositorys. CodeCatalyst 

Um die Anwendung zu erstellen, benötigen Sie einen Entwicklungscomputer, auf dem Node.js und der zugehörige `npm` Client installiert sind.

In diesem Tutorial wird davon ausgegangen, dass Sie eine CodeCatalyst Entwicklungsumgebung als Entwicklungsmaschine verwenden. Sie müssen zwar keine CodeCatalyst Entwicklungsumgebung verwenden, aber sie wird empfohlen, da sie eine saubere Arbeitsumgebung bietet, Node.js enthält und `npm` vorinstalliert ist und leicht zu löschen ist, wenn Sie das Tutorial abgeschlossen haben. Weitere Informationen zu CodeCatalyst Entwicklungsumgebungen finden Sie unter[Erstellen einer Entwicklungsumgebung](devenvironment-create.md).

Gehen Sie wie folgt vor, um eine CodeCatalyst Entwicklungsumgebung zu starten und damit die Anwendung „Hello World“ zu erstellen.

**Um eine Entwicklungsumgebung zu starten CodeCatalyst**

1. Wählen Sie im Navigationsbereich **Code** und dann **Dev Environments** aus. 

1. Wählen Sie oben **Create Dev Environment** und dann **AWS Cloud9 (im Browser)** aus.

1. Vergewissern Sie sich, dass **Repository** auf `hello-world-app` und **Existing Branch** auf eingestellt ist`main`. Wählen Sie **Erstellen** aus.

   Ihre Entwicklungsumgebung wird in einem neuen Browser-Tab gestartet, in den Ihr Repository (`hello-world-app`) geklont wird.

1. Lassen Sie beide CodeCatalyst Browser-Tabs geöffnet und fahren Sie mit dem nächsten Verfahren fort.

**Um die Anwendung „Hello World“ Node.js zu erstellen**

1. Gehen Sie zu Ihrer Entwicklungsumgebung.

1. Wechseln Sie an der Terminal-Eingabeaufforderung zum Stammverzeichnis des `hello-world-app` Quell-Repositorys:

   ```
   cd hello-world-app
   ```

1. Initialisieren Sie ein Node.js -Projekt:

   ```
   npm init -y
   ```

   Die Initialisierung erstellt eine `package.json` Datei im Stammverzeichnis von. `hello-world-app`

1. Connect den npm-Client in Ihrer Entwicklungsumgebung mit Ihrem CodeCatalyst Paket-Repository:

   1. Wechseln Sie zur CodeCatalyst Konsole.

   1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.

   1. Wählen Sie `codecatalyst-package-repository`.

   1. Wählen Sie **Mit Repository verbinden**.

   1. Wählen Sie „**Token erstellen**“. Ein Personal Access Token (PAT) wird für Sie erstellt.

   1. Wählen Sie **Kopieren**, um die Befehle zu kopieren.

   1. Wechseln Sie zu Ihrer Entwicklungsumgebung.

   1. Stellen Sie sicher, dass Sie sich im `hello-world-app` Verzeichnis befinden.

   1. Fügen Sie die Befehle ein. Sie sehen etwa wie folgt aus:

      ```
      npm set registry=https://packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/codecatalyst-package-repository/ --location project
      npm set //packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/hello-world-app/:_authToken=username:token-secret
      ```

1. `lodash`Version 4.17.20 importieren:

   ```
   npm install lodash@v4.17.20 --save --save-exact
   ```

   npm sucht an den folgenden Orten in der folgenden Reihenfolge nach `lodash` Version 4.17.20:
   + In der Entwicklungsumgebung. Es kann es hier nicht finden.
   + Im CodeCatalyst Paket-Repository. Es kann es hier nicht finden.
   + Im Gateway-Repository. Es kann es hier nicht finden.
   + Auf npmjs.com. Es findet es hier.

   npm `lodash` importiert in das Gateway-Repository, das CodeCatalyst Paket-Repository und die Entwicklungsumgebung.
**Anmerkung**  
Wenn Sie den npm-Client in Schritt 4 nicht mit Ihrem CodeCatalyst Paket-Repository verbunden hätten, hätte npm `lodash` direkt von npmjs.com abgerufen und das Paket in keines der Repositorys importiert.

   npm aktualisiert Ihre `package.json` Datei auch mit der `lodash` Abhängigkeit und erstellt ein `node_modules` Verzeichnis, das all seine Abhängigkeiten enthält. `lodash`

1. Testen Sie, der erfolgreich in Ihre Entwicklungsumgebung importiert `lodash` wurde. Geben Sie ein:

   ```
   npm list
   ```

   Die folgende Meldung weist auf einen erfolgreichen Import hin:

   ```
   `-- lodash@4.17.20
   ```

1. (Optional) Öffnen Sie `hello-world-app/package.json` und überprüfen Sie, ob die Zeilen in hinzugefügt ***red bold***wurden:

   ```
   {
     "name": "hello-world-app",
     "version": "1.0.0",
     "description": "",
     "main": "index.js",
     "scripts": {
       "test": "echo \"Error: no test specified\" && exit 1"
     },
     "keywords": [],
     "author": "",
     "license": "ISC",
     dependencies": {
       "lodash": "4.17.20"
     }
   }
   ```

1. Erstellen Sie in `/hello-world-app` eine Datei namens `index.js` mit dem folgenden Inhalt:
**Tipp**  
Sie können die Seitennavigation in Ihrer Entwicklungsumgebung verwenden, um diese Datei zu erstellen.

   ```
   // Importing lodash library
   const _ = require('lodash');
   
   // Input string
   const inputString = 'hello-world';
   
   // Transforming the string using lodash
   const transformedString = _.startCase(inputString.replace('-', ' '));
   
   // Outputting the transformed string to the console
   console.log(transformedString);
   ```

**Um zu testen, ob 'lodash' in Ihre Gateway- und CodeCatalyst Paket-Repositorys importiert wurde**

1. Wechseln Sie zur Konsole. CodeCatalyst 

1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.

1. Wählen Sie **npm-public-registry-gateway**.

1. Stellen Sie sicher, dass angezeigt `lodash` wird. In der Spalte **Letzte Version** wird Folgendes angezeigt`4.17.20`.

1. Wiederholen Sie diesen Vorgang für die`codecatalyst-package-repository`. Möglicherweise müssen Sie das Browserfenster aktualisieren, um das importierte Paket zu sehen.

**Um „Hello World“ in Ihrer Entwicklungsumgebung zu testen**

1. Wechseln Sie zu Ihrer Entwicklungsumgebung.

1. Stellen Sie sicher, dass Sie sich immer noch im `hello-world-app` Verzeichnis befinden, und führen Sie dann die Anwendung aus:

   ```
   node index.js
   ```

   Eine `Hello World` Meldung wird angezeigt. Node.js hat die Anwendung mit dem `lodash` Paket ausgeführt, das Sie in einem vorherigen Schritt in Ihre Entwicklungsumgebung heruntergeladen haben.

**Um das Verzeichnis 'node\$1modules' zu ignorieren und 'Hello World' zu übertragen**

1. Ignoriere das Verzeichnis. `node_modules` Geben Sie ein:

   ```
   echo "node_modules/" >> .gitignore
   ```

   Es hat sich bewährt, zu vermeiden, dass dieses Verzeichnis festgeschrieben wird. Außerdem beeinträchtigt die Übertragung dieses Verzeichnisses die späteren Schritte in diesem Tutorial.

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "add the Hello World application"
   git push
   ```

   Die Anwendung und die Projektdateien von „Hello World“ werden Ihrem Quell-Repository hinzugefügt.

## Schritt 4: Erstellen Sie einen Workflow, der „Hello World“ ausführt
<a name="packages-tutorial-create-workflow"></a>

In diesem Schritt erstellen Sie einen Workflow, der die Anwendung „Hello World“ unter Verwendung der Abhängigkeit ausführt. `lodash` Der Workflow umfasst eine einzelne *Aktion* oder Aufgabe, die aufgerufen wird. `RunHelloWorldApp` Die `RunHelloWorldApp` Aktion umfasst die folgenden wichtigen Befehle und Abschnitte:
+ **`Packages`**

  Dieser Abschnitt gibt den Namen des CodeCatalyst Paket-Repositorys an, zu dem die Aktion beim Ausführen `npm install` eine Verbindung herstellen muss.
+ **`- Run: npm install`** 

  Dieser Befehl weist npm an, die in der `package.json` Datei angegebenen Abhängigkeiten zu installieren. Die einzige in der `package.json` Datei angegebene Abhängigkeit ist`lodash`. npm sucht an den folgenden `lodash` Orten nach:
  + Im Docker-Image, in dem die Aktion ausgeführt wird. Es kann es hier nicht finden.
  + Im CodeCatalyst Paket-Repository. Es findet es hier.

  Nachdem npm es gefunden hat`lodash`, importiert es es in das Docker-Image, auf dem die Aktion ausgeführt wird.
+ **`- Run: npm list`**

  Dieser Befehl gibt aus, welche Version von auf das Docker-Image heruntergeladen `lodash` wurde, auf dem die Aktion ausgeführt wird.
+ **`- Run: node index.js`**

  Mit diesem Befehl wird die Anwendung „Hello World“ unter Verwendung der in der Datei angegebenen Abhängigkeit ausgeführt. `package.json`

Beachten Sie, dass es sich bei der `RunHelloWorldApp` Aktion um eine Build-Aktion handelt, wie durch die `aws/build@v1` Kennung oben im Workflow angezeigt wird. Weitere Informationen zur Build-Aktion finden Sie unter[Bauen mit Workflows](build-workflow-actions.md).

Verwenden Sie die folgenden Anweisungen, um einen Workflow zu erstellen, der die `lodash` Abhängigkeit aus Ihrem CodeCatalyst Paket-Repository abruft und dann Ihre Anwendung „Hello World“ ausführt.

**So erstellen Sie ein Workflow**

1. Wechseln Sie zur Konsole. CodeCatalyst 

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

1. Wählen Sie Workflow **erstellen** aus.

1. Wählen Sie für **Quell-Repository** die Option`hello-world-app`.

1. Wählen Sie für **Branch** die Option`main`.

   Die Workflow-Definitionsdatei wird im ausgewählten Quell-Repository und Branch erstellt.

1. Wählen Sie **Erstellen** aus.

1. Wählen Sie oben **YAML** aus.

1. Löschen Sie den YAML-Beispielcode.

1. Fügen Sie den folgenden YAML-Code hinzu:

   ```
   Name: codecatalyst-package-workflow
   SchemaVersion: "1.0"
   
   # Required - Define action configurations.
   Actions:
     RunHelloWorldApp:
       # Identifies the action. Do not modify this value.
       Identifier: aws/build@v1
       Compute:
         Type: Lambda
       Inputs:
         Sources:
           - WorkflowSource # This specifies your source repository. 
       Configuration:
         Steps:
           - Run: npm install
           - Run: npm list
           - Run: node index.js
         Container: # This specifies the Docker image that runs the action.
           Registry: CODECATALYST
           Image: CodeCatalystLinuxLambda_x86_64:2024_03
       Packages:
         NpmConfiguration:
           PackageRegistries:
             - PackagesRepository: codecatalyst-package-repository
   ```

   Ersetzen Sie ihn im vorherigen Code *codecatalyst-package-repository* durch den Namen des CodeCatalyst Paket-Repositorys, in [Schritt 2: Erstellen Sie die CodeCatalyst Paket-Repositorys und das Gateway](#packages-tutorial-package-repo) dem Sie es erstellt haben.

   Informationen zu den Eigenschaften in dieser Datei finden Sie unter[Aktionen erstellen und testen YAML](build-action-ref.md).

1. (Optional) Wählen Sie „**Validieren**“, um sicherzustellen, dass der YAML-Code gültig ist, bevor Sie ihn festschreiben.

1. Wählen Sie **Commit** (Übergeben).

1. Geben Sie im **Dialogfeld „Workflow bestätigen**“ Folgendes ein:

   1. Behalten Sie als **Workflow-Dateiname** die Standardeinstellung bei`codecatalyst-package-workflow`.

   1. Geben Sie für **Commit-Nachricht** Folgendes ein:

      ```
      add initial workflow file
      ```

   1. Wählen Sie für **Repository **hello-world-app****.

   1. Wählen Sie als **Branch-Name** die Option **main** aus.

   1. Wählen Sie **Commit** (Übergeben).

   Sie haben jetzt einen Workflow erstellt.

**Um den Workflow auszuführen**

1. Wählen Sie neben dem Workflow, den Sie gerade erstellt haben (`codecatalyst-package-workflow`), **Aktionen** und dann **Ausführen** aus.

   Eine Workflow-Ausführung wird gestartet.

1. Wählen Sie in der grünen Benachrichtigung oben rechts den Link zum Lauf aus. Der Link sieht ähnlich aus wie`View Run-1234`.

   Es wird ein Workflow-Diagramm angezeigt, das zeigt, wer den Lauf und die **RunHelloWorldApp**Aktion gestartet hat.

1. Wählen Sie das **RunHelloWorldApp**Aktionsfeld aus, um den Fortschritt der Aktion zu verfolgen. 

1. Wenn der Lauf beendet ist, gehe zu[Schritt 5: Überprüfen Sie den Workflow](#packages-tutorial-verify).

## Schritt 5: Überprüfen Sie den Workflow
<a name="packages-tutorial-verify"></a>

In diesem Schritt überprüfen Sie, ob der Workflow die Anwendung „Hello World“ mit ihrer `lodash` Abhängigkeit erfolgreich ausgeführt hat.

**Um zu überprüfen, ob die Anwendung „Hello World“ unter Verwendung ihrer Abhängigkeit ausgeführt wurde**

1. Wählen Sie im Workflow-Diagramm das **RunHelloWorldApp**Feld aus.

   Eine Liste mit Protokollmeldungen wird angezeigt.

1. Erweitern Sie die `node index.js` Protokollnachricht.

   Die folgende Meldung wird angezeigt:

   ```
   [Container] 2024/04/24 21:15:41.545650 Running command node index.js
   Hello World
   ```

   Das Erscheinen von `Hello Word` (anstelle von`hello-world`) weist darauf hin, dass die `lodash` Abhängigkeit erfolgreich verwendet wurde.

1. Erweitern Sie das `npm list` Protokoll.

   Eine Meldung ähnlich der folgenden wird angezeigt:

   ```
   └── lodash@4.17.20
   ```

   Diese Meldung weist darauf hin, dass `lodash` Version 4.17.20 auf das Docker-Image heruntergeladen wurde, auf dem die Workflow-Aktion ausgeführt wird.

## Schritt 6: Blockieren Sie Importe von npmjs.com
<a name="packages-tutorial-block"></a>

 Jetzt, da `lodash` Version 4.17.20 in Ihrem Gateway und Ihren CodeCatalyst Paket-Repositorys vorhanden ist, können Sie Importe anderer Versionen blockieren. Durch das Blockieren wird verhindert, dass Sie versehentlich neuere (oder frühere) Versionen von importieren`lodash`, die möglicherweise bösartigen Code enthalten. Weitere Informationen erhalten Sie unter [Steuerelemente für den Paketursprung bearbeiten](package-origin-controls.md) und [Angriffe durch Substitution von Abhängigkeiten](package-origin-controls.md#dependency-substitution-attacks).

Verwenden Sie die folgenden Anweisungen, um Importe von `lodash` in Ihr Gateway-Repository zu blockieren. Wenn Sie Pakete am Gateway blockieren, werden sie auch an nachgelagerten Standorten blockiert.

**Um Importe in Ihr Gateway-Repository zu blockieren**

1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.

1. Wählen Sie **npm-publish-registry-gateway**.

1. Wählen Sie `lodash`.

1. Wähle ganz oben **Origin Controls** aus.

1. Wähle unter **Upstream** die Option **Blockieren** aus.

1. Wählen Sie **Speichern**.

   Sie haben jetzt Importe von npmjs.com in Ihr Gateway-Repository (und Downstream-Repositorys und Computer) blockiert.

## Schritt 7: Testen Sie die Blockierungsfunktion
<a name="packages-tutorial-test-block"></a>

In diesem Abschnitt überprüfen Sie, ob die Blockierung, die Sie eingerichtet haben, funktioniert. [Schritt 6: Blockieren Sie Importe von npmjs.com](#packages-tutorial-block) **Zunächst konfigurieren Sie „Hello World“ so, dass Version 4.17.2 **1** von `lodash` anstelle der in Ihrem Gateway-Repository verfügbaren Version 4.17.2 0 angefordert wird.** Anschließend überprüfen Sie, ob die Anwendung Version 4.17.21 nicht von nmpjs.com abrufen kann, was auf eine erfolgreiche Blockierung hinweist. Als letzten Test entsperren Sie Importe in Ihr Gateway-Repository und überprüfen, ob die Anwendung Version 4.17.21 von erfolgreich abrufen kann. `lodash`

Verwenden Sie die folgenden Verfahren, um die Blockierungsfunktion zu testen.

**Bevor Sie beginnen**

1. Wechseln Sie zu Ihrer Entwicklungsumgebung.

1. Rufen Sie die `codecatalyst-package-workflow.yaml` Datei ab, die Sie zuvor mit der CodeCatalyst Konsole erstellt haben:

   ```
   git pull
   ```

**Um 'Hello World' so zu konfigurieren, dass Version 4.17.21 von 'lodash' angefordert wird**

1. Öffnen Sie `/hello-world-app/package.json`.

1. Ändern Sie die `lodash` Version auf 4.17.21, wie in: ***red bold***

   ```
   {
     "name": "hello-world-app",
     "version": "1.0.0",
     "description": "",
     "main": "index.js",
     "scripts": {
       "test": "echo \"Error: no test specified\" && exit 1"
     },
     "keywords": [],
     "author": "",
     "license": "ISC",
     "dependencies": {
       "lodash": "4.17.21"
     }
   }
   ```

   Es besteht jetzt eine Diskrepanz zwischen der Version in der `package.json` Datei (4.17.21) und der Version in den Gateway- und CodeCatalyst Paket-Repositorys (4.17.20).

1. Hinzufügen, Festschreiben und Push:

   ```
   git add .
   git commit -m "update package.json to use lodash 4.17.21"
   git push
   ```

**Um zu testen, dass 'Hello World' die Version 4.17.21 von 'lodash' nicht abrufen kann**

1. Führen Sie den Workflow mit dem Versionskonflikt aus:

   1. Wechseln Sie zur CodeCatalyst Konsole.

   1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**

   1. **Wählen Sie `codecatalyst-package-workflow` als Nächstes **Aktionen** und anschließend Ausführen aus.**

      npm sucht nach Abhängigkeiten und `package.json` stellt fest, dass Version 4.17.21 von für 'Hello World' `lodash` erforderlich ist. npm sucht an den folgenden Speicherorten in der folgenden Reihenfolge nach der Abhängigkeit:
      + Im Docker-Image, in dem die Aktion ausgeführt wird. Es kann es hier nicht finden.
      + Im CodeCatalyst Paket-Repository. Es kann es hier nicht finden.
      + Im Gateway-Repository. Es kann es hier nicht finden.
      + Auf npmjs.com. Es findet es hier.

      Nachdem npm Version 4.17.21 auf npmjs.com gefunden hat, versucht es, sie in das Gateway-Repository zu importieren. Da Sie das Gateway jedoch so eingerichtet haben, dass Importe von blockiert werden`lodash`, findet der Import nicht statt.

      Da der Import nicht stattfindet, schlägt der Workflow fehl.

1. Stellen Sie sicher, dass der Workflow fehlgeschlagen ist:

   1. Wählen Sie in der grünen Benachrichtigung oben rechts den Link zum Lauf aus. Der Link sieht ähnlich aus wie`View Run-2345`.

   1. Wählen Sie im Workflow-Diagramm das **RunHelloWorldApp**Feld aus.

   1. Erweitern Sie die `npm install` Protokollnachricht.

      Die folgende Meldung wird angezeigt:

      ```
      [Container] 2024/04/25 17:20:34.995591 Running command npm install
      npm ERR! code ETARGET
      npm ERR! notarget No matching version found for lodash@4.17.21.
      npm ERR! notarget In most cases you or one of your dependencies are requesting
      npm ERR! notarget a package version that doesn't exist.
      
      npm ERR! A complete log of this run can be found in: /tmp/.npm/_logs/2024-05-08T22_03_26_493Z-debug-0.log
      ```

      Der Fehler weist darauf hin, dass Version 4.17.21 nicht gefunden werden konnte. Dies wird erwartet, da Sie es blockiert haben.

**Um Importe von npmjs.com zu entsperren**

1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.

1. Wählen Sie **npm-publish-registry-gateway**.

1. Wählen Sie `lodash`.

1. **Wähle ganz oben Origin Controls aus.**

1. Wähle unter **Upstream** die Option **Zulassen** aus.

1. Wählen Sie **Speichern**.

   Sie haben jetzt Importe von `lodash` entsperrt.

   Ihr Workflow kann jetzt Version 4.17.21 von importieren. `lodash`

**Um zu testen, ob Importe von npmjs.com entsperrt sind**

1. Führen Sie Ihren Workflow erneut aus. Diesmal sollte der Workflow erfolgreich sein, da der Import von 4.17.21 jetzt funktionieren sollte. Um den Workflow erneut auszuführen:

   1. **Wählen Sie **CI/CD** und dann Workflows.**

   1. **Wählen Sie `codecatalyst-package-workflow` als Nächstes **Aktionen** und dann Ausführen aus.**

   1. Wählen Sie in der grünen Benachrichtigung oben rechts den Link zum Lauf aus. Der Link sieht ähnlich aus wie`View Run-3456`.

      Es wird ein Workflow-Diagramm angezeigt, das zeigt, wer den Lauf und die **RunHelloWorldApp**Aktion gestartet hat.

   1. Wählen Sie das **RunHelloWorldApp**Aktionsfeld aus, um den Fortschritt der Aktion zu verfolgen. 

   1. Erweitern Sie die `npm list` Protokollnachricht und stellen Sie sicher, dass eine Meldung ähnlich der folgenden angezeigt wird:

      ```
      └── lodash@4.17.21
      ```

      Diese Meldung weist darauf hin, dass `lodash` Version 4.17.21 heruntergeladen wurde.

1. Stellen Sie sicher, dass Version 4.17.21 in Ihre und Ihre CodeCatalyst Gateway-Repositorys importiert wurde:

   1. Wählen Sie im Navigationsbereich **Packages (Pakete)** aus.

   1. Wählen Sie **npm-public-registry-gateway**.

   1. Suchen Sie nach der `lodash` Version und stellen Sie sicher, dass dies der Fall ist. `4.17.21`
**Anmerkung**  
Obwohl Version 4.17.20 nicht auf dieser Seite aufgeführt ist, können Sie sie finden, indem Sie oben **Versionen** auswählen `lodash` und dann auswählen.

   1. Wiederholen Sie diese Schritte, um zu überprüfen, ob Version 4.17.21 importiert wurde. `codecatalyst-package-repository`

## Bereinigen
<a name="packages-tutorial-cleanup"></a>

Bereinigen Sie die in diesem Tutorial verwendeten Dateien und Dienste, um zu vermeiden, dass dafür Gebühren anfallen.

**Anleitung zum Aufräumen der Pakete**

1. Löschen Sie das`codecatalyst-package-project`:

   1. Navigieren Sie in der CodeCatalyst Konsole zu dem `codecatalyst-package-project` Projekt, falls Sie noch nicht dort sind.

   1. Wählen Sie im Navigationsbereich die Option **Projekteinstellungen** aus.

   1. Wählen Sie **Projekt löschen****delete**, geben Sie ein und wählen Sie **Projekt löschen**.

      CodeCatalyst löscht alle Projektressourcen, einschließlich der Quell-, Gateway- und CodeCatalyst Paket-Repositorys. Die Entwicklungsumgebung wird ebenfalls gelöscht.

1. Löschen Sie das PAT-Token:

   1. Wählen Sie rechts Ihren Benutzernamen und dann **Meine Einstellungen** aus.

   1. Wählen Sie unter **Persönliche Zugriffstoken** das Token aus, das Sie in diesem Tutorial erstellt haben, und wählen Sie **Löschen** aus.

In diesem Tutorial haben Sie gelernt, wie Sie einen Workflow erstellen, der eine Anwendung ausführt, deren Abhängigkeiten aus einem CodeCatalyst Paket-Repository abgerufen werden. Sie haben auch gelernt, wie Sie Pakete blockieren und entsperren können, damit sie nicht in Ihr Gateway und Ihre CodeCatalyst Paket-Repositorys gelangen.

# CodeCatalyst Paket-Repositorys in Workflows angeben
<a name="workflows-package-specify-action"></a>

 CodeCatalystIn können Sie Ihren Build- und Testaktionen in Ihrem Workflow ein CodeCatalyst Paket-Repository hinzufügen. Ihr Paket-Repository muss mit einem Paketformat wie npm konfiguriert sein. Sie können sich auch dafür entscheiden, eine Abfolge von Bereichen für Ihr ausgewähltes Paket-Repository einzubeziehen.

Verwenden Sie die folgenden Anweisungen, um eine Paketkonfiguration anzugeben, die mit einer Workflow-Aktion verwendet werden soll.

------
#### [ Visual ]

**So geben Sie die Paketkonfiguration an, die eine Aktion verwenden soll (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 die Aktion **Build** oder **Test** aus, mit der Sie ein Paket-Repository konfigurieren möchten.

1. Wählen Sie **Pakete** aus.

1. Wählen **Sie im Dropdownmenü Konfiguration hinzufügen** die Paketkonfiguration aus, die Sie für Ihre Workflow-Aktionen verwenden möchten.

1. Wählen Sie **Paket-Repository hinzufügen** aus.

1. Geben Sie im Dropdownmenü **Paket-Repository** den Namen Ihres CodeCatalyst *Paket-Repositorys* an, das die Aktion verwenden soll.

   Weitere Hinweise zu Paket-Repositorys finden Sie unter. [Paket-Repositorys](packages-concepts.md#packages-concepts-repository)

1. (Optional) Geben Sie im **Feld Bereiche — optional** eine Abfolge von *Bereichen* an, die Sie in Ihrer Paketregistrierung definieren möchten.

   Bei der Definition von Bereichen wird das angegebene Paket-Repository als Registrierung für alle aufgelisteten Bereiche konfiguriert. Wenn ein Paket mit dem Bereich über den npm-Client angefordert wird, verwendet es dieses Repository anstelle des Standard-Repositorys. Jedem Bereichsnamen muss ein „@“ vorangestellt werden.

   Wenn dieser `Scopes` Wert weggelassen wird, wird das angegebene Paket-Repository als Standardregistrierung für alle von der Aktion verwendeten Pakete konfiguriert.

   Weitere Informationen zu Bereichen finden Sie unter [Paket-Namespaces](packages-concepts.md#packages-concepts-package-namespaces) und Pakete mit [Geltungsbereich](https://docs.npmjs.com/cli/v10/using-npm/scope).

1. Wählen Sie **Hinzufügen** aus.

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 die Paketkonfiguration anzugeben, die eine Aktion verwenden soll (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 in einer **Build** - oder **Test-Aktion** Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
    Configuration:
       Packages:
           NpmConfiguration:
             PackageRegistries:
               - PackagesRepository: package-repository
                 Scopes:
                   - "@scope"
   ```

   Weitere Informationen finden Sie in der Beschreibung der `Packages` Eigenschaft unter [Aktionen erstellen und testen YAML](build-action-ref.md) Für Ihre Aktion.

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

------

# Verwenden von Autorisierungstoken in Workflow-Aktionen
<a name="workflows-package-export-token"></a>

Sie können ein von der Workflow-Aktion bereitgestelltes Token verwenden, um einen Paketmanager manuell für die Authentifizierung bei CodeCatalyst Paket-Repositorys zu konfigurieren. CodeCatalyst stellt dieses Token als Umgebungsvariable zur Verfügung, auf die Sie bei Ihren Aktionen verweisen können.


| Umgebungsvariable | Wert | 
| --- | --- | 
|  CATALYST\$1MACHINE\$1RESOURCE\$1NAME  |  Die Benutzeridentität des Autorisierungstokens.  | 
|  CATALYST\$1PACKAGES\$1AUTHORIZATION\$1TOKEN  |  Der Wert eines Autorisierungstokens.  | 

**Anmerkung**  
Beachten Sie, dass diese Umgebungsvariablen nur aufgefüllt werden, wenn Sie Ihre Aktion für den Export des Autorisierungstokens konfiguriert haben.

Verwenden Sie die folgenden Anweisungen, um ein Autorisierungstoken mit einer Workflow-Aktion zu verwenden.

------
#### [ Visual ]

**Um ein exportiertes Autorisierungstoken mit einer Aktion zu verwenden (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 die Aktion **Build** oder **Test** aus, mit der Sie ein Paket-Repository konfigurieren möchten.

1. Wählen Sie **Pakete** aus.

1. Aktivieren Sie die Option **Autorisierungstoken exportieren**.

------
#### [ YAML ]

**Um ein exportiertes Autorisierungstoken mit einer Aktion zu verwenden (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 in einer **Build** - oder **Test-Aktion** Code hinzu, der dem folgenden ähnelt:

   ```
   Actions:
     action-name:
       Packages:
         ExportAuthorizationToken: true
   ```

   Sie können im `Steps` Abschnitt Ihrer YAML auf die Variablen `$CATALYST_MACHINE_RESOURCE_NAME` und die `$CATALYST_PACKAGES_AUTHORIZATION_TOKEN` Umgebungsvariablen verweisen. Weitere Informationen finden Sie unter [Beispiel: Manuelle Konfiguration für `pip` die Authentifizierung mit CodeCatalyst](workflows-working-packages-ex.md#workflows-working-packages-pypi-token).

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

------

# Beispiele: Paket-Repositorys in Workflows
<a name="workflows-working-packages-ex"></a>

Die folgenden Beispiele zeigen, wie in der Workflow-Definitionsdatei auf Pakete verwiesen wird.

**Topics**
+ [

## Beispiel: Pakete definieren mit `NpmConfiguration`
](#workflows-working-packages-ex-basic)
+ [

## Beispiel: Überschreiben der Standardregistrierung
](#workflows-working-packages-ex-overriding-registry)
+ [

## Beispiel: Bereiche in Ihrer Paketregistrierung überschreiben
](#workflows-working-packages-ex-overriding-scopes)
+ [

## Beispiel: Manuelle Konfiguration für `pip` die Authentifizierung mit CodeCatalyst
](#workflows-working-packages-pypi-token)

## Beispiel: Pakete definieren mit `NpmConfiguration`
<a name="workflows-working-packages-ex-basic"></a>

Das folgende Beispiel zeigt, wie Sie ein Paket mit `NpmConfiguration` in Ihrer Workflow-Definitionsdatei definieren.

```
Actions:
  Build:
  Identifier: aws/build-beta@v1
  Configuration:
    Packages:
        NpmConfiguration:
          PackageRegistries:
            - PackagesRepository: main-repo
            - PackagesRepository: scoped-repo
              Scopes:
                - "@scope1"
```

In diesem Beispiel wird der npm-Client wie folgt konfiguriert:

```
default: main-repo
@scope1: scoped-repo
```

In diesem Beispiel sind zwei Repositorys definiert. Die Standardregistrierung ist so festgelegt, `main-repo` wie sie ohne Bereich definiert ist. Der Bereich `@scope1` ist in `PackageRegistries` für konfiguriert`scoped-repo`.

## Beispiel: Überschreiben der Standardregistrierung
<a name="workflows-working-packages-ex-overriding-registry"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie die Standardregistrierung überschreiben können.

```
NpmConfiguration:
  PackageRegistries:
    - PackagesRepository: my-repo-1
    - PackagesRepository: my-repo-2
    - PackagesRepository: my-repo-3
```

In diesem Beispiel wird der npm-Client wie folgt konfiguriert:

```
default: my-repo-3
```

Wenn Sie mehrere Standard-Repositorys angeben, hat das letzte Repository Priorität. In diesem Beispiel ist das zuletzt aufgeführte Repository`my-repo-3`, was bedeutet, dass npm eine Verbindung herstellen wird. `my-repo-3` Dies überschreibt die `my-repo-1` Repositorien und. `my-repo-2`

## Beispiel: Bereiche in Ihrer Paketregistrierung überschreiben
<a name="workflows-working-packages-ex-overriding-scopes"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie einen Bereich in Ihrer Paketregistrierung überschreiben können.

```
NpmConfiguration:
  PackageRegistries:
    - PackagesRepository: my-default-repo
    - PackagesRepository: my-repo-1
      Scopes:
        - "@scope1"
        - "@scope2"
    - PackagesRepository: my-repo-2
      Scopes:
        - "@scope2"
```

In diesem Beispiel wird der npm-Client wie folgt konfiguriert:

```
default: my-default-repo
@scope1: my-repo-1
@scope2: my-repo-2
```

Wenn Sie übergeordnete Bereiche einbeziehen, hat das letzte Repository Priorität. In diesem Beispiel wurde dieser Bereich `@scope2` zum letzten Mal für konfiguriert. `PackageRegistries` `my-repo-2` Dadurch wird der für `@scope2` `my-repo-1` konfigurierte Bereich außer Kraft gesetzt.

## Beispiel: Manuelle Konfiguration für `pip` die Authentifizierung mit CodeCatalyst
<a name="workflows-working-packages-pypi-token"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie in einer Build-Aktion auf CodeCatalyst Autorisierungsumgebungsvariablen verweisen.

```
Actions:
  Build:
    Identifier: aws/build@v1.0.0
    Configuration:
      Steps:
        - Run: pip config set global.index-url https://$CATALYST_MACHINE_RESOURCE_NAME:$CATALYST_PACKAGES_AUTHORIZATION_TOKEN@codecatalyst.aws/pypi/my-space/my-project/my-repo/simple/
    Packages:
      ExportAuthorizationToken: true
```

# Aufrufen einer Lambda-Funktion mithilfe eines Workflows
<a name="lam-invoke-action"></a>

In diesem Abschnitt wird beschrieben, wie eine AWS Lambda Funktion mithilfe eines Workflows aufgerufen wird. CodeCatalyst Um dies zu erreichen, müssen Sie die **AWS Lambda Aufrufaktion zu** Ihrem Workflow hinzufügen. Die **AWS Lambda Aufruf-Aktion** ruft die Lambda-Funktion auf, die Sie angeben.

**[Die Aufruf-Aktion ruft nicht nur Ihre Funktion auf, sondern konvertiert auch jeden Schlüssel der AWS Lambda obersten Ebene in der Antwortnutzlast, die von der Lambda-Funktion empfangen wurde, in eine Workflow-Ausgabevariable.](workflows-working-with-variables.md)** Auf diese Variablen kann dann in nachfolgenden Workflow-Aktionen verwiesen werden. Wenn Sie nicht möchten, dass alle Schlüssel der obersten Ebene in Variablen umgewandelt werden, können Sie Filter verwenden, um die genauen Schlüssel anzugeben. Weitere Informationen finden Sie in der Beschreibung der [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) [Aktion 'AWS Lambda aufrufen' YAML](lam-invoke-action-ref.md) Immobilie. 

**Topics**
+ [

## Wann sollte diese Aktion verwendet werden
](#lam-invoke-action-when-to-use)
+ [

## Runtime-Image, das von der Aktion „Aufrufen“ verwendet wird AWS Lambda
](#lam-invoke-action-runtime)
+ [

# Beispiel: Eine Lambda-Funktion aufrufen
](lam-invoke-action-example-workflow.md)
+ [

# Aktion „AWS Lambda Aufrufen“ hinzufügen
](lam-invoke-action-add.md)
+ [

# Variablen 'AWS Lambda aufrufen'
](lam-invoke-action-variables.md)
+ [

# Aktion 'AWS Lambda aufrufen' YAML
](lam-invoke-action-ref.md)

## Wann sollte diese Aktion verwendet werden
<a name="lam-invoke-action-when-to-use"></a>

Verwenden Sie diese Aktion, wenn Sie Ihrem Workflow Funktionen hinzufügen möchten, die in einer Lambda-Funktion gekapselt sind und von dieser ausgeführt werden.

Beispielsweise möchtest du vielleicht, dass dein Workflow eine `Build started` Benachrichtigung an einen Slack-Channel sendet, bevor du einen Build deiner Anwendung startest. In diesem Fall würde dein Workflow eine **AWS Lambda Aufrufaktion zum Aufrufen** eines Lambdas zum Versenden der Slack-Benachrichtigung und eine [Build-Aktion](build-add-action.md) zum Erstellen deiner Anwendung beinhalten.

Als weiteres Beispiel könnten Sie möchten, dass Ihr Workflow einen Schwachstellenscan Ihrer Anwendung durchführt, bevor sie bereitgestellt wird. In diesem Fall würden Sie eine Build-Aktion verwenden, um Ihre Anwendung zu erstellen, eine **AWS Lambda Aufruf-Aktion**, um ein Lambda aufzurufen, um nach Sicherheitslücken zu suchen, und eine Bereitstellungsaktion, um die gescannte Anwendung bereitzustellen.

## Runtime-Image, das von der Aktion „Aufrufen“ verwendet wird AWS Lambda
<a name="lam-invoke-action-runtime"></a>

Die **AWS Lambda Aufruf-Aktion** wird auf einem Image [vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Beispiel: Eine Lambda-Funktion aufrufen
<a name="lam-invoke-action-example-workflow"></a>

Der folgende Beispiel-Workflow umfasst die Aktion „**AWS Lambda Aufrufen**“ zusammen mit einer Aktion „Bereitstellen“. Der Workflow sendet eine Slack-Benachrichtigung, die angibt, dass eine Bereitstellung gestartet wurde, und stellt dann AWS mithilfe einer Vorlage eine Anwendung bereit. CloudFormation Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein **Trigger** — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).
+ Eine **AWS Lambda Aufrufaktion** (`LambdaNotify`) — Beim Auslösen ruft diese Aktion die `Notify-Start` Lambda-Funktion im angegebenen AWS Konto und in der angegebenen Region (`my-aws-account`, und) auf. `us-west-2` Beim Aufruf sendet die Lambda-Funktion eine Slack-Benachrichtigung, die darauf hinweist, dass ein Deployment gestartet wurde.
+ Eine ** CloudFormation Stack-Aktion bereitstellen** (`Deploy`) — Nach Abschluss der Aufruf-Aktion führt **AWS Lambda die Stack-Aktion** **Deploy die Vorlage (`cfn-template.yml`) aus, um deinen CloudFormation Anwendungsstapel** bereitzustellen. Weitere Informationen zur Aktion ** CloudFormation Stack bereitstellen** finden Sie unter[Einen CloudFormation Stack bereitstellen](deploy-action-cfn.md).

**Anmerkung**  
Das folgende Workflow-Beispiel dient der Veranschaulichung und funktioniert ohne zusätzliche Konfiguration nicht.

**Anmerkung**  
Im folgenden YAML-Code können Sie die `Connections:` Abschnitte weglassen, wenn Sie möchten. **Wenn Sie diese Abschnitte weglassen, müssen Sie sicherstellen, dass die im Feld **Standard-IAM-Rolle** angegebene Rolle in Ihrer Umgebung die Berechtigungen und Vertrauensrichtlinien enthält, die für die Stack-Aktionen **AWS Lambda Invoke** und Deploy erforderlich sind. CloudFormation ** Weitere Informationen zum Einrichten einer Umgebung mit einer Standard-IAM-Rolle finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md) Weitere Informationen zu den Berechtigungen und Vertrauensrichtlinien, die für die ** CloudFormation Stack-Aktionen „**AWS Lambda Aufrufen**“ und „Bereitstellen**“ erforderlich sind, finden Sie in der Beschreibung der `Role` Eigenschaft im Dokument und. [Aktion 'AWS Lambda aufrufen' YAML](lam-invoke-action-ref.md) [Aktion CloudFormation 'Stack bereitstellen' YAML](deploy-action-ref-cfn.md)

```
Name: codecatalyst-lamda-invoke-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  LambdaNotify:
    Identifier: aws/lambda-invoke@v1
    Environment:
      Name: my-production-environment
      Connections:
        - Name: my-aws-account
          Role: codecatalyst-lambda-invoke-role
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      Function: Notify-Start
      AWSRegion: us-west-2
        
  Deploy:
    Identifier: aws/cfn-deploy@v1
    Environment:
      Name: my-production-environment
      Connections:
        - Name: my-aws-account
          Role: codecatalyst-deploy-role
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      name: my-application-stack
      region: us-west-2
      role-arn: arn:aws:iam::111122223333:role/StackRole
      template: ./cfn-template.yml
      capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
```

# Aktion „AWS Lambda Aufrufen“ hinzufügen
<a name="lam-invoke-action-add"></a>

 Verwenden Sie die folgenden Anweisungen, um die **AWS Lambda Aufrufaktion zu Ihrem Workflow hinzuzufügen.** 

**Voraussetzung**  
Bevor Sie beginnen, stellen Sie sicher, dass Ihre AWS Lambda Funktion und die zugehörige Lambda-Ausführungsrolle bereit und verfügbar sind. AWS Weitere Informationen finden Sie im Thema [Lambda-Ausführungsrolle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) im *AWS Lambda Developer Guide*.

------
#### [ Visual ]

**So fügen Sie die Aktion „AWS Lambda Aufrufen“ mit dem visuellen Editor hinzu**

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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS Lambda Aufrufaktion** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **AWS Lambda Aufrufen**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben**, **Konfiguration** und **Ausgaben** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion 'AWS Lambda aufrufen' YAML](lam-invoke-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „AWS Lambda Aufrufen“ 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. Wählen Sie links oben **\$1 Aktionen, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der **AWS Lambda Aufrufaktion** und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **AWS Lambda Aufrufen**. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion 'AWS Lambda aufrufen' YAML](lam-invoke-action-ref.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**.

------

# Variablen 'AWS Lambda aufrufen'
<a name="lam-invoke-action-variables"></a>

Standardmäßig erzeugt die **AWS Lambda Aufrufaktion** eine Variable pro Schlüssel der obersten Ebene in der Lambda-Antwortnutzlast.

Wenn die Antwortnutzlast beispielsweise wie folgt aussieht:

```
responsePayload = {
  "name": "Saanvi",
  "location": "Seattle",
  "department": {
    "company": "Amazon",
    "team": "AWS"
  }
}
```

... dann würde die Aktion die folgenden Variablen generieren.


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Name  |  Saanvi  | 
|  location  |  Seattle  | 
|  Abteilung  |  \$1"Firma“: „Amazon“, „Team“: "AWS„\$1  | 

**Anmerkung**  
Sie können mithilfe der `ResponseFilters` YAML-Eigenschaft ändern, welche Variablen generiert werden. Weitere Informationen finden Sie unter [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) im [Aktion 'AWS Lambda aufrufen' YAML](lam-invoke-action-ref.md).

*Die Variablen, die von der Aktion „AWS Lambda Aufrufen“ zur Laufzeit erzeugt und gesetzt werden, werden als vordefinierte Variablen bezeichnet.*

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter. [Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md)

# Aktion 'AWS Lambda aufrufen' YAML
<a name="lam-invoke-action-ref"></a>

**Im Folgenden finden Sie die YAML-Definition der Aufruf-Aktion.AWS Lambda ** Informationen zur Verwendung dieser Aktion finden Sie unter. [Aufrufen einer Lambda-Funktion mithilfe eines Workflows](lam-invoke-action.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 action definition starts here.   
  LambdaInvoke\$1nn: 
    Identifier: aws/lambda-invoke@v1
    DependsOn:
      - dependent-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - request-payload
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      Function: my-function|function-arn
      AWSRegion: us-west-2
      # Specify RequestPayload or RequestPayloadFile, but not both.
      RequestPayload: '{"firstname": "Li", lastname: "Jean", "company": "ExampleCo", "team": "Development"}'
      RequestPayloadFile: my/request-payload.json
      ContinueOnError: true|false
      LogType: Tail|None
      ResponseFilters: '{"name": ".name", "company": ".department.company"}'
    Outputs:
      Artifacts:
        - Name: lambda_artifacts
          Files: 
            - "lambda-response.json"
```

## LambdaInvoke
<a name="lam.invoke.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `Lambda_Invoke_Action_Workflow_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aktionsname“**

## Identifier
<a name="lam.invoke.identifier"></a>

(*LambdaInvoke*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/lambda-invoke@v1`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ LambdaInvoke \$1nn/ aws/lambda-invoke @v1 label**

## DependsOn
<a name="lam.invoke.dependson"></a>

(*LambdaInvoke*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="lam.invoke.computename"></a>

(*LambdaInvoke*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="lam.invoke.computetype"></a>

(*LambdaInvoke*/Compute/**Type**)

(Erforderlich, wenn [Compute](#lam.invoke.computename) es enthalten ist)

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: Registerkarte „**Konfiguration/Berechnungstyp**“

## Fleet
<a name="lam.invoke.computefleet"></a>

(*LambdaInvoke*/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 im Leerlauf 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`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„Flotte **berechnen**“

## Timeout
<a name="lam.invoke.timeout"></a>

(*LambdaInvoke*/**Timeout**)

(Erforderlich)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Inputs
<a name="lam.invoke.inputs"></a>

(*LambdaInvoke*/**Inputs**)

(Erforderlich)

Der `Inputs` Abschnitt definiert die Daten, die die **AWS Lambda Aufrufaktion während** einer Workflow-Ausführung benötigt.

**Anmerkung**  
Pro **AWS Lambda Aufrufaktion** ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig. Variablen werden auf diese Summe nicht angerechnet.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

## Sources
<a name="lam.invoke.inputs.sources"></a>

(*LambdaInvoke*/Inputs/**Sources**)

([RequestPayloadFile](#lam.invoke.request.payload.file)Erforderlich, falls angegeben)

Wenn Sie eine JSON-Datei mit Anforderungs-Payload an die **AWS Lambda Aufruf-Aktion** übergeben möchten und diese Payload-Datei in einem Quell-Repository gespeichert ist, geben Sie das Label dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label. `WorkflowSource`

Wenn Ihre Anforderungs-Payload-Datei nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Hinweise zur Payload-Datei finden Sie unter. [RequestPayloadFile](#lam.invoke.request.payload.file)

**Anmerkung**  
Anstatt eine Payload-Datei anzugeben, können Sie den JSON-Code der Payload mithilfe der Eigenschaft direkt zur Aktion hinzufügen. `RequestPayload` Weitere Informationen finden Sie unter [RequestPayload](#lam.invoke.request.payload). 

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="lam.invoke.inputs.artifacts"></a>

(*LambdaInvoke*/Inputs/**Artifacts**)

(Erforderlich, falls [RequestPayloadFile](#lam.invoke.request.payload.file)angegeben)

Wenn Sie eine JSON-Datei mit Anforderungs-Payload an die **AWS Lambda Aufruf-Aktion übergeben möchten und diese Payload-Datei in einem Ausgabeartefakt** [einer vorherigen Aktion enthalten ist, geben Sie dieses Artefakt](build-action-ref.md#build.outputs.artifacts) hier an.

Weitere Hinweise zur Payload-Datei finden Sie unter. [RequestPayloadFile](#lam.invoke.request.payload.file)

**Anmerkung**  
Anstatt eine Payload-Datei anzugeben, können Sie den JSON-Code der Payload mithilfe der Eigenschaft direkt zur Aktion hinzufügen. `RequestPayload` Weitere Informationen finden Sie unter [RequestPayload](#lam.invoke.request.payload). 

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Variables - input
<a name="lam.invoke.inputs.variables"></a>

(*LambdaInvoke*/Inputs/**Variables**)

(Optional)

Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Variablen“ — optional**

## Environment
<a name="lam.invoke.environment"></a>

(*LambdaInvoke*/**Environment**)

(Erforderlich)

Geben Sie die CodeCatalyst Umgebung an, die für die Aktion verwendet werden soll. Die Aktion stellt eine Verbindung mit der AWS-Konto optionalen Amazon VPC her, die in der ausgewählten Umgebung angegeben ist. Die Aktion verwendet die in der Umgebung angegebene Standard-IAM-Rolle, um sich mit der Amazon VPC zu verbinden AWS-Konto, und verwendet die in der [Amazon VPC-Verbindung angegebene IAM-Rolle, um eine Verbindung zur Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) herzustellen.

**Anmerkung**  
Wenn die Standard-IAM-Rolle nicht über die für die Aktion erforderlichen Berechtigungen verfügt, können Sie die Aktion so konfigurieren, dass sie eine andere Rolle verwendet. Weitere Informationen finden Sie unter [Die IAM-Rolle einer Aktion ändern](deploy-environments-switch-role.md).

Weitere Informationen zu Umgebungen finden Sie unter [Einsatz in AWS-Konten und VPCs](deploy-environments.md) und[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Name
<a name="lam.invoke.environment.name"></a>

(*LambdaInvoke*/Environment/**Name**)

(Erforderlich, falls [Environment](#lam.invoke.environment) enthalten)

Geben Sie den Namen einer vorhandenen Umgebung an, die Sie der Aktion zuordnen möchten.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Umgebung“**

## Connections
<a name="lam.invoke.environment.connections"></a>

(*LambdaInvoke*/Environment/**Connections**)

(Optional in neueren Versionen der Aktion; in älteren Versionen erforderlich)

Geben Sie die Kontoverbindung an, die der Aktion zugeordnet werden soll. Sie können unter maximal eine Kontoverbindung angeben`Environment`.

Wenn Sie keine Kontoverbindung angeben:
+ Die Aktion verwendet die AWS-Konto Verbindung und die Standard-IAM-Rolle, die in der Umgebung in der CodeCatalyst Konsole angegeben sind. Informationen zum Hinzufügen einer Kontoverbindung und einer Standard-IAM-Rolle zur Umgebung finden Sie unter. [Erstellen einer Umgebung](deploy-environments-creating-environment.md)
+ Die Standard-IAM-Rolle muss die Richtlinien und Berechtigungen enthalten, die für die Aktion erforderlich sind. **Informationen zu diesen Richtlinien und Berechtigungen finden Sie in der Beschreibung der Role-Eigenschaft in der YAML-Definitionsdokumentation der Aktion.**

Weitere Informationen zu Kontoverbindungen finden Sie unter[Ermöglichen des Zugriffs auf AWS Ressourcen mit verbundenen AWS-Konten](ipa-connect-account.md). Hinweise zum Hinzufügen einer Kontoverbindung zu einer Umgebung finden Sie unter[Erstellen einer Umgebung](deploy-environments-creating-environment.md).

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Name
<a name="lam.invoke.environment.connections.name"></a>

(*LambdaInvoke*/Environment/Connections/**Name**)

(Erforderlich, falls enthalten[Connections](#lam.invoke.environment.connections))

Geben Sie den Namen der Kontoverbindung an.

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte „Konfiguration“/„/Kontoverbindung Environment/account/role AWS **

## Role
<a name="lam.invoke.environment.connections.role"></a>

(*LambdaInvoke*/Environment/Connections/**Role**)

(Erforderlich, falls enthalten[Connections](#lam.invoke.environment.connections))

Geben Sie den Namen der IAM-Rolle an, mit der die **AWS Lambda Aufrufaktion** auf Ihre Lambda-Funktion zugreift AWS und sie aufruft. Stellen Sie sicher, dass Sie [die Rolle zu Ihrem CodeCatalyst Bereich hinzugefügt](ipa-connect-account-addroles.md) haben und dass die Rolle die folgenden Richtlinien enthält.

Wenn Sie keine IAM-Rolle angeben, verwendet die Aktion die Standard-IAM-Rolle, die in der [Umgebung](deploy-environments.md) in der CodeCatalyst Konsole aufgeführt ist. Wenn Sie die Standardrolle in der Umgebung verwenden, stellen Sie sicher, dass sie über die folgenden Richtlinien verfügt.
+ Die folgende Berechtigungsrichtlinie:
**Warnung**  
Beschränken Sie die Berechtigungen auf die in der folgenden Richtlinie angegebenen. Die Verwendung einer Rolle mit umfassenderen Berechtigungen kann ein Sicherheitsrisiko darstellen.
+ Die folgende benutzerdefinierte Vertrauensrichtlinie:

**Anmerkung**  
Sie können die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle mit dieser Aktion verwenden, wenn Sie möchten. Weitere Informationen über diese Rolle finden Sie unter [Die **CodeCatalystWorkflowDevelopmentRole-*spaceName***Rolle für Ihr Konto und Ihren Bereich erstellen](ipa-iam-roles.md#ipa-iam-roles-service-create). Beachten Sie, dass die `CodeCatalystWorkflowDevelopmentRole-spaceName` Rolle über volle Zugriffsberechtigungen verfügt, was ein Sicherheitsrisiko darstellen kann. Wir empfehlen, diese Rolle nur in Tutorials und Szenarien zu verwenden, in denen die Sicherheit weniger wichtig ist. 

Entsprechende Benutzeroberfläche: Je nach Aktionsversion eine der folgenden Optionen:
+ (Neuere Versionen) tab/Environment/What Die Konfiguration ist da*my-environment*? **/Dreipunktmenü/ Rolle wechseln**
+ **(Ältere Versionen) Registerkarte Environment/account/role „Konfiguration“ /' '/ Rolle**

## Configuration
<a name="lam.invoke.configuration"></a>

(*LambdaInvoke*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## Function
<a name="lam.invoke.function"></a>

(*LambdaInvoke*/Configuration/**Function**)

(Erforderlich)

Geben Sie die AWS Lambda Funktion an, die durch diese Aktion aufgerufen werden soll. Sie können den Namen der Funktion oder ihren Amazon-Ressourcennamen (ARN) angeben. Sie finden den Namen oder ARN in der Lambda-Konsole.

**Anmerkung**  
Das AWS Konto, in dem sich die Lambda-Funktion befindet, kann sich von dem unter angegebenen Konto unterscheiden. `Connections:`

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Funktion“**

## AWSRegion
<a name="lam.invoke.region"></a>

(*LambdaInvoke*/Configuration/**AWSRegion**)

(Erforderlich)

Geben Sie die AWS Region an, in der sich Ihre AWS Lambda Funktion befindet. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) in der. *Allgemeine AWS-Referenz*

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Ziel-Bucket**“ — optional

## RequestPayload
<a name="lam.invoke.request.payload"></a>

(*LambdaInvoke*/Configuration/**RequestPayload**)

(Optional)

Wenn Sie eine Anforderungsnutzlast an die **AWS Lambda Aufrufaktion** übergeben möchten, geben Sie die Anforderungsnutzlast hier im JSON-Format an.

Beispiel für eine Payload einer Anfrage:

```
'{ "key": "value" }'
```

Wenn Sie keine Anforderungsnutzlast an Ihre Lambda-Funktion übergeben möchten, lassen Sie diese Eigenschaft weg.

**Anmerkung**  
Sie können `RequestPayload` oder `RequestPayloadFile` angeben, aber nicht beides.

*Weitere Informationen zur Payload der Anfrage finden Sie im Thema [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) in der API-Referenz.AWS Lambda *

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Payload „**Anfrage**“ — optional

## RequestPayloadFile
<a name="lam.invoke.request.payload.file"></a>

(*LambdaInvoke*/Configuration/**RequestPayloadFile**)

(Optional)

Wenn Sie eine Anforderungs-Payload an die **AWS Lambda Aufruf-Aktion übergeben möchten, geben Sie hier** den Pfad zu dieser Anforderungs-Payload-Datei an. Die Datei muss im JSON-Format sein.

Die Payload-Datei der Anfrage kann sich in einem Quell-Repository oder in einem Artefakt aus einer früheren Aktion befinden. Der Dateipfad bezieht sich auf das Quell-Repository oder das Artefakt-Stammverzeichnis.

Wenn Sie keine Anforderungsnutzlast an Ihre Lambda-Funktion übergeben möchten, lassen Sie diese Eigenschaft weg.

**Anmerkung**  
Sie können `RequestPayload` oder `RequestPayloadFile` angeben, aber nicht beides.

*Weitere Informationen zur Payload-Datei für Anfragen finden Sie im Thema [Invoke in der API-Referenz](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html).AWS Lambda *

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/**Payload-Datei anfordern** — optional

## ContinueOnError
<a name="lam.invoke.continue"></a>

(*LambdaInvoke*/Configuration/**RequestPayloadFile**)

(Optional)

Geben Sie an, ob Sie die **AWS Lambda Aufrufaktion** auch dann als erfolgreich markieren möchten, wenn die AWS Lambda aufgerufene Funktion fehlschlägt. Erwägen Sie, diese Eigenschaft auf `true` zu setzen, damit nachfolgende Aktionen in Ihrem Workflow trotz des Lambda-Fehlers gestartet werden können.

Standardmäßig schlägt die Aktion fehl, wenn die Lambda-Funktion fehlschlägt („off“ im Visual Editor oder `false` im YAML-Editor).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Bei Fehler fortfahren**

## LogType
<a name="lam.invoke.log.type"></a>

(*LambdaInvoke*/Configuration/**LogType**)

(Optional)

Geben Sie an, ob Sie Fehlerprotokolle in die Antwort der Lambda-Funktion aufnehmen möchten, nachdem sie aufgerufen wurde. Sie können diese Protokolle auf der Registerkarte **Protokolle** der **Lambda-Aufrufaktion** in der CodeCatalyst Konsole anzeigen. Die möglichen Werte sind:
+ `Tail`— Logs zurückgeben
+ `None`— gibt keine Logs zurück

Die Standardeinstellung ist **Tail**.

Weitere Informationen zum Protokolltyp finden Sie im Thema [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) in der *AWS Lambda API-Referenz.*

Weitere Informationen zum Anzeigen von Protokollen finden Sie unter [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“ /Protokolltyp**

## ResponseFilters
<a name="lam.invoke.response.filters"></a>

(*LambdaInvoke*/Configuration/**ResponseFilters**)

(Optional)

Geben Sie an, welche Schlüssel in der Payload der Lambda-Antwort Sie in Ausgabevariablen konvertieren möchten. Sie können dann in nachfolgenden Aktionen in Ihrem Workflow auf die Ausgabevariablen verweisen. Weitere Informationen zu Variablen in CodeCatalyst finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Wenn Ihre Antwort-Payload beispielsweise wie folgt aussieht:

```
responsePayload = {
  "name": "Saanvi",
  "location": "Seattle",
  "department": {
    "company": "Amazon",
    "team": "AWS"
  }
}
```

... und deine Antwortfilter sehen so aus:

```
Configuration:
  ...
  ResponseFilters: '{"name": ".name", "company": ".department.company"}'
```

... dann generiert die Aktion die folgenden Ausgangsvariablen:


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Name  |  Saanvi  | 
|  company  |  Amazon  | 

Sie können dann in nachfolgenden Aktionen auf die `company` Variablen `name` und verweisen.

Wenn Sie keine Schlüssel in angeben`ResponseFilters`, konvertiert die Aktion jeden Schlüssel der obersten Ebene in der Lambda-Antwort in eine Ausgabevariable. Weitere Informationen finden Sie unter [Variablen 'AWS Lambda aufrufen'](lam-invoke-action-variables.md).

Erwägen Sie die Verwendung von Antwortfiltern, um die generierten Ausgabevariablen auf diejenigen zu beschränken, die Sie tatsächlich verwenden möchten.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Antwortfilter“ — optional**

## Outputs
<a name="lam.invoke.outputs"></a>

(*LambdaInvoke*/**Outputs**)

(Optional)

Definiert die Daten, die von der Aktion während eines Workflow-Laufs ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts
<a name="lam.invoke.outputs.artifacts"></a>

(*LambdaInvoke*/Outputs/**Artifacts**)

(Optional)

Geben Sie die durch die Aktion generierten Artefakte an. Sie können diese Artefakte als Eingabe in anderen Aktionen referenzieren.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte/ Name des Build-Artefakts**

## Name
<a name="lam.invoke.outputs.artifacts.name"></a>

(*LambdaInvoke*/Outputs/Artifacts/**Name**)

(Optional)

Geben Sie den Namen des Artefakts an, das die Lambda-Antwortnutzlast enthält, die von der Lambda-Funktion zurückgegeben wird. Der Standardwert ist `lambda_artifacts`. Wenn Sie kein Artefakt angeben, kann die Payload der Lambda-Antwort in den Protokollen der Aktion angezeigt werden, die auf der Registerkarte **Protokolle** für die Aktion in der Konsole verfügbar sind. CodeCatalyst Weitere Informationen zum Anzeigen von Protokollen finden Sie unter [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

**Entsprechende Benutzeroberfläche: Gibt die Registerkarte „Artifacts/Name des Build-Artefakts“ aus**

## Files
<a name="lam.invoke.outputs.artifacts.files"></a>

(*LambdaInvoke*/Outputs/Artifacts/**Files**)

(Optional)

Geben Sie die Dateien an, die in das Artefakt aufgenommen werden sollen. Sie müssen angeben, `lambda-response.json` dass die Payload-Datei für die Lambda-Antwort eingeschlossen wird.

**Entsprechende Benutzeroberfläche: Gibt die Tab/Artifacts/Dateien aus, die vom Build erzeugt wurden**

# Ändern einer Amazon ECS-Aufgabendefinition
<a name="render-ecs-action"></a>

In diesem Abschnitt wird beschrieben, wie Sie das `image` Feld in einer [Aufgabendefinitionsdatei](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) von Amazon Elastic Container Service (Amazon ECS) mithilfe eines CodeCatalyst Workflows aktualisieren. Um dies zu erreichen, müssen Sie Ihrem Workflow die Aktion **Render Amazon ECS Aufgabendefinition** hinzufügen. Diese Aktion aktualisiert das Image-Feld in der Aufgabendefinitionsdatei mit einem Docker-Image-Namen, der von Ihrem Workflow zur Laufzeit bereitgestellt wird.

**Anmerkung**  
Sie können diese Aktion auch verwenden, um das `environment` Feld der Aufgabendefinition mit Umgebungsvariablen zu aktualisieren.

**Topics**
+ [

## Wann sollte diese Aktion verwendet werden
](#render-ecs-action-when-to-use)
+ [

## So funktioniert die Aktion „Amazon ECS-Aufgabendefinition rendern“
](#render-ecs-action-how-it-works)
+ [

## Von der Aktion „Amazon ECS-Aufgabendefinition rendern“ verwendetes Runtime-Image
](#render-ecs-action-runtime)
+ [

# Beispiel: Ändern Sie eine Amazon ECS-Taskdef
](render-ecs-action-example-workflow.md)
+ [

# Aktion „Amazon ECS-Aufgabendefinition rendern“ hinzufügen
](render-ecs-action-add.md)
+ [

# Die aktualisierte Aufgabendefinitionsdatei anzeigen
](render-ecs-action-view.md)
+ [

# Variablen „Amazon ECS-Aufgabendefinition rendern“
](render-ecs-action-variables.md)
+ [

# Aktion 'Amazon ECS-Aufgabendefinition rendern' YAML
](render-ecs-action-ref.md)

## Wann sollte diese Aktion verwendet werden
<a name="render-ecs-action-when-to-use"></a>

Verwenden Sie diese Option, wenn Sie über einen Workflow verfügen, der ein Docker-Image mit dynamischen Inhalten wie einer Commit-ID oder einem Zeitstempel erstellt und markiert. 

Verwenden Sie diese Aktion nicht, wenn Ihre Aufgabendefinitionsdatei einen Bildwert enthält, der immer gleich bleibt. In diesem Fall können Sie den Namen Ihres Bilds manuell in die Aufgabendefinitionsdatei eingeben.

## So funktioniert die Aktion „Amazon ECS-Aufgabendefinition rendern“
<a name="render-ecs-action-how-it-works"></a>

Sie müssen die **Amazon ECS-Aufgabendefinitionsaktion rendern** mit den Aktionen **Build** und **Deploy to Amazon ECS** in Ihrem Workflow verwenden. Zusammen funktionieren diese Aktionen wie folgt:

1. Die **Build-Aktion** erstellt Ihr Docker-Image und kennzeichnet es mit einem Namen, einer Commit-ID, einem Zeitstempel oder einem anderen dynamischen Inhalt. Ihre Build-Aktion könnte beispielsweise so aussehen:

   ```
   MyECSWorkflow
     Actions:
       BuildAction:
         Identifier: aws/build@v1
         ...
         Configuration:
           Steps:
           # Build, tag, and push the Docker image...
             - Run: docker build -t MyDockerImage:${WorkflowSource.CommitId} .
             ...
   ```

   Im vorherigen Code gibt die `docker build -t` Direktive an, das Docker-Image zu erstellen und es zur Laufzeit der Aktion mit der Commit-ID zu kennzeichnen. Der generierte Image-Name könnte so aussehen:

   `MyDockerImage:a37bd7e`

1. Die Aktion **„Amazon ECS-Aufgabendefinition rendern**“ fügt Ihrer Aufgabendefinitionsdatei den dynamisch generierten Imagenamen wie folgt hinzu: `MyDockerImage:a37bd7e`

   ```
   {
       "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
       "containerDefinitions": [
           {
               "name": "codecatalyst-ecs-container",
               "image":  MyDockerImage:a37bd7e, 
               "essential": true,
               ...
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ]
           }
       ],
   ...
   }
   ```

   Optional können Sie auch festlegen, dass die Aktion **„Amazon ECS-Aufgabendefinition rendern**“ der Aufgabendefinition Umgebungsvariablen wie folgt hinzufügt:

   ```
   {
     "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
     "containerDefinitions": [
       {
         "name": "codecatalyst-ecs-container",
         "image":  MyDockerImage:a37bd7e,
         ...
         "environment": [
           {
             name": "ECS_LOGLEVEL",
             value": "info"
           }
         ]
       }
     ],
   ...
   }
   ```

   Weitere Informationen zu Umgebungsvariablen finden Sie unter [Spezifizieren von Umgebungsvariablen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html) im *Amazon Elastic Container Service Developer Guide*.

1. Die Aktion In **Amazon ECS bereitstellen** registriert die aktualisierte Aufgabendefinitionsdatei bei Amazon ECS. Durch die Registrierung der aktualisierten Aufgabendefinitionsdatei wird das neue Image `MyDockerImage:a37bd7e` in Amazon ECS bereitgestellt.

## Von der Aktion „Amazon ECS-Aufgabendefinition rendern“ verwendetes Runtime-Image
<a name="render-ecs-action-runtime"></a>

Die Aktion **„Amazon ECS-Aufgabendefinition rendern**“ wird auf einem [Image vom November 2022](build-images.md#build.previous-image) ausgeführt. Weitere Informationen finden Sie unter [Aktive Bilder](build-images.md#build-curated-images).

# Beispiel: Ändern Sie eine Amazon ECS-Taskdef
<a name="render-ecs-action-example-workflow"></a>

Im Folgenden finden Sie ein Beispiel für einen vollständigen Workflow, der die **Aufgabendefinitionsaktion Amazon ECS rendern** sowie die Aktionen Build und Deploy umfasst. Der Zweck des Workflows besteht darin, ein Docker-Image zu erstellen und in Ihrem Amazon ECS-Cluster bereitzustellen. Der Workflow besteht aus den folgenden Bausteinen, die nacheinander ausgeführt werden:
+ Ein **Trigger** — Dieser Trigger startet die Workflow-Ausführung automatisch, wenn Sie eine Änderung an Ihr Quell-Repository übertragen. Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md). 
+ Eine **Build-Aktion** (`BuildDocker`) — Beim Auslösen erstellt die Aktion das Docker-Image mithilfe der Dockerfile, kennzeichnet es mit einer Commit-ID und überträgt das Image an Amazon ECR. Weitere Informationen zur Build-Aktion finden Sie unter. [Bauen mit Workflows](build-workflow-actions.md)
+ Eine **Amazon ECS-Aufgabendefinitionsaktion rendern** (`RenderTaskDef`) — Nach Abschluss der Build-Aktion aktualisiert diese Aktion ein `taskdef.json` vorhandenes Objekt im Stammverzeichnis Ihres Quell-Repositorys mit einem `image` Feldwert, der die richtige Commit-ID enthält. Sie speichert die aktualisierte Datei unter einem neuen Dateinamen (`task-definition-random-string.json`) und erstellt dann ein Ausgabeartefakt, das diese Datei enthält. Die Renderaktion generiert außerdem eine Variable namens `task-definition` und setzt sie auf den Namen der neuen Aufgabendefinitionsdatei. Das Artefakt und die Variable werden für die Aktion Deploy verwendet, die als Nächstes folgt.
+ Eine Aktion „In **Amazon ECS bereitstellen**“ (`DeployToECS`) — Nach Abschluss der Aktion **„Amazon ECS-Aufgabendefinition rendern**“ sucht die Aktion „In **Amazon ECS bereitstellen“ nach** dem von der Renderaktion generierten Ausgabeartefakt (`TaskDefArtifact`), findet die darin enthaltene `task-definition-random-string.json` Datei und registriert sie bei Ihrem Amazon ECS-Service. Der Amazon ECS-Service folgt dann den Anweisungen in der `task-definition-random-string.json` Datei, um Amazon ECS-Aufgaben — und zugehörige Docker-Image-Container — in Ihrem Amazon ECS-Cluster auszuführen. 

```
Name: codecatalyst-ecs-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  BuildDocker:
    Identifier: aws/build@v1
    Environment:
      Name: codecatalyst-ecs-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-ecs-build-role
    Inputs:
      Variables:
        - Name: REPOSITORY_URI
          Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
        - Name: IMAGE_TAG
          Value: ${WorkflowSource.CommitId}
    Configuration:
      Steps:
        #pre_build:
        - Run: echo Logging in to Amazon ECR...
        - Run: aws --version
        - Run: aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-2.amazonaws.com
        #build:
        - Run: echo Build started on `date`
        - Run: echo Building the Docker image...
        - Run: docker build -t $REPOSITORY_URI:latest .
        - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
        #post_build:
        - Run: echo Build completed on `date`
        - Run: echo Pushing the Docker images...
        - Run: docker push $REPOSITORY_URI:latest
        - Run: docker push $REPOSITORY_URI:$IMAGE_TAG
        
  RenderTaskDef:
    DependsOn: 
      - BuildDocker
    Identifier: aws/ecs-render-task-definition@v1
    Inputs:
      Variables:
        - Name: REPOSITORY_URI
          Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
        - Name: IMAGE_TAG
          Value: ${WorkflowSource.CommitId}
    Configuration:      
      task-definition: taskdef.json
      container-definition-name: codecatalyst-ecs-container
      image: $REPOSITORY_URI:$IMAGE_TAG 
    # The output artifact contains the updated task definition file. 
    # The new file is prefixed with 'task-definition'.
    # The output variable is set to the name of the updated task definition file. 
    Outputs:
      Artifacts:
        - Name: TaskDefArtifact
          Files: 
            - "task-definition*"
      Variables:
        - task-definition
        
  DeployToECS:
    Identifier: aws/ecs-deploy@v1
    Environment:
      Name: codecatalyst-ecs-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-ecs-deploy-role
    #Input artifact contains the updated task definition file.
    Inputs:
      Sources: []
      Artifacts:
        - TaskDefArtifact
    Configuration:
      region: us-east-2
      cluster: codecatalyst-ecs-cluster
      service: codecatalyst-ecs-service
      task-definition: ${RenderTaskDef.task-definition}
```

# Aktion „Amazon ECS-Aufgabendefinition rendern“ hinzufügen
<a name="render-ecs-action-add"></a>

 Verwenden Sie die folgenden Anweisungen, um Ihrem Workflow die Aktion **„Amazon ECS rendern“ -Aufgabendefinition** hinzuzufügen. 

**Voraussetzung**  
Bevor Sie beginnen, stellen Sie sicher, dass Sie über einen Workflow verfügen, der eine Build-Aktion enthält, die dynamisch ein Docker-Image generiert. Einzelheiten finden Sie im vorherigen [Beispiel-Workflow](render-ecs-action-example-workflow.md).

------
#### [ Visual ]

**Um die Aktion „Amazon ECS-Aufgabendefinition rendern“ mit dem visuellen 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 oben links **\$1 Aktionen**, um den Aktionskatalog zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion **„Amazon ECS-Aufgabendefinition rendern**“ und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **„Amazon ECS-Aufgabendefinition rendern**“. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Füllen Sie auf den Registerkarten **Eingaben** und **Konfiguration** die Felder nach Ihren Bedürfnissen aus. Eine Beschreibung der einzelnen Felder finden Sie unter[Aktion 'Amazon ECS-Aufgabendefinition rendern' YAML](render-ecs-action-ref.md). Diese Referenz enthält detaillierte Informationen zu jedem Feld (und dem entsprechenden YAML-Eigenschaftswert), wie es sowohl im YAML- als auch im visuellen Editor angezeigt wird.

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 die Aktion „Amazon ECS-Aufgabendefinition rendern“ mit dem YAML-Editor hinzuzufügen**

1. [Öffnen Sie die Konsole unter https://codecatalyst.aws/ CodeCatalyst .](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. Wählen Sie links oben **\$1 Aktionen, um den Aktionskatalog** zu öffnen.

1. Wählen Sie in der Drop-down-Liste **Amazon** aus CodeCatalyst.

1. Suchen Sie nach der Aktion **„Amazon ECS-Aufgabendefinition rendern**“ und führen Sie einen der folgenden Schritte aus:
   + Wählen Sie das Pluszeichen (**\$1**), um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

     Oder
   + Wählen Sie **„Amazon ECS-Aufgabendefinition rendern**“. Das Dialogfeld mit den Aktionsdetails wird angezeigt. In diesem Dialogfeld:
     + (Optional) Wählen Sie „**Quelltext** [anzeigen“, um den Quellcode der Aktion](workflows-view-source.md#workflows-view-source.title) anzuzeigen.
     + Wählen Sie **Zum Workflow** hinzufügen, um die Aktion zum Workflow-Diagramm hinzuzufügen und den zugehörigen Konfigurationsbereich zu öffnen.

1. Ändern Sie die Eigenschaften im YAML-Code nach Ihren Bedürfnissen. Eine Erläuterung der einzelnen verfügbaren Eigenschaften finden Sie in der[Aktion 'Amazon ECS-Aufgabendefinition rendern' YAML](render-ecs-action-ref.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**.

------

**Nächste Schritte**

Nachdem Sie die Render-Aktion hinzugefügt haben, fügen Sie Ihrem Workflow die Aktion **Deploy to Amazon ECS** hinzu, indem Sie den Anweisungen unter folgen[Bereitstellung auf Amazon ECS mit einem Workflow](deploy-action-ecs.md). Gehen Sie beim Hinzufügen der Bereitstellungsaktion wie folgt vor:

1. Wählen Sie auf der Registerkarte „**Eingaben**“ der Aktion „Bereitstellen“ unter **Artefakte — optional** das Artefakt aus, das durch die Renderaktion generiert wurde. Sie enthält die aktualisierte Aufgabendefinitionsdatei.

   Weitere Informationen zu Artefakten finden Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

1. Geben Sie auf der Registerkarte **Konfiguration** der Bereitstellungsaktion im Feld **Aufgabendefinition** die folgende Aktionsvariable an: `${action-name.task-definition}` wobei der Name Ihrer Renderaktion *action-name* steht, zum Beispiel`RenderTaskDef`. Die Renderaktion setzt diese Variable auf den neuen Namen der Aufgabendefinitionsdatei.

   Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

   Weitere Informationen zur Konfiguration der Bereitstellungsaktion finden Sie im vorherigen [Beispiel-Workflow](render-ecs-action-example-workflow.md).

# Die aktualisierte Aufgabendefinitionsdatei anzeigen
<a name="render-ecs-action-view"></a>

Sie können den Namen und den Inhalt der aktualisierten Aufgabendefinitionsdatei einsehen.

**Um den Namen der aktualisierten Aufgabendefinitionsdatei anzuzeigen, nachdem sie von der Aktion **Amazon ECS-Aufgabendefinition rendern** verarbeitet wurde.**

1. Suchen Sie den Lauf, der eine abgeschlossene Renderaktion enthält:

   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 einen Lauf aus, der die abgeschlossene Renderaktion beinhaltet.

1. Wählen Sie im Workflow-Diagramm die Renderaktion aus.

1. Wählen Sie **Ausgaben** aus.

1. Wählen Sie **Variablen**.

1. Der Name der Aufgabendefinitionsdatei wird angezeigt. Er sieht ähnlich aus wie`task-definition--259-0a2r7gxlTF5X-.json`.

**Um den Inhalt der aktualisierten Aufgabendefinitionsdatei anzuzeigen**

1. Suchen Sie den Lauf, der eine abgeschlossene Renderaktion enthält:

   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 einen Lauf aus, der die abgeschlossene Renderaktion beinhaltet.

1. Wählen Sie in der Workflow-Ausführung oben neben **Visual** und **YAML** die Option **Workflow-Ausgaben** aus.

1. Wählen Sie im Abschnitt **Artefakte** neben dem Artefakt, das die aktualisierte Aufgabendefinitionsdatei enthält, die Option **Herunterladen** aus. Für dieses Artefakt wird die Spalte **Produziert von** auf den Namen Ihrer Renderaktion gesetzt.

1. Öffnen Sie die ZIP-Datei, um die JSON-Datei mit der Aufgabendefinition anzuzeigen.

# Variablen „Amazon ECS-Aufgabendefinition rendern“
<a name="render-ecs-action-variables"></a>

Die Aktion **„Amazon ECS-Aufgabendefinition rendern**“ erzeugt und setzt zur Laufzeit die folgenden Variablen. Diese werden als *vordefinierte Variablen* bezeichnet.

Hinweise zum Verweisen auf diese Variablen in einem Workflow finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).


| Key (Schlüssel) | Value (Wert) | 
| --- | --- | 
|  Aufgabendefinition  |  Der Name der Aufgabendefinitionsdatei, die durch die **Amazon ECS-Aufgabendefinitionsaktion Rendern** aktualisiert wurde. Der Name hat folgendes Format: `task-definition-random-string.json`. Beispiel: `task-definition--259-0a2r7gxlTF5Xr.json`  | 

# Aktion 'Amazon ECS-Aufgabendefinition rendern' YAML
<a name="render-ecs-action-ref"></a>

Im Folgenden finden Sie die YAML-Definition der **Aufgabendefinitionsaktion „Amazon ECS rendern**“. Informationen zur Verwendung dieser Aktion finden Sie unter[Ändern einer Amazon ECS-Aufgabendefinition](render-ecs-action.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 action definition starts here.   
  ECSRenderTaskDefinition\$1nn: 
    Identifier: aws/ecs-render-task-definition@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - task-definition-artifact
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2
    Configuration 
      task-definition: task-definition-path
      container-definition-name: container-definition-name
      image: docker-image-name
      environment-variables:
        - variable-name-1=variable-value-1
        - variable-name-2=variable-value-2
    Outputs:
      Artifacts:
        - Name: TaskDefArtifact
          Files: "task-definition*"
      Variables:
        - task-definition
```

## ECSRenderTaskDefinition
<a name="render.ecs.name"></a>

(Erforderlich)

Geben Sie den Namen der Aktion an. Alle Aktionsnamen müssen innerhalb des Workflows eindeutig sein. Aktionsnamen 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 Aktionsnamen zuzulassen.

Standard: `ECSRenderTaskDefinition_nn`.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aktionsname“**

## Identifier
<a name="render.ecs.identifier"></a>

(*ECSRenderTaskDefinition*/**Identifier**)

(Erforderlich)

Identifiziert die Aktion. Ändern Sie diese Eigenschaft nur, wenn Sie die Version ändern möchten. Weitere Informationen finden Sie unter [Angabe der zu verwendenden Aktionsversion](workflows-action-versions.md).

Standard: `aws/ecs-render-task-definition@v1`.

**Entsprechende Benutzeroberfläche: Workflow-Diagram/ ECSRenderTaskDefinition \$1nn/ aws/ @v1 label ecs-render-task-definition**

## DependsOn
<a name="render.ecs.dependson"></a>

(*ECSRenderTaskDefinition*/**DependsOn**)

(Optional)

Geben Sie eine Aktion, eine Aktionsgruppe oder ein Gate an, die erfolgreich ausgeführt werden müssen, damit diese Aktion ausgeführt werden kann.

Weitere Hinweise zur Funktion „Hängt davon ab“ finden Sie unter. [Aktionen sequenzieren](workflows-depends-on.md)

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Hängt davon ab**“ — optional

## Compute
<a name="render.ecs.computename"></a>

(*ECSRenderTaskDefinition*/**Compute**)

(Optional)

Die Rechen-Engine, mit der Ihre Workflow-Aktionen ausgeführt wurden. 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).

Entsprechende Benutzeroberfläche: *keine*

## Type
<a name="render.ecs.computetype"></a>

(*ECSRenderTaskDefinition*/Compute/**Type**)

([Compute](#render.ecs.computename)Erforderlich, falls enthalten)

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: Registerkarte „**Konfiguration/Berechnungstyp**“

## Fleet
<a name="render.ecs.computefleet"></a>

(*ECSRenderTaskDefinition*/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`

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„Flotte **berechnen**“

## Timeout
<a name="render.ecs.timeout"></a>

(*ECSRenderTaskDefinition*/**Timeout**)

(Optional)

Geben Sie an, wie lange die Aktion in Minuten (YAML-Editor) oder Stunden und Minuten (visueller Editor) ausgeführt werden kann, bevor die Aktion CodeCatalyst beendet wird. Das Minimum beträgt 5 Minuten und das Maximum ist unter beschrieben[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Das Standard-Timeout entspricht dem maximalen Timeout.

**Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration/Timeout“ — optional**

## Inputs
<a name="render.ecs.inputs"></a>

(*ECSRenderTaskDefinition*/**Inputs**)

(Optional)

Der `Inputs` Abschnitt definiert die Daten, die während einer Workflow-Ausführung `ECSRenderTaskDefinition` benötigt werden.

**Anmerkung**  
Pro **Render Amazon ECS-Aufgabendefinitionsaktion** ist nur eine Eingabe (entweder eine Quelle oder ein Artefakt) zulässig. Variablen werden auf diese Summe nicht angerechnet.

Entsprechende Benutzeroberfläche: Registerkarte „**Eingaben**“

## Sources
<a name="render.ecs.inputs.sources"></a>

(*ECSRenderTaskDefinition*/Inputs/**Sources**)

(Erforderlich, wenn Ihre Aufgabendefinitionsdatei in einem Quell-Repository gespeichert ist)

Wenn Ihre Aufgabendefinitionsdatei in einem Quell-Repository gespeichert ist, geben Sie die Bezeichnung dieses Quell-Repositorys an. Derzeit ist das einzige unterstützte Label`WorkflowSource`.

Wenn Ihre Aufgabendefinitionsdatei nicht in einem Quell-Repository enthalten ist, muss sie sich in einem Artefakt befinden, das durch eine andere Aktion generiert wurde.

Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).

**Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„Quellen“ — optional**

## Artifacts - input
<a name="render.ecs.inputs.artifacts"></a>

(*ECSRenderTaskDefinition*/Inputs/**Artifacts**)

(Erforderlich, wenn Ihre Aufgabendefinitionsdatei in einem [Ausgabeartefakt](workflows-working-artifacts-output.md) einer vorherigen Aktion gespeichert ist)

Wenn die Aufgabendefinitionsdatei, die Sie bereitstellen möchten, in einem Artefakt enthalten ist, das durch eine vorherige Aktion generiert wurde, geben Sie dieses Artefakt hier an. Wenn Ihre Aufgabendefinitionsdatei nicht in einem Artefakt enthalten ist, muss sie sich in Ihrem Quell-Repository befinden.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter. [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md)

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Artefakte“ — optional**

## Variables - input
<a name="render.ecs.inputs.variables"></a>

(*ECSRenderTaskDefinition*/Inputs/**Variables**)

(Erforderlich)

Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Eingaben“/„**Variablen“ — optional**

## Configuration
<a name="render.ecs.configuration"></a>

(*ECSRenderTaskDefinition*/**Configuration**)

(Erforderlich)

Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“

## task-definition
<a name="render.ecs.task.definition"></a>

(*ECSRenderTaskDefinition*/Configuration/**task-definition**)

(Erforderlich)

Geben Sie den Pfad zu einer vorhandenen Aufgabendefinitionsdatei an. Wenn sich die Datei in Ihrem Quell-Repository befindet, ist der Pfad relativ zum Stammordner des Quell-Repositorys. Wenn sich Ihre Datei in einem Artefakt aus einer früheren Workflow-Aktion befindet, ist der Pfad relativ zum Artefakt-Stammordner. Weitere Informationen zu Aufgabendefinitionsdateien finden Sie unter [Aufgabendefinitionen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) im *Amazon Elastic Container Service Developer Guide*.

Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration/Aufgabendefinition**“

## container-definition-name
<a name="render.ecs.container.name"></a>

(*ECSRenderTaskDefinition*/Configuration/**container-definition-name**)

(Erforderlich)

Geben Sie den Namen des Containers an, auf dem Ihr Docker-Image ausgeführt werden soll. Sie finden diesen Namen im `name` Feld`containerDefinitions`, in Ihrer Aufgabendefinitionsdatei. Weitere Informationen finden Sie unter [Name](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_name) im *Amazon Elastic Container Service Developer Guide*.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Name des **Containers**

## image
<a name="render.ecs.image"></a>

(*ECSRenderTaskDefinition*/Configuration/**image**)

(Erforderlich)

Geben Sie den Namen des Docker-Images an, das die Aktion **Amazon ECS-Aufgabendefinition rendern** zu Ihrer Aufgabendefinitionsdatei hinzufügen soll. Die Aktion fügt diesen Namen dem `image` Feld`containerDefinitions`, in Ihrer Aufgabendefinitionsdatei hinzu. Wenn in dem `image` Feld bereits ein Wert vorhanden ist, wird er von der Aktion überschrieben. Sie können Variablen in den Bildnamen aufnehmen.

Beispiele:

Wenn Sie angeben`MyDockerImage:${WorkflowSource.CommitId}`, wird die Aktion der Aufgabendefinitionsdatei hinzugefügt`MyDockerImage:commit-id`, in der sich eine Commit-ID *commit-id* befindet, die zur Laufzeit vom Workflow generiert wird.

Wenn Sie angeben`my-ecr-repo/image-repo:$(date +%m-%d-%y-%H-%m-%s)`, fügt die Aktion *my-ecr-repo* /image-repo: *date \$1%m-%d-%y-%H-%m-%s* zur Aufgabendefinitionsdatei hinzu. Dabei *my-ecr-repo* handelt es sich um den URI einer Amazon Elastic Container Registry (ECR) und um einen Zeitstempel in dem Format, das zur Laufzeit durch den Workflow `month-day-year-hour-minute-second` generiert *date \$1%m-%d-%y-%H-%m-%s* wird.

Weitere Informationen zu `image` diesem Bereich finden Sie unter [Bild](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_image) im *Amazon Elastic Container Service Developer Guide*. Weitere Informationen zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/Name **des Images**

## environment-variables
<a name="render.ecs.environment.variables"></a>

(*ECSRenderTaskDefinition*/Configuration/**environment-variables**)

(Erforderlich)

Geben Sie die Umgebungsvariablen an, die die Aktion **„Amazon ECS-Aufgabendefinition rendern**“ zu Ihrer Aufgabendefinitionsdatei hinzufügen soll. Die Aktion fügt die Variablen dem `environment` Feld`containerDefinitions`, in Ihrer Aufgabendefinitionsdatei hinzu. Wenn in der Datei bereits Variablen vorhanden sind, überschreibt die Aktion die Werte vorhandener Variablen und fügt alle neuen Variablen hinzu. Weitere Informationen zu Amazon ECS-Umgebungsvariablen finden Sie unter [Spezifizieren von Umgebungsvariablen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html) im *Amazon Elastic Container Service Developer Guide*.

Entsprechende Benutzeroberfläche: Registerkarte „Konfiguration“/„**Umgebungsvariablen“ — optional**

## Outputs
<a name="render.ecs.outputs"></a>

(*ECSRenderTaskDefinition*/**Outputs**)

(Erforderlich)

Definiert die Daten, die von der Aktion während einer Workflow-Ausführung ausgegeben werden.

Entsprechende Benutzeroberfläche: Registerkarte „**Ausgaben**“

## Artifacts
<a name="render.ecs.outputs.artifacts"></a>

(*ECSRenderTaskDefinition*/Outputs/**Artifacts**)

(Erforderlich)

Geben Sie die durch die Aktion generierten Artefakte an. Sie können diese Artefakte als Eingabe in anderen Aktionen referenzieren.

Weitere Informationen zu Artefakten, einschließlich Beispielen, finden Sie unter[Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte**

## Name
<a name="render.ecs.outputs.artifacts.name"></a>

(*ECSRenderTaskDefinition*/Outputs/Artifacts/**Name**)

(Erforderlich)

Geben Sie den Namen des Artefakts an, das die aktualisierte Aufgabendefinitionsdatei enthalten soll. Der Standardwert ist `MyTaskDefinitionArtifact`. Anschließend müssen Sie dieses Artefakt als Eingabe für die Aktion **Deploy to Amazon ECS** angeben. Informationen darüber, wie Sie dieses Artefakt als Eingabe zur Aktion **Deploy to Amazon ECS** hinzufügen, finden Sie unter[Beispiel: Ändern Sie eine Amazon ECS-Taskdef](render-ecs-action-example-workflow.md).

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artifacte/Name**

## Files
<a name="render.ecs.outputs.artifacts.files"></a>

(*ECSRenderTaskDefinition*/Outputs/Artifacts/**Files**)

(Erforderlich)

Geben Sie die Dateien an, die in das Artefakt aufgenommen werden sollen. Sie müssen angeben, `task-definition-*` dass die aktualisierte Aufgabendefinitionsdatei, die mit beginnt`task-definition-`, eingeschlossen wird.

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Artefakte/Dateien**

## Variables
<a name="render.ecs.outputs.variables"></a>

(*ECSRenderTaskDefinition*/Outputs/**Variables**)

(Erforderlich)

Geben Sie den Namen einer Variablen an, die durch die Renderaktion festgelegt werden soll. Bei der Renderaktion wird der Wert dieser Variablen auf den Namen der aktualisierten Aufgabendefinitionsdatei gesetzt (z. B.`task-definition-random-string.json`). Anschließend müssen Sie diese Variable in der Eigenschaft **Aufgabendefinition** (visueller Editor) oder `task-definition` (Yaml-Editor) der Aktion **Deploy to Amazon ECS** angeben. Informationen zum Hinzufügen dieser Variablen zur Aktion **Deploy to Amazon ECS** finden Sie unter[Beispiel: Ändern Sie eine Amazon ECS-Taskdef](render-ecs-action-example-workflow.md).

Standard: `task-definition`

**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Variablen/Feld Name**

# Verwenden von Variablen in Workflows
<a name="workflows-working-with-variables"></a>

 Eine *Variable* ist ein Schlüssel-Wert-Paar, das Informationen enthält, auf die Sie in Ihrem CodeCatalyst Amazon-Workflow verweisen können. Der Wertteil der Variablen wird bei der Ausführung des Workflows durch einen tatsächlichen Wert ersetzt.

Es gibt zwei Arten von Variablen, die Sie in einem Workflow verwenden können:
+ **Benutzerdefinierte Variablen** — Dies sind Schlüssel-Wert-Paare, die Sie definieren.
+ **Vordefinierte Variablen** — Dies sind Schlüssel-Wert-Paare, die von einem Workflow automatisch ausgegeben werden. Sie müssen sie nicht definieren.

Weitere Informationen zu Workflows finden Sie unter [Erstellen, Testen und Bereitstellen mit WorkflowsMit Workflows erstellen, testen und bereitstellen](workflow.md).

**Anmerkung**  
CodeCatalyst unterstützt auch [GitHub Ausgabeparameter](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter), die sich wie Variablen verhalten und in anderen Aktionen referenziert werden können. Weitere Informationen finden Sie unter [GitHub Ausgabeparameter exportieren](integrations-github-action-export.md) und [Referenzieren von GitHub Ausgabeparametern](integrations-github-action-referencing.md)

**Topics**
+ [

# Verwenden von benutzerdefinierten Variablen
](workflows-using-variables.md)
+ [

# Verwenden vordefinierter Variablen
](workflows-using-predefined-variables.md)

# Verwenden von benutzerdefinierten Variablen
<a name="workflows-using-variables"></a>

*Benutzerdefinierte Variablen* sind Schlüssel-Wert-Paare, die Sie definieren. Es gibt zwei Arten:
+ **Klartext-Variablen oder einfach **Variablen**** — Dies sind Schlüssel-Wert-Paare, die Sie in der Workflow-Definitionsdatei im Klartext definieren.
+ **Secrets** — Dies sind Schlüssel-Wert-Paare, die Sie auf einer separaten **Secrets-Seite** der CodeCatalyst Amazon-Konsole definieren. Der *Schlüssel* (Name) ist ein öffentliches Label, und der *Wert* enthält die Informationen, die Sie geheim halten möchten. Sie geben nur den Schlüssel in der Workflow-Definitionsdatei an. Verwenden Sie geheime Schlüssel anstelle von Kennwörtern und anderen vertraulichen Informationen in der Workflow-Definitionsdatei.

**Anmerkung**  
Der Kürze halber wird in diesem Leitfaden der Begriff *Variable* für *Klartext-Variable* verwendet.

Weitere Informationen zu Variablen finden Sie unter. [Verwenden von Variablen in Workflows](workflows-working-with-variables.md)

**Topics**
+ [

# Beispiele für Variablen
](workflows-working-with-variables-ex.md)
+ [

# Definition einer Variablen
](workflows-working-with-variables-define-input.md)
+ [

# Ein Geheimnis definieren
](workflows-working-with-variables-define-secret.md)
+ [

# Eine Variable exportieren, damit sie von anderen Aktionen verwendet werden kann
](workflows-working-with-variables-export-input.md)
+ [

# Verweisen auf eine Variable in der Aktion, die sie definiert
](workflows-working-with-variables-reference-input.md)
+ [

# Referenzieren einer Variablenausgabe durch eine andere Aktion
](workflows-working-with-variables-reference-action.md)
+ [

# Auf ein Geheimnis verweisen
](workflows-working-with-variables-reference-secret.md)

# Beispiele für Variablen
<a name="workflows-working-with-variables-ex"></a>

Die folgenden Beispiele zeigen, wie Variablen in der Workflow-Definitionsdatei definiert und referenziert werden.

Weitere Informationen zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Topics**
+ [

## Beispiel: Definieren einer Variablen mithilfe der Eigenschaft Inputs
](#workflows-working-with-variables-ex-define-inputs)
+ [

## Beispiel: Definieren einer Variablen mithilfe der Eigenschaft Steps
](#workflows-working-with-variables-ex-define-steps)
+ [

## Beispiel: Exportieren einer Variablen mithilfe der Outputs-Eigenschaft
](#workflows-working-with-variables-ex-export-outputs)
+ [

## Beispiel: Verweisen auf eine Variable, die in derselben Aktion definiert wurde
](#workflows-working-with-variables-ex-refer-current)
+ [

## Beispiel: Verweisen auf eine Variable, die in einer anderen Aktion definiert wurde
](#workflows-working-with-variables-ex-refer-other)
+ [

## Beispiel: Verweisen auf ein Geheimnis
](#workflows-working-with-variables-ex-refer-secret)

## Beispiel: Definieren einer Variablen mithilfe der Eigenschaft Inputs
<a name="workflows-working-with-variables-ex-define-inputs"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie zwei Variablen definieren, `VAR1` und`VAR2`, in einem `Inputs` Abschnitt.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Inputs:
      Variables:
      - Name: VAR1
        Value: "My variable 1"
      - Name: VAR2
        Value: "My variable 2"
```

## Beispiel: Definieren einer Variablen mithilfe der Eigenschaft Steps
<a name="workflows-working-with-variables-ex-define-steps"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie eine `DATE` Variable in dem `Steps` Abschnitt explizit definieren.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Configuration:    
      Steps:
        - Run: DATE=$(date +%m-%d-%y)
```

## Beispiel: Exportieren einer Variablen mithilfe der Outputs-Eigenschaft
<a name="workflows-working-with-variables-ex-export-outputs"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie zwei Variablen definieren `REPOSITORY-URI` und `TIMESTAMP` diese mithilfe des `Outputs` Abschnitts exportieren.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Inputs:
      Variables:
        - Name: REPOSITORY-URI
          Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
    Configuration:
      Steps:
        - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) 
    Outputs:
      Variables:
        - REPOSITORY-URI
        - TIMESTAMP
```

## Beispiel: Verweisen auf eine Variable, die in derselben Aktion definiert wurde
<a name="workflows-working-with-variables-ex-refer-current"></a>

Das folgende Beispiel zeigt Ihnen`MyBuildAction`, wie Sie eine `VAR1` Variable in angeben und dann in derselben Aktion darauf verweisen, indem Sie`$VAR1`.

```
Actions:
  MyBuildAction:
    Identifier: aws/build@v1
    Inputs:
      Variables:
        - Name: VAR1
          Value: my-value
    Configuration:
      Steps:
        - Run: $VAR1
```

## Beispiel: Verweisen auf eine Variable, die in einer anderen Aktion definiert wurde
<a name="workflows-working-with-variables-ex-refer-other"></a>

Das folgende Beispiel zeigt, wie Sie eine `TIMESTAMP` Variable in angeben`BuildActionA`, sie mithilfe der `Outputs` Eigenschaft exportieren und dann in `BuildActionB` using `${BuildActionA.TIMESTAMP}` darauf verweisen.

```
Actions:
  BuildActionA:
    Identifier: aws/build@v1
    Configuration:    
      Steps:
        - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) 
    Outputs:
      Variables:
        - TIMESTAMP
  BuildActionB:
    Identifier: aws/build@v1
    Configuration:
      Steps:
        - Run: docker build -t my-ecr-repo/image-repo:latest .      
        - Run: docker tag my-ecr-repo/image-repo:${BuildActionA.TIMESTAMP}
        
        # Specifying just '$TIMESTAMP' here will not work 
        # because TIMESTAMP is not a variable 
        # in the BuildActionB action.
```

## Beispiel: Verweisen auf ein Geheimnis
<a name="workflows-working-with-variables-ex-refer-secret"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie auf ein `my-password` Geheimnis verweisen. Das `my-password` ist der Schlüssel des Geheimnisses. Der Schlüssel dieses Geheimnisses und der entsprechende Kennwortwert müssen auf der Seite **Geheimnisse** der CodeCatalyst Konsole angegeben werden, bevor sie in der Workflow-Definitionsdatei verwendet werden können. Weitere Informationen finden Sie unter [Daten mithilfe von Geheimnissen maskieren](workflows-secrets.md).

```
Actions:
  BuildActionA:
    Identifier: aws/build@v1
    Configuration:    
      Steps:
        - Run: curl -u LiJuan:${Secrets.my-password} https://example.com
```

# Definition einer Variablen
<a name="workflows-working-with-variables-define-input"></a>

Sie können Variablen auf zwei Arten definieren:
+ Im `Inputs` Abschnitt einer Workflow-Aktion — siehe [So definieren Sie eine Variable im Abschnitt „Eingaben“](#workflows-to-define-variable-input)
+ Im `Steps` Abschnitt einer Workflow-Aktion — siehe [So definieren Sie eine Variable im Abschnitt „Schritte“](#workflows-to-define-variable-steps)
**Anmerkung**  
Die `Steps` Methode funktioniert nur mit den Aktionen CodeCatalyst Build, Test und **GitHub Actions**, da dies die einzigen Aktionen sind, die einen `Steps` Abschnitt enthalten.

Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md).

Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

------
#### [ Visual ]

**So definieren Sie eine Variable im Abschnitt „Eingaben“ (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 die Aktion aus, für die Sie die Variable setzen möchten.

1. Wählen Sie **Eingaben**.

1. Wählen Sie unter **Variablen — optional** die Option **Variable hinzufügen** aus, und gehen Sie dann wie folgt vor:

   Geben Sie eine Sequenz von name/value Paaren an, die die Eingabevariablen definieren, die Sie für die Aktion verfügbar machen möchten. Variablennamen 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 Variablennamen zuzulassen.

   Weitere Informationen zu Variablen, einschließlich Beispielen, finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.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 eine Variable im Abschnitt „Eingaben“ zu definieren (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 in einer Workflow-Aktion Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     Inputs:
       Variables:
         - Name: variable-name
           Value: variable-value
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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

------

------
#### [ Visual ]

**Um eine Variable im Abschnitt „Schritte“ zu definieren (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 die Aktion aus, für die Sie die Variable setzen möchten.

1. Wählen Sie **Konfiguration**.

1. Definieren Sie in **Shell-Befehlen** oder **GitHubActions YAML**, je nachdem, was verfügbar ist, eine Variable in den Aktionen`Steps`, entweder explizit oder implizit.
   + Um die Variable explizit zu definieren, fügen Sie sie in einen Bash-Befehl direkt in den Abschnitt ein. `Steps`
   + Um eine Variable implizit zu definieren, geben Sie sie in einer Datei an, auf die im Abschnitt der Aktion verwiesen wird. `Steps`

     Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für die Aktion.

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 eine Variable im Abschnitt „Schritte“ zu definieren (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. Definieren Sie in einer Workflow-Aktion eine Variable im `Steps` Abschnitt der Aktion, entweder explizit oder implizit.
   + Um die Variable explizit zu definieren, fügen Sie sie in einen Bash-Befehl direkt in den `Steps` Abschnitt ein.
   + Um eine Variable implizit zu definieren, geben Sie sie in einer Datei an, auf die im Abschnitt der Aktion verwiesen wird. `Steps`

     Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für die Aktion.

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

------

# Ein Geheimnis definieren
<a name="workflows-working-with-variables-define-secret"></a>

Sie definieren ein Geheimnis auf der Seite **Secrets** der CodeCatalyst Konsole. Weitere Informationen finden Sie unter [Daten mithilfe von Geheimnissen maskieren](workflows-secrets.md).

Sie könnten beispielsweise ein Geheimnis definieren, das wie folgt aussieht:
+ Name (Schlüssel): **my-password**
+ Wert: **^\$1H3\$1\$1b9**

Nachdem das Geheimnis definiert wurde, können Sie den Schlüssel (**my-password**) des Geheimnisses in der Workflow-Definitionsdatei angeben. Ein Beispiel für diese Vorgehensweise finden Sie unter [Beispiel: Verweisen auf ein Geheimnis](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret).

# Eine Variable exportieren, damit sie von anderen Aktionen verwendet werden kann
<a name="workflows-working-with-variables-export-input"></a>

Verwenden Sie die folgenden Anweisungen, um eine Variable aus einer Aktion zu exportieren, sodass Sie in anderen Aktionen darauf verweisen können.

Bevor Sie eine Variable exportieren, beachten Sie Folgendes:
+ Wenn Sie nur innerhalb der Aktion, in der sie definiert ist, auf die Variable verweisen müssen, müssen Sie sie nicht exportieren.
+ Nicht alle Aktionen unterstützen den Export von Variablen. Um festzustellen, ob Ihre Aktion diese Funktion unterstützt, führen Sie die folgenden Anweisungen für den visuellen Editor durch und prüfen Sie, ob die Aktion auf der Registerkarte **Ausgaben** eine Schaltfläche „**Variablen**“ enthält. Falls ja, wird der Export von Variablen unterstützt. 
+ Informationen zum Exportieren einer Variablen aus einer GitHub Aktion finden Sie unter[GitHub Ausgabeparameter exportieren](integrations-github-action-export.md).

Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Voraussetzung**  
Stellen Sie sicher, dass Sie die Variable definiert haben, die Sie exportieren möchten. Weitere Informationen finden Sie unter [Definition einer Variablen](workflows-working-with-variables-define-input.md).

------
#### [ Visual ]

**Um eine Variable zu exportieren (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 die Aktion aus, aus der Sie die Variable exportieren möchten.

1. Wählen Sie **Ausgaben** aus.

1. Wählen Sie unter **Variablen — optional** die Option **Variable hinzufügen** aus, und gehen Sie dann wie folgt vor:

   Geben Sie den Namen einer Variablen an, die die Aktion exportieren soll. Diese Variable muss bereits im `Steps` Abschnitt `Inputs` oder derselben Aktion definiert sein.

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 eine Variable zu exportieren (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 in der Aktion, aus der Sie die Variable exportieren möchten, Code hinzu, der dem folgenden ähnelt:

   ```
   action-name:
     Outputs:
       Variables:
         - Name: variable-name
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md).

1. (Optional) Wählen Sie **Validieren** aus, 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**.

------

# Verweisen auf eine Variable in der Aktion, die sie definiert
<a name="workflows-working-with-variables-reference-input"></a>

Verwenden Sie die folgenden Anweisungen, um in der Aktion, die sie definiert, auf eine Variable zu verweisen.

**Anmerkung**  
Informationen zum Verweisen auf eine durch eine GitHub Aktion generierte Variable finden Sie unter[Referenzieren von GitHub Ausgabeparametern](integrations-github-action-referencing.md).

Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Voraussetzung**  
Vergewissern Sie sich, dass Sie die Variable definiert haben, auf die Sie verweisen möchten. Weitere Informationen finden Sie unter [Definition einer Variablen](workflows-working-with-variables-define-input.md).

------
#### [ Visual ]

*Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.*

------
#### [ YAML ]

**Um in der Aktion, die sie definiert, auf eine Variable zu verweisen**

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 der CodeCatalyst Aktion, die die Variable definiert, auf die Sie verweisen möchten, die Variable mit der folgenden Bash-Syntax hinzu:

   ```
   $variable-name
   ```

   Beispiel:

   ```
   MyAction:
       Configuration:
         Steps:
           - Run: $variable-name
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md). Weitere Informationen finden Sie in den Referenzinformationen für Ihre Aktion im[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.

------

# Referenzieren einer Variablenausgabe durch eine andere Aktion
<a name="workflows-working-with-variables-reference-action"></a>

Verwenden Sie die folgenden Anweisungen, um auf Variablen zu verweisen, die von anderen Aktionen ausgegeben wurden.

**Anmerkung**  
 Informationen zum Verweisen auf eine Variablenausgabe aus einer GitHub Aktion finden Sie unter[Referenzieren von GitHub Ausgabeparametern](integrations-github-action-referencing.md).

Weitere Hinweise zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).

**Voraussetzung**  
Stellen Sie sicher, dass Sie die Variable exportiert haben, auf die Sie verweisen möchten. Weitere Informationen finden Sie unter [Eine Variable exportieren, damit sie von anderen Aktionen verwendet werden kann](workflows-working-with-variables-export-input.md).

------
#### [ Visual ]

*Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.*

------
#### [ YAML ]

**Um auf eine Variable zu verweisen, die von einer anderen Aktion ausgegeben wurde (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 in der CodeCatalyst Aktion mithilfe der folgenden Syntax einen Verweis auf die Variable hinzu:

   ```
   ${action-group-name.action-name.variable-name}
   ```

   Ersetzen Sie:
   + *action-group-name*mit dem Namen der Aktionsgruppe, die die Aktion enthält, die eine Variable ausgibt.
**Anmerkung**  
Sie können weglassen, *action-group-name* wenn es keine Aktionsgruppe gibt oder wenn die Variable durch eine Aktion in derselben Aktionsgruppe erzeugt wird.
   + *action-name*mit dem Namen der Aktion, die die Variable ausgibt.
   + *variable-name*mit dem Namen der Variablen.

   Beispiel:

   ```
   MySecondAction:
       Configuration:
         Steps:
           - Run: ${MyFirstAction.TIMESTAMP}
   ```

   Weitere Beispiele finden Sie unter [Beispiele für Variablen](workflows-working-with-variables-ex.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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.

------

# Auf ein Geheimnis verweisen
<a name="workflows-working-with-variables-reference-secret"></a>

Anweisungen zum Verweisen auf ein Geheimnis in der Workflow-Definitionsdatei finden Sie unter. [Verwenden eines Secrets](workflows-secrets.using.md)

Ein Beispiel finden Sie unter [Beispiel: Verweisen auf ein Geheimnis](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret).

# Verwenden vordefinierter Variablen
<a name="workflows-using-predefined-variables"></a>

*Vordefinierte Variablen* sind Schlüssel-Wert-Paare, die von einem Workflow automatisch ausgegeben und Ihnen zur Verwendung in Workflow-Aktionen zur Verfügung gestellt werden. 

Weitere Informationen zu Variablen finden Sie unter. [Verwenden von Variablen in Workflows](workflows-working-with-variables.md)

**Topics**
+ [

# Beispiele für die Referenzierung vordefinierter Variablen
](workflows-predefined-examples.md)
+ [

# Verweisen auf eine vordefinierte Variable
](workflows-working-with-variables-reference-output-vars.md)
+ [

# Ermitteln, welche vordefinierten Variablen Ihr Workflow ausgibt
](workflows-working-with-variables-determine-output-vars.md)
+ [

# Liste der vordefinierten Variablen
](workflow-ref-action-variables.md)

# Beispiele für die Referenzierung vordefinierter Variablen
<a name="workflows-predefined-examples"></a>

Die folgenden Beispiele zeigen, wie Sie in der Workflow-Definitionsdatei auf vordefinierte Variablen verweisen.

Weitere Informationen zu vordefinierten Variablen finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).

**Topics**
+ [

## Beispiel: Verweisen auf die vordefinierte CommitId Variable ""
](#workflows-working-with-variables-ex-refer-action)
+ [

## Beispiel: Verweisen auf die vordefinierte BranchName Variable ""
](#workflows-working-with-variables-ex-branch)

## Beispiel: Verweisen auf die vordefinierte CommitId Variable ""
<a name="workflows-working-with-variables-ex-refer-action"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie in der `MyBuildAction` Aktion auf die `CommitId` vordefinierte Variable verweisen. Die `CommitId` Variable wird automatisch von ausgegeben CodeCatalyst. Weitere Informationen finden Sie unter [Liste der vordefinierten Variablen](workflow-ref-action-variables.md).

Obwohl das Beispiel zeigt, dass die Variable in der Build-Aktion verwendet wird, können Sie sie `CommitId` in jeder beliebigen Aktion verwenden.

```
MyBuildAction:
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      Steps:
      #Build Docker image and tag it with a commit ID
        - Run: docker build -t image-repo/my-docker-image:latest .
        - Run: docker tag image-repo/my-docker-image:${WorkflowSource.CommitId}
```

## Beispiel: Verweisen auf die vordefinierte BranchName Variable ""
<a name="workflows-working-with-variables-ex-branch"></a>

Das folgende Beispiel zeigt Ihnen, wie Sie in der `CDKDeploy` Aktion auf die `BranchName` vordefinierte Variable verweisen. Die `BranchName` Variable wird automatisch von ausgegeben CodeCatalyst. Weitere Informationen finden Sie unter [Liste der vordefinierten Variablen](workflow-ref-action-variables.md).

Obwohl das Beispiel zeigt, dass die Variable in der **AWS CDK Bereitstellungsaktion** verwendet wird, können Sie sie `BranchName` in jeder beliebigen Aktion verwenden.

```
CDKDeploy:
    Identifier: aws/cdk-deploy@v2
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      StackName: app-stack-${WorkflowSource.BranchName}
```

# Verweisen auf eine vordefinierte Variable
<a name="workflows-working-with-variables-reference-output-vars"></a>

Sie können in jeder Aktion innerhalb eines CodeCatalyst Amazon-Workflows auf vordefinierte Variablen verweisen.

Verwenden Sie die folgenden Anweisungen, um auf eine vordefinierte Variable in einem Workflow zu verweisen.

Weitere Informationen zu vordefinierten Variablen finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).

**Voraussetzung**  
Ermitteln Sie den Namen der vordefinierten Variablen, auf die Sie verweisen möchten, z. `CommitId` B. Weitere Informationen finden Sie unter [Ermitteln, welche vordefinierten Variablen Ihr Workflow ausgibt](workflows-working-with-variables-determine-output-vars.md).

------
#### [ Visual ]

*Nicht verfügbar. Wählen Sie YAML, um die YAML-Anweisungen anzuzeigen.*

------
#### [ YAML ]

**Um auf eine vordefinierte Variable zu verweisen (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 in einer CodeCatalyst Aktion die vordefinierte Variablenreferenz mit der folgenden Syntax hinzu:

   ```
   ${action-group-name.action-name-or-WorkflowSource.variable-name}
   ```

   Ersetzen Sie:
   + *action-group-name*mit dem Namen der Aktionsgruppe.
**Anmerkung**  
Sie können weglassen, *action-group-name* wenn es keine Aktionsgruppe gibt oder wenn die Variable durch eine Aktion in derselben Aktionsgruppe erzeugt wird.
   + *action-name-or-WorkflowSource*mit:

     Der Name der Aktion, die die Variable ausgibt.

     oder

     `WorkflowSource`, wenn es sich bei der Variablen um die `CommitId` Variable `BranchName` oder handelt.
   + *variable-name*mit dem Namen der Variablen.

   Beispiel:

   ```
   MySecondAction:
       Configuration:
         Steps:
           - Run: echo ${MyFirstECSAction.cluster}
   ```

   Ein weiteres Beispiel:

   ```
   MySecondAction:
       Configuration:
         Steps:
           - Run: echo ${WorkflowSource.CommitId}
   ```

   Weitere Beispiele finden Sie unter [Beispiele für die Referenzierung vordefinierter Variablen](workflows-predefined-examples.md). Weitere Informationen finden Sie unter [YAML-Workflow-Definition](workflow-reference.md) Für Ihre Aktion.

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.

------

# Ermitteln, welche vordefinierten Variablen Ihr Workflow ausgibt
<a name="workflows-working-with-variables-determine-output-vars"></a>

Gehen Sie wie folgt vor, um zu ermitteln, welche vordefinierten Variablen ein Workflow ausgibt, wenn er ausgeführt wird. Sie können dann innerhalb desselben Workflows auf diese Variablen verweisen. 

Weitere Informationen zu vordefinierten Variablen finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).

**So ermitteln Sie die vordefinierten Variablen, die Ihr Workflow ausgibt**
+ Führen Sie eine der folgenden Aktionen aus:
  + **Führen Sie den Workflow einmal** aus. Nach Abschluss des Laufs werden die vom Workflow ausgegebenen Variablen auf der Registerkarte **Variablen** der Seite mit den Ausführungsdetails angezeigt. Weitere Informationen finden Sie unter [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).
  + **Konsultieren Sie die [Liste der vordefinierten Variablen](workflow-ref-action-variables.md)**. In dieser Referenz sind der Variablenname (Schlüssel) und der Wert für jede vordefinierte Variable aufgeführt.

**Anmerkung**  
Die maximale Gesamtgröße der Variablen eines Workflows ist unter aufgeführt[Kontingente für Workflows in CodeCatalyst](workflows-quotas.md). Wenn die Gesamtgröße das Maximum überschreitet, schlägt die Aktion, die nach dem Erreichen des Maximums ausgeführt wird, möglicherweise fehl.

# Liste der vordefinierten Variablen
<a name="workflow-ref-action-variables"></a>

In den folgenden Abschnitten finden Sie eine Übersicht über die vordefinierten Variablen, die automatisch durch CodeCatalyst Aktionen im Rahmen einer Workflow-Ausführung erzeugt werden.

Weitere Informationen zu vordefinierten Variablen finden Sie unter[Verwenden vordefinierter Variablen](workflows-using-predefined-variables.md).

**Anmerkung**  
Diese Liste enthält nur vordefinierte Variablen, die von der CodeCatalyst Quelle und den [CodeCatalyst Aktionen ausgegeben werden](workflows-actions.md#workflows-actions-types). Wenn Sie andere Aktionstypen verwenden, z. B. Aktionen oder GitHub CodeCatalyst Labs-Aktionen, finden Sie stattdessen weitere Informationen unter[Ermitteln, welche vordefinierten Variablen Ihr Workflow ausgibt](workflows-working-with-variables-determine-output-vars.md).

**Liste**

**Anmerkung**  
Nicht alle CodeCatalyst Aktionen erzeugen vordefinierte Variablen. Wenn die Aktion nicht in der Liste enthalten ist, erzeugt sie keine Variablen.
+ [Variablen BranchName '' und CommitId ''](workflows-sources-variables.md)
+ [CloudFormation 'Stack'-Variablen bereitstellen](deploy-action-cfn-variables.md)
+ [Variablen „In Amazon ECS bereitstellen“](deploy-action-ecs-variables.md)
+ [Variablen „Im Kubernetes-Cluster bereitstellen“](deploy-action-eks-variables.md)
+ [Variablen 'AWS CDK bereitstellen'](cdk-dep-action-variables.md)
+ [AWS CDK 'Bootstrap'-Variablen](cdk-boot-action-variables.md)
+ [Variablen 'AWS Lambda aufrufen'](lam-invoke-action-variables.md)
+ [Variablen „Amazon ECS-Aufgabendefinition rendern“](render-ecs-action-variables.md)

# Daten mithilfe von Geheimnissen maskieren
<a name="workflows-secrets"></a>

Es kann vorkommen, dass Sie vertrauliche Daten, wie z. B. Anmeldeinformationen, in Ihren Workflows verwenden müssen. Es sollte vermieden werden, diese Werte irgendwo in Ihrem Repository im Klartext zu speichern, da jeder, der Zugriff auf das Repository hat, das das Geheimnis enthält, sie sehen kann. Ebenso sollten diese Werte nicht direkt in Workflow-Definitionen verwendet werden, da sie dann als Dateien in Ihrem Repository sichtbar sind. Mit können Sie diese Werte schützen CodeCatalyst, indem Sie Ihrem Projekt ein Geheimnis hinzufügen und dann in Ihrer Workflow-Definitionsdatei auf das Geheimnis verweisen. Beachten Sie, dass Sie pro Aktion maximal fünf Geheimnisse haben können.

**Anmerkung**  
Secrets können nur verwendet werden, um Passwörter und vertrauliche Informationen in der Workflow-Definitionsdatei zu ersetzen.

**Topics**
+ [

# Ein Geheimnis erstellen
](workflows-secrets.creating.md)
+ [

# Ein Geheimnis bearbeiten
](workflows-secrets.editing.md)
+ [

# Verwenden eines Secrets
](workflows-secrets.using.md)
+ [

# Ein Geheimnis löschen
](workflows-secrets.deleting.md)

# Ein Geheimnis erstellen
<a name="workflows-secrets.creating"></a>

Gehen Sie wie folgt vor, um ein Geheimnis zu erstellen. Das Geheimnis enthält die vertraulichen Informationen, die Sie vor dem Zugriff verbergen möchten.

**Anmerkung**  
Geheimnisse sind für Aktionen sichtbar und werden nicht maskiert, wenn sie in eine Datei geschrieben werden.

**So erstellen Sie ein Secret**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Secrets aus.**

1. Wählen Sie **Create secret (Secret erstellen)** aus.

1. Geben Sie die folgenden Informationen ein:  
**Name**  
Geben Sie einen Namen für Ihr Geheimnis ein.  
**Wert**  
Geben Sie den Wert für das Geheimnis ein. Dies sind die vertraulichen Informationen, die Sie vor dem Zugriff verbergen möchten. Standardmäßig wird der Wert nicht angezeigt. Um den Wert anzuzeigen, wählen Sie **Wert anzeigen**.  
**Beschreibung**  
(Optional) Geben Sie eine Beschreibung für Ihr Geheimnis ein.

1. Wählen Sie **Erstellen** aus.

# Ein Geheimnis bearbeiten
<a name="workflows-secrets.editing"></a>

Gehen Sie wie folgt vor, um ein Geheimnis zu bearbeiten.

**Um ein Geheimnis zu bearbeiten**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Secrets aus.**

1. Wählen Sie in der Geheimnisliste das Geheimnis aus, das Sie bearbeiten möchten.

1. Wählen Sie **Bearbeiten** aus.

1. Bearbeiten Sie die folgenden Eigenschaften:  
**Wert**  
Geben Sie den Wert für das Geheimnis ein. Dies ist der Wert, den Sie aus der Ansicht ausblenden möchten. Standardmäßig wird der Wert nicht angezeigt.  
**Beschreibung**  
(Optional) Geben Sie eine Beschreibung für Ihr Geheimnis ein.

1. Wählen Sie **Speichern**.

# Verwenden eines Secrets
<a name="workflows-secrets.using"></a>

Um ein Geheimnis in einer Workflow-Aktion zu verwenden, müssen Sie die Referenz-ID des Geheimnisses abrufen und diese ID in der Workflow-Aktion verwenden.

**Topics**
+ [

## Den Bezeichner eines Geheimnisses abrufen
](#workflows-using-secrets.get-identifier)
+ [

## Verweisen auf ein Geheimnis in einem Workflow
](#workflows-using-secrets.using-identifier)

## Den Bezeichner eines Geheimnisses abrufen
<a name="workflows-using-secrets.get-identifier"></a>

Gehen Sie wie folgt vor, um die Referenz-ID des Geheimnisses zu ermitteln. Sie fügen diese Kennung Ihrem Workflow hinzu.

**Um die Referenz-ID des Geheimnisses zu erhalten**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Secrets aus.**

1. Suchen Sie in der Liste der Geheimnisse nach dem Geheimnis, das Sie verwenden möchten.

1. Kopieren Sie in der Spalte **Referenz-ID** die Kennung des Geheimnisses. Im Folgenden ist die Syntax für die **Referenz-ID**:

   ```
   ${Secrets.<name>}
   ```

## Verweisen auf ein Geheimnis in einem Workflow
<a name="workflows-using-secrets.using-identifier"></a>

Gehen Sie wie folgt vor, um in einem Workflow auf ein Geheimnis zu verweisen.

**Um auf ein Geheimnis zu verweisen**

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. Ändern Sie das YAML so, dass es den Bezeichner des Geheimnisses verwendet. Um beispielsweise einen Benutzernamen und ein Passwort zu verwenden, die zusammen mit dem `curl` Befehl als Geheimnisse gespeichert sind, würden Sie einen `Run` Befehl verwenden, der dem folgenden ähnelt:

   ```
   - Run: curl -u <username-secret-identifier>:<password-secret-identifier> https://example.com
   ```

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

# Ein Geheimnis löschen
<a name="workflows-secrets.deleting"></a>

Gehen Sie wie folgt vor, um ein Geheimnis und die geheime Referenz-ID zu löschen.

**Anmerkung**  
Bevor Sie ein Geheimnis löschen, empfehlen wir, die Referenz-ID des Geheimnisses aus allen Workflow-Aktionen zu entfernen. Wenn Sie das Geheimnis löschen, ohne die Referenz-ID zu löschen, schlägt die Aktion bei der nächsten Ausführung fehl. 

**Um die Referenz-ID eines geheimen Schlüssels aus einem Workflow zu löschen**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

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 im Workflow nach der folgenden Zeichenfolge:

   ```
   ${Secrets.
   ```

   Dadurch werden alle Referenzkennungen aller Geheimnisse gefunden.

1. Löscht den Referenzbezeichner des ausgewählten Geheimnisses oder ersetzt ihn durch einen Klartextwert.

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

**So löschen Sie ein Geheimnis**

1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Secrets aus.**

1. Wählen Sie in der Geheimnisliste das Geheimnis aus, das Sie löschen möchten.

1. Wählen Sie **Löschen** aus.

1. Geben Sie ein**delete**, um das Löschen zu bestätigen.

1. Wählen Sie **Löschen** aus.

# Status eines Workflows anzeigen
<a name="workflows-view-status"></a>

Möglicherweise möchten Sie den Status eines Workflows anzeigen, um festzustellen, ob es Probleme mit der Workflow-Konfiguration gibt, die Sie beheben müssen, oder um Fehler bei Läufen zu beheben, die nicht gestartet werden können. CodeCatalystwertet den Workflow-Status jedes Mal aus, wenn Sie die dem Workflow zugrunde liegende [Workflow-Definitionsdatei](workflows-concepts.md#workflows-concepts-workflows-def) erstellen oder aktualisieren. 

**Anmerkung**  
Sie können auch den *Ausführungsstatus* des Workflows anzeigen, der sich vom Workflow-Status unterscheidet. Weitere Informationen finden Sie unter [Status und Details der Workflow-Ausführung anzeigen](workflows-view-run.md).

Eine Liste möglicher Workflow-Status finden Sie unter[Workflow-Status in CodeCatalyst](workflows-workflow-status.md).

**So zeigen Sie den Status eines Workflows an**

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.

   Der Status wird zusammen mit dem Workflow in der Liste angezeigt.

1. (Optional) Wählen Sie den Namen des Workflows und suchen Sie das Feld **Workflow-Definition**. Es zeigt den Workflow-Status an.

# Kontingente für Workflows in CodeCatalyst
<a name="workflows-quotas"></a>

In der folgenden Tabelle werden Kontingente und Limits für Workflows in Amazon beschrieben CodeCatalyst.

Weitere Informationen zu Kontingenten bei Amazon CodeCatalyst finden Sie unter[Kontingente für CodeCatalyst](quotas.md).


|  |  | 
| --- |--- |
| Maximale Anzahl von Workflows pro Space |  800  | 
| Maximale Größe der Workflow-Definitionsdatei |  256 KB  | 
| Maximale Anzahl von Workflow-Dateien, die in einem einzelnen Quellereignis verarbeitet werden |  50  | 
| Maximale Anzahl von Dateien, die in einem Einzelquellenereignis verarbeitet wurden |  4.000  | 
| Maximale Anzahl aktiver Flotten pro Space |  10  | 
| Maximale Anzahl aktiver Recheninstanzen pro Flotte |  20  | 
| Maximale Anzahl von Eingabeartefakten pro Aktion |  10  | 
| Maximale Anzahl von Ausgabeartefakten pro Aktion |  10  | 
| Maximale Gesamtgröße der Ausgabevariablen einer einzelnen Aktion |  120 KB  | 
| Maximale Länge eines Ausgangsvariablenwerts  |  500 Zeichen oder mehr, abhängig von der Aktion, die den Wert ausgibt.   Werte können gekürzt werden, wenn sie das Limit der Aktion überschreiten.   | 
| Maximale Anzahl von Tagen für die Aufbewahrung von Artefakten, die während einer Workflow-Ausführung generiert wurden |  30  | 
| Maximale Anzahl von Berichten pro Aktion |  50  | 
| Maximale Anzahl von Testfällen pro Testbericht |  20 000  | 
| Maximale Anzahl von Dateien pro Codeabdeckungsbericht |  20 000  | 
| Maximale Anzahl von Ergebnissen der Analyse der Softwarezusammensetzung pro Bericht |  20 000  | 
| Maximale Anzahl von Dateien pro statischem Analysebericht |  20 000  | 
| Maximale Anzahl gleichzeitiger Workflow-Ausführungen pro Speicherplatz |  100  | 
| Maximale Anzahl von Aktionen pro Workflow |  50  | 
| Maximale Anzahl gleichzeitig ausgeführter Aktionen pro Workflow |  50  | 
| Maximale Anzahl gleichzeitig ausgeführter Aktionen pro Space |  200  | 
| Maximale Dauer, für die eine Aktion ausgeführt werden kann |  Für die Build- und Testaktionen beträgt das Timeout 8 Stunden. Für alle anderen Aktionen beträgt das Timeout 1 Stunde.  | 
| Maximale Anzahl von Umgebungen, die einem AWS-Konto pro Bereich zugeordnet sind |  5,000  | 
| Maximale Anzahl von Geheimnissen pro Aktion |  5  | 
| Maximale Anzahl von Geheimnissen pro Feld |  500 000  | 

# Status der Workflow-Ausführung
<a name="workflows-view-run-status"></a>

Ein Workflow-Lauf kann sich in einem der folgenden Status befinden:
+ **Erfolgreich** — Die Workflow-Ausführung wurde erfolgreich verarbeitet.
+ **Fehlgeschlagen** — Eine oder mehrere Aktionen in der Workflow-Ausführung sind fehlgeschlagen.
+ **In Bearbeitung** — Der Workflow-Lauf wird gerade verarbeitet.
+ **Gestoppt** — Eine Person hat den Workflow-Lauf gestoppt, während er in Bearbeitung war.
+ **Beenden** — Die Workflow-Ausführung wird derzeit gestoppt.
+ **Abgebrochen** — Die Workflow-Ausführung wurde von abgebrochen, CodeCatalyst weil der zugehörige Workflow während der Ausführung gelöscht oder aktualisiert wurde.
+ **Ersetzt — Tritt nur auf, wenn Sie den abgelösten** Ausführungsmodus [konfiguriert](workflows-configure-runs.md#workflows-configure-runs-superseded) haben. Die Workflow-Ausführung wurde von abgebrochen, CodeCatalyst weil sie durch eine spätere Workflow-Ausführung ersetzt wurde.

# Workflow-Status in CodeCatalyst
<a name="workflows-workflow-status"></a>

Ein Workflow kann einen der folgenden Status haben:
+ **Gültig** [— Der Workflow ist ausführbar und kann durch Trigger aktiviert werden.](workflows-add-trigger.md#workflows-add-trigger.title)

  Damit ein Workflow als gültig markiert werden kann, müssen die beiden folgenden Bedingungen erfüllt sein:
  + Die Workflow-Definitionsdatei muss gültig sein.
  + Der Workflow darf keine Trigger, keine Push-Trigger oder einen Push-Trigger haben, der mithilfe der Dateien im aktuellen Branch ausgeführt wird. Weitere Informationen finden Sie unter [Richtlinien zur Verwendung von Triggern und Branches](workflows-add-trigger-considerations.md).
+ **Ungültig** — Die Definitionsdatei des Workflows ist nicht gültig. Der Workflow kann nicht manuell oder automatisch über Trigger ausgeführt werden. Ungültige Workflows werden mit einer **Workflow-Definition mit einer *n* Fehlermeldung** (oder einer ähnlichen Meldung) in der CodeCatalyst Konsole angezeigt.

  Damit ein Workflow als ungültig markiert werden kann, muss die folgende Bedingung erfüllt sein:
  + Die Workflow-Definitionsdatei muss falsch konfiguriert sein.

    Informationen zum Korrigieren einer falsch konfigurierten Workflow-Definitionsdatei finden Sie unter. [Wie behebe ich den Fehler „Workflow-Definition enthält *n* Fehler“?](troubleshooting-workflows.md#troubleshooting-workflows-asterisks)
+ **Inaktiv** — Die Workflow-Definition ist gültig, kann aber nicht manuell oder automatisch über Trigger ausgeführt werden.

  Damit ein Workflow als inaktiv markiert werden kann, müssen beide der folgenden Bedingungen erfüllt sein:
  + Die Workflow-Definitionsdatei muss gültig sein.
  + Die Workflow-Definitionsdatei muss einen Push-Trigger enthalten, der einen Zweig angibt, der sich von dem unterscheidet, in dem sich die Workflow-Definitionsdatei derzeit befindet. Weitere Informationen finden Sie unter [Richtlinien zur Verwendung von Triggern und Branches](workflows-add-trigger-considerations.md).

    Informationen zum Umschalten eines Workflows von **Inaktiv** **auf Aktiv** finden Sie unter[Wie behebe ich die Meldung „Der Workflow ist inaktiv“?](troubleshooting-workflows.md#troubleshooting-workflows-inactive).
**Anmerkung**  
Wenn sich viele Workflows im Status **Inaktiv** befinden, können Sie sie aus der Ansicht filtern. Um inaktive Workflows herauszufiltern, wählen Sie oben auf der Workflow-Seite das Feld ****Workflows** filtern** aus, wählen Sie **Status** und dann **Status aus\$1 = Entspricht nicht** und wählen Sie **INAKTIV**.

**Anmerkung**  
Wenn der Workflow eine Ressource angibt, die Sie später entfernen (z. B. ein Paket-Repository), wird diese Änderung CodeCatalyst nicht erkannt und der Workflow wird weiterhin als gültig markiert. Solche Probleme werden erkannt, wenn der Workflow ausgeführt wird.

# YAML-Workflow-Definition
<a name="workflow-reference"></a>

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
<a name="workflow.anatomy"></a>

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
<a name="workflow.terms.syntax.conv"></a>

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
<a name="workflow.syntax.conv"></a>

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
<a name="workflow.terms"></a>

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
<a name="workflow.top.level"></a>

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
<a name="workflow.name"></a>

(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
<a name="workflow.schemaversion"></a>

(Erforderlich)

Die Schemaversion der Workflow-Definition. Der einzige gültige Wert ist derzeit `1.0`.

Entsprechende Benutzeroberfläche: *keine*

### RunMode
<a name="workflow.runmode"></a>

(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
<a name="compute-reference"></a>

(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
<a name="workflow.compute.type"></a>

(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
<a name="workflow.compute.fleet"></a>

(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
<a name="workflow.compute.sharedinstance"></a>

(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
<a name="triggers-reference"></a>

(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
<a name="workflow.triggers.type"></a>

(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
<a name="workflow.triggers.events"></a>

(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
<a name="workflow.triggers.branches"></a>

(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
<a name="workflow.triggers.files-changed"></a>

(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
<a name="workflow.triggers.expression"></a>

(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
<a name="actions-reference"></a>

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
<a name="workflow.actions.name"></a>

(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
<a name="workflow.action-groups"></a>

(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*