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.
# Bauen mit Workflows
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*action-name*/Outputs/**Reports** )
(Optional)
Ein Abschnitt, der die Konfiguration für Testberichte spezifiziert.
**Entsprechende Benutzeroberfläche: Registerkarte Ausgaben/Berichte**
## Berichtsname-1
**(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
(*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
(*action-name*/**Configuration**)
(Erforderlich) Ein Abschnitt, in dem Sie die Konfigurationseigenschaften der Aktion definieren können.
Entsprechende Benutzeroberfläche: Registerkarte „**Konfiguration**“
## Container
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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“**