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. # Testen mit Workflows 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 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 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 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 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 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 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 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 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 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 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 ``` 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 ``` 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 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 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 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 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 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 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 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 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 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | Name | Erforderlich | Description | | --- | --- | --- | | `fullyQualifiedName` | Nein | Zusätzliche Informationen, die den Speicherort des Ergebnisses beschreiben. Maximale Länge: 1.024 Zeichen | ## `fix`-Objekt | 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. |