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. # CodePipeline Referenz zur Pipeline-Struktur Referenz der Pipeline-Struktur Sie können CodePipeline sie verwenden, um eine CI/CD Pipeline automatisierter Schritte zu strukturieren, mit denen Aufgaben ausgeführt werden, die den Quellcode Ihrer Anwendung erstellen, testen und bereitstellen. Dieser Referenzabschnitt enthält Einzelheiten zur JSON-Struktur und zu den Parametern in Ihrer Pipeline. Eine allgemeine Liste von Konzepten, die beschreiben, wie Pipelines verwendet werden, finden Sie unter[CodePipeline Konzepte ](concepts.md). + Wenn du eine Pipeline erstellst, wählst du eine verfügbare Quellaktion und einen Anbieter aus, z. B. einen S3-Bucket, ein CodeCommit Repository, ein Bitbucket-Repository oder ein GitHub Repository, das deinen Quellcode enthält und deine Pipeline startet, wenn du eine Quellcodeänderung festschreibst. Dieser Referenzabschnitt enthält Referenzinformationen zu den verfügbaren Quellen für deine Pipeline. Weitere Informationen zum Arbeiten mit Quellaktionen finden Sie unter[Starten Sie eine Pipeline in CodePipeline](pipelines-about-starting.md). + Sie können die Test-, Build- und Bereitstellungsaktionen und Anbieter auswählen, die Sie bei der Ausführung Ihrer Pipeline automatisch einbeziehen möchten. Dieser Referenzabschnitt enthält Referenzinformationen zu den verfügbaren Aktionen und dazu, wie sie in Ihre Pipeline-JSON passen. + Ihre fertige Pipeline besteht aus einer Quellphase sowie weiteren Phasen, in denen Sie Aktionen zum Bereitstellen und Testen Ihrer Anwendung konfigurieren. Ein konzeptionelles Beispiel für eine DevOps Pipeline, die Ihre Anwendung bereitstellt, finden Sie unter[DevOps Beispiel für eine Pipeline](concepts-devops-example.md). Standardmäßig hat jede Pipeline, in der Sie erfolgreich eine Pipeline erstellen, AWS CodePipeline eine gültige Struktur. Wenn Sie jedoch manuell eine JSON-Datei erstellen oder bearbeiten, um eine Pipeline zu erstellen oder eine Pipeline aus der zu aktualisieren AWS CLI, können Sie versehentlich eine Struktur erstellen, die nicht gültig ist. Die folgende Referenz kann Ihnen dabei helfen, die Anforderungen hinsichtlich der Struktur Ihrer Pipeline besser zu verstehen und Probleme zu beheben. Beachten Sie die Einschränkungen in [Kontingente in AWS CodePipeline](limits.md), die für alle Pipelines gelten. Die folgenden Abschnitte enthalten allgemeine Parameter und ihre Position in der Pipeline-Struktur. Die Anforderungen an die Rohrleitungsstruktur werden in jedem Abschnitt für die folgenden Typen von Rohrleitungskomponenten detailliert beschrieben: + Feldreferenz für [Pipeline-Erklärung](pipeline-requirements.md) + Feldreferenz für den [Deklaration der Phase](stage-requirements.md) + Feldreferenz für den [Aktionsdeklaration](action-requirements.md) + Liste von [Gültige Aktionsanbieter in CodePipeline](actions-valid-providers.md) nach Aktionstyp + Referenz für [Gültige Einstellungen für den `PollForSourceChanges` Parameter](PollForSourceChanges-defaults.md) + Referenz für [Gültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp](reference-action-artifacts.md) + Linkliste für [Gültige Konfigurationsparameter für jeden Anbietertyp](structure-configuration-examples.md) Weitere Informationen finden Sie unter dem [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)Objekt im *CodePipeline API-Leitfaden*. Das folgende Beispiel für eine Pipeline-Konsolenansicht zeigt die Pipeline mit dem Namen new-github, die Stufen mit den Namen `Source` `manual``Build`, und und sowie Aktionen von GitHub (über GitHub App), manuellen Genehmigungsanbietern und CodeBuild Aktionsanbietern. ![\[Ein Beispiel für die Pipeline-Ansicht in der CodePipeline Konsole.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/pipeline-console-view.png) Wenn der Pipeline-Bearbeitungsmodus im Konsolendiagramm angezeigt wird, können Sie Quellenüberschreibungen, Trigger und Aktionen bearbeiten, wie im folgenden Beispiel gezeigt. ![\[Ein Beispiel für den Pipeline-Bearbeitungsmodus in der CodePipeline Konsole.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/pipeline-console-view-edit.png) **Topics** + [ # Pipeline-Erklärung ](pipeline-requirements.md) + [ # Deklaration der Phase ](stage-requirements.md) + [ # Aktionsdeklaration ](action-requirements.md) + [ # Gültige Aktionsanbieter in CodePipeline ](actions-valid-providers.md) + [ # Gültige Einstellungen für den `PollForSourceChanges` Parameter ](PollForSourceChanges-defaults.md) + [ # Gültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp ](reference-action-artifacts.md) + [ # Gültige Konfigurationsparameter für jeden Anbietertyp ](structure-configuration-examples.md) # Pipeline-Erklärung Die Pipeline- und Metadatenebene einer Pipeline hat eine grundlegende Struktur, die die folgenden Parameter und die folgende Syntax umfasst. Der Pipeline-Parameter stellt die Struktur der Aktionen und Phasen dar, die in der Pipeline ausgeführt werden sollen. Weitere Informationen finden Sie unter dem [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)Objekt im *CodePipeline API-Leitfaden*. Das folgende Beispiel zeigt die Pipeline- und Metadatenebene der Pipeline-Struktur sowohl in JSON als auch in YAML für eine Pipeline vom Typ V2. ------ #### [ YAML ] ``` pipeline: name: MyPipeline roleArn: >- arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline artifactStore: type: S3 location: amzn-s3-demo-bucket stages: ... version: 6 executionMode: SUPERSEDED pipelineType: V2 variables: - name: MyVariable defaultValue: '1' triggers: - providerType: CodeStarSourceConnection gitConfiguration: sourceActionName: Source push: - branches: includes: - main excludes: - feature-branch pullRequest: - events: - CLOSED branches: includes: - main* metadata: pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline' created: '2019-12-12T06:49:02.733000+00:00' updated: '2020-09-10T06:34:07.447000+00:00' pollingDisabledAt: '2020-09-10T06:34:07.447000\$100:00' ``` ------ #### [ JSON ] ``` { "pipeline": { "name": "MyPipeline", "roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline", "artifactStore": { "type": "S3", "location": "amzn-s3-demo-bucket" }, "stages": { ... }, "version": 6, "executionMode": "SUPERSEDED", "pipelineType": "V2", "variables": [ { "name": "MyVariable", "defaultValue": "1" } ], "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "branches": { "includes": [ "main" ], "excludes": [ "feature-branch" ] } } ], "pullRequest": [ { "events": [ "CLOSED" ], "branches": { "includes": [ "main*" ] } } ] } } ] }, "metadata": { "pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline", "created": "2019-12-12T06:49:02.733000+00:00", "updated": "2020-09-10T06:34:07.447000+00:00", "pollingDisabledAt": "2020-09-10T06:34:07.447000+00:00" } } ``` ------ ## `name` Der Name der Pipeline. Wenn Sie eine Pipeline bearbeiten oder aktualisieren, kann der Pipelinename nicht geändert werden. **Anmerkung** Wenn Sie eine vorhandene Pipeline umbenennen möchten, können Sie mit dem CLI-Befehl `get-pipeline` eine JSON-Datei erstellen, die die Struktur Ihrer Pipeline enthält. Anschließend können Sie mit dem CLI-Befehl `create-pipeline` eine Pipeline mit dieser Struktur erstellen und ihr einen neuen Namen geben. ## `roleArn` Der IAM-ARN für die CodePipeline Servicerolle, z. B. arn:aws:iam: :80398example:role/ \$1Service\$1Role. CodePipeline Um die Konsole zum Anzeigen des ARN der Pipeline-Dienstrolle anstelle der JSON-Struktur zu verwenden, wählen Sie Ihre Pipeline in der Konsole aus und wählen Sie dann **Einstellungen** aus. Auf der Registerkarte **Allgemein** wird das **ARN-Feld für die Servicerolle** angezeigt. ## `artifactStore`ODER `artifactStores` Das `artifactStore` Feld enthält den Typ und die Position des Artefakt-Buckets für eine Pipeline mit allen Aktionen in derselben AWS Region. Wenn Sie Aktionen in einer anderen Region als Ihrer Pipeline hinzufügen, wird das `artifactStores` Mapping verwendet, um den Artefakt-Bucket für jede AWS Region aufzulisten, in der Aktionen ausgeführt werden. Wenn Sie eine Pipeline erstellen oder bearbeiten, müssen Sie einen Artefakt-Bucket in der Pipelineregion haben, sowie einen Artefakt-Bucket für jede Region, in der Sie eine Aktion ausführen möchten. **Anmerkung** In der Pipeline-Struktur müssen Sie entweder `artifactStore` oder `artifactStores` in Ihre Pipeline aufnehmen, aber Sie können nicht beide verwenden. Wenn Sie eine regionsübergreifende Aktion in Ihrer Pipeline erstellen, müssen Sie `artifactStores` verwenden. Das folgende Beispiel zeigt die grundlegende Struktur für eine Pipeline mit regionsübergreifenden Aktionen, die den `artifactStores`-Parameter verwendet: ``` "pipeline": { "name": "YourPipelineName", "roleArn": "CodePipeline_Service_Role", "artifactStores": { "us-east-1": { "type": "S3", "location": "S3 artifact bucket name, such as amzn-s3-demo-bucket" }, "us-west-2": { "type": "S3", "location": "S3 artifact bucket name, such as amzn-s3-demo-bucket" } }, "stages": [ { ... ``` ### `type` Der Standorttyp für den Artefakt-Bucket, angegeben als Amazon S3. ### `location` Der Name des Amazon S3 S3-Buckets, der automatisch für Sie generiert wird, wenn Sie zum ersten Mal eine Pipeline mithilfe der Konsole erstellen, z. B. codepipeline-us-east -2-1234567890, oder eines beliebigen Amazon S3 S3-Buckets, den Sie zu diesem Zweck bereitstellen ## `stages` Dieser Parameter enthält den Namen jeder Phase in der Pipeline. Weitere Informationen zu den Parametern und der Syntax auf der Stufenebene der Pipeline-Struktur finden Sie unter dem [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)Objekt im * CodePipeline API-Leitfaden*. Die Pipeline-Struktur für Stufen hat die folgenden Anforderungen: + Eine Pipeline muss mindestens zwei Phasen enthalten. + Die erste Phase einer Pipeline muss mindestens eine Quellaktion enthalten. Sie darf nur Quellaktionen enthalten. + Nur die erste Phase einer Pipeline kann Quellaktionen enthalten. + Mindestens eine Phase in jeder Pipeline muss eine Aktion enthalten, die keine Quellaktion ist. + Alle Namen von Phasen in einer Pipeline müssen eindeutig sein. + Phasennamen können in der CodePipeline Konsole nicht bearbeitet werden. Wenn Sie einen Phasennamen mithilfe von bearbeiten und die Phase eine Aktion mit einem oder mehreren geheimen Parametern (z. B. einem OAuth Token) enthält, wird der Wert dieser geheimen Parameter nicht beibehalten. AWS CLI Sie müssen die Werte der Parameter (die in der von der AWS CLI zurückgegebenen JSON mit vier Sternchen maskiert sind) manuell in die JSON-Struktur eingeben. **Wichtig** Bei Pipelines, die länger als 30 Tage inaktiv sind, ist das Polling für die Pipeline deaktiviert. Weitere Informationen finden Sie [pollingDisabledAt](#metadata.pollingDisabledAt)in der Referenz zur Pipeline-Struktur. Die Schritte zur Migration Ihrer Pipeline von der Abfrage zur ereignisbasierten Änderungserkennung finden Sie unter Methoden zur [Änderungserkennung](change-detection-methods.md). ## `version` Die Versionsnummer einer Pipeline wird bei jedem Pipeline-Update automatisch generiert und aktualisiert. ## `executionMode` Sie können den Pipeline-Ausführungsmodus so einstellen, dass Sie das Pipeline-Verhalten für aufeinanderfolgende Läufe angeben können, z. B. für Warteschlangen, Ablösen oder Parallelbetrieb. Weitere Informationen finden Sie unter [Legen Sie den Pipeline-Ausführungsmodus fest oder ändern Sie ihn](execution-modes.md). **Wichtig** Für Pipelines im PARALLELMODUS ist ein stufenweises Rollback nicht verfügbar. Ebenso können Fehlerbedingungen mit einem Rollback-Ergebnistyp nicht zu einer Pipeline im PARALLEL-Modus hinzugefügt werden. ## `pipelineType` Der Pipeline-Typ gibt die verfügbare Struktur und die Funktionen in der Pipeline an, z. B. für eine Pipeline vom Typ V2. Weitere Informationen finden Sie unter [Arten von Pipelines](pipeline-types.md). ## `variables` Variablen auf Pipelineebene werden bei der Erstellung der Pipeline definiert und zur Laufzeit der Pipeline aufgelöst. Weitere Informationen finden Sie unter [Variablen-Referenz](reference-variables.md). Ein Tutorial mit einer Variablen auf Pipelineebene, die bei der Ausführung der Pipeline übergeben wird, finden Sie unter. [Tutorial: Variablen auf Pipeline-Ebene verwenden](tutorials-pipeline-variables.md) ## `triggers` Mit Triggern können Sie Ihre Pipeline so konfigurieren, dass sie bei einem bestimmten Ereignistyp oder einem gefilterten Ereignistyp startet, z. B. wenn eine Änderung an einem bestimmten Branch oder einer bestimmten Pull-Anforderung erkannt wird. Trigger können für Quellaktionen mit Verbindungen konfiguriert werden, die die `CodeStarSourceConnection` Aktion in verwenden CodePipeline GitHub, wie Bitbucket und GitLab. Weitere Informationen zu Quellaktionen, die Verbindungen verwenden, findest du unter[Fügen Sie externe Quellanbieter zu Pipelines hinzu mit CodeConnections](pipelines-connections.md). Weitere Informationen und detailliertere Beispiele finden Sie unter[Automatisieren Sie das Starten von Pipelines mithilfe von Triggern und Filtern](pipelines-triggers.md). Für die Filterung werden Muster regulärer Ausdrücke im Glob-Format unterstützt, wie unter beschrieben[Arbeiten mit Glob-Mustern in der Syntax](syntax-glob.md). **Anmerkung** Für die Quellaktionen CodeCommit und S3 ist entweder eine konfigurierte Ressource zur Erkennung von Änderungen (eine EventBridge Regel) erforderlich, oder es wird die Option verwendet, das Repository nach Quelländerungen abzufragen. Für Pipelines mit einer Bitbucket GitHub - oder GitHub Enterprise Server-Quellaktion musst du weder einen Webhook einrichten noch standardmäßig Polling verwenden. Die Aktion „Verbindungen“ verwaltet die Erkennung von Änderungen für dich. **Wichtig** Bei Pipelines, die länger als 30 Tage inaktiv sind, ist das Polling für die Pipeline deaktiviert. Weitere Informationen finden Sie [pollingDisabledAt](#metadata.pollingDisabledAt)in der Referenz zur Pipeline-Struktur. Die Schritte zur Migration Ihrer Pipeline von der Abfrage zur ereignisbasierten Änderungserkennung finden Sie unter Methoden zur [Änderungserkennung](change-detection-methods.md). ### `gitConfiguration`-Felder Die Git-Konfiguration für den Trigger, einschließlich der Ereignistypen und aller Parameter zum Filtern nach Branches, Dateipfaden, Tags oder Pull-Request-Ereignissen. Die Felder in der JSON-Struktur sind wie folgt definiert: + `sourceActionName`: Der Name der Pipeline-Quellaktion mit der Git-Konfiguration. + `push`: Push-Ereignisse mit Filterung. Diese Ereignisse verwenden eine ODER-Operation zwischen verschiedenen Push-Filtern und eine UND-Operation innerhalb von Filtern. + `branches`: Die Zweige, nach denen gefiltert werden soll. Zweige verwenden eine UND-Operation zwischen Ein- und Ausschlüssen. + `includes`: Muster, nach denen nach Zweigen gefiltert wird, die aufgenommen werden sollen. Beinhaltet die Verwendung einer ODER-Operation. + `excludes`: Muster, nach denen nach Zweigen gefiltert werden soll, die ausgeschlossen werden. Schließt die Verwendung einer ODER-Operation aus. + `filePaths`: Die Dateipfadnamen, nach denen gefiltert werden soll. + `includes`: Muster, nach denen nach Dateipfaden gefiltert werden soll, die eingeschlossen werden sollen. Beinhaltet die Verwendung einer ODER-Operation. + `excludes`: Muster, nach denen nach Dateipfaden gefiltert werden soll, die ausgeschlossen werden. Schließt die Verwendung einer ODER-Operation aus. + `tags`: Die Tag-Namen, nach denen gefiltert werden soll. + `includes`: Muster, nach denen nach Tags gefiltert werden soll, die aufgenommen werden sollen. Beinhaltet die Verwendung einer ODER-Operation. + `excludes`: Muster, nach denen nach Tags gefiltert werden soll, die ausgeschlossen werden. Schließt die Verwendung einer ODER-Operation aus. + `pullRequest`: Pull-Request-Ereignisse mit Filterung nach Pull-Request-Ereignissen und Pull-Request-Filtern. + `events`: Filtert nach offenen, aktualisierten oder geschlossenen Pull-Request-Ereignissen wie angegeben. + `branches`: Die Branches, nach denen gefiltert werden soll. Zweige verwenden eine UND-Operation zwischen Ein- und Ausschlüssen. + `includes`: Muster, nach denen nach Zweigen gefiltert wird, die aufgenommen werden sollen. Beinhaltet die Verwendung einer ODER-Operation. + `excludes`: Muster, nach denen nach Zweigen gefiltert werden soll, die ausgeschlossen werden. Schließt die Verwendung einer ODER-Operation aus. + `filePaths`: Die Dateipfadnamen, nach denen gefiltert werden soll. + `includes`: Muster, nach denen nach Dateipfaden gefiltert werden soll, die eingeschlossen werden sollen. Beinhaltet die Verwendung einer ODER-Operation. + `excludes`: Muster, nach denen nach Dateipfaden gefiltert werden soll, die ausgeschlossen werden. Schließt die Verwendung einer ODER-Operation aus. Im Folgenden finden Sie ein Beispiel für die Trigger-Konfiguration für Push- und Pull-Request-Ereignistypen. ``` "triggers": [ { "provider": "Connection", "gitConfiguration": { "sourceActionName": "ApplicationSource", "push": [ { "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] }, "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "tags": { "includes": [ "release-v0", "release-v1" ], "excludes": [ "release-v2" ] } } ], "pullRequest": [ { "events": [ "CLOSED" ], "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] } } ] } } ], ``` ### `push`Felder vom Ereignistyp für Einschließen und Ausschließen Das Ein- und Ausschlussverhalten für Ebenen von Git-Konfigurationsfeldern für **Push-Ereignistypen** ist in der folgenden Liste aufgeführt: ``` push (OR operation is used between push and pullRequest or multiples) filePaths (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) excludes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) branches (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) excludes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) tags (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) TAG/**", "TAG2/** (OR operation is used between tag names) excludes (AND operation is used between includes and excludes) TAG/**", "TAG2/** (OR operation is used between tag names) ``` ### `pull request`Felder für den Ereignistyp zum Einschließen und Ausschließen Das Ein- und Ausschlussverhalten für Ebenen von Git-Konfigurationsfeldern für **Pull-Request-Ereignistypen** ist in der folgenden Liste aufgeführt: ``` pullRequest (OR operation is used between push and pullRequest or multiples) events (AND operation is used between events, filePaths, and branches). Includes/excludes are N/A for pull request events. filePaths (AND operation is used between events, filePaths, and branches) includes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) excludes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) branches (AND operation is used between events, filePaths, and branches) includes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) excludes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) ``` ## `metadata` Die Pipeline-Metadatenfelder unterscheiden sich von der Pipelinestruktur und können nicht bearbeitet werden. Wenn Sie eine Pipeline aktualisieren, wird das Datum im Metadatenfeld `updated` automatisch geändert. ### `pipelineArn` Der Amazon-Ressourcenname (ARN) der Pipeline. Um die Konsole zum Anzeigen des Pipeline-ARN anstelle der JSON-Struktur zu verwenden, wählen Sie Ihre Pipeline in der Konsole aus und wählen Sie dann **Einstellungen** aus. Auf der Registerkarte **Allgemein** wird das Feld **Pipeline-ARN** angezeigt. ### `created` Datum und Uhrzeit der Erstellung der Pipeline. ### `updated` Datum und Uhrzeit der letzten Aktualisierung der Pipeline. ### `pollingDisabledAt` Datum und Uhrzeit der Deaktivierung der Abfrage für eine Pipeline, die für Abfragen zur Änderungserkennung konfiguriert ist. Bei Pipelines, die länger als 30 Tage inaktiv sind, ist die Abfrage für die Pipeline deaktiviert. + Bei inaktiven Pipelines wird die Abfrage nach 30 Tagen ohne Ausführung deaktiviert. + Pipelines EventBridge, die CodeStar Verbindungen oder Webhooks verwenden, sind davon nicht betroffen. + Aktive Pipelines sind nicht betroffen. Weitere Informationen finden Sie unter dem `pollingDisabledAt` Parameter unter [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html)Objekt im * CodePipeline API-Leitfaden*. Die Schritte zur Migration Ihrer Pipeline von der Abfrage zur ereignisbasierten Änderungserkennung finden Sie unter Methoden zur [Änderungserkennung](change-detection-methods.md). # Deklaration der Phase Die Stufenebene einer Pipeline hat eine grundlegende Struktur, die die folgenden Parameter und die folgende Syntax umfasst. Weitere Informationen finden Sie unter dem [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)Objekt im * CodePipeline API-Leitfaden*. Das folgende Beispiel zeigt die Stufenebene der Pipeline-Struktur sowohl in JSON als auch in YAML. Das Beispiel zeigt zwei Stufen mit dem Namen `Source` und`Build`. Das Beispiel enthält zwei Bedingungen, eine für `onSuccess` und eine für`beforeEntry`. ------ #### [ YAML ] ``` pipeline: name: MyPipeline roleArn: >- arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline artifactStore: type: S3 location: amzn-s3-demo-bucket stages: - name: Source actions: - name: Source ... - name: Build actions: - name: Build ... onSuccess: conditions: - result: ROLLBACK rules: - name: DeploymentWindowRule ... beforeEntry: conditions: - result: FAIL rules: - name: MyLambdaRule ... version: 6 metadata: pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline' created: '2019-12-12T06:49:02.733000+00:00' updated: '2020-09-10T06:34:07.447000+00:00' ``` ------ #### [ JSON ] ``` { "pipeline": { "name": "MyPipeline", "roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline", "artifactStore": { "type": "S3", "location": "amzn-s3-demo-bucket" }, "stages": [ { "name": "Source", "actions": [ { "name": "Source", ... } ] }, { "name": "Build", "actions": [ { "name": "Build", ... } ], "onSuccess": { "conditions": [ { "result": "ROLLBACK", "rules": [ { "name": "DeploymentWindowRule", ... } ] } ] }, "beforeEntry": { "conditions": [ { "result": "FAIL", "rules": [ { "name": "MyLambdaRule", ... } ] } ] } } ], } ], "version": 6 }, "metadata": { "pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline", "created": "2019-12-12T06:49:02.733000+00:00", "updated": "2020-09-10T06:34:07.447000+00:00" } } ``` ------ ## `name` Den Namen der -Stufe. ## `actions` Die Aktionsebene einer Pipeline hat eine grundlegende Struktur, die die folgenden Parameter und die folgende Syntax umfasst. Parameter und Beispiele finden Sie unter[Aktionsdeklaration](action-requirements.md). ## `conditions` Bedingungen enthalten eine oder mehrere Regeln, die in einer Liste von Regeln unter verfügbar sind CodePipeline. Wenn alle Regeln in einer Bedingung erfolgreich sind, ist die Bedingung erfüllt. Sie können Bedingungen so konfigurieren, dass das angegebene Ergebnis wirksam wird, wenn die Kriterien nicht erfüllt sind. Sie können die folgenden Arten von Bedingungen konfigurieren: + `beforeEntry` + `onFailure` + `onSuccess` Weitere Informationen und Beispiele finden Sie unter [Bedingungen für eine Phase konfigurieren](stage-conditions.md). ## `rules` Jede Bedingung hat einen Regelsatz, bei dem es sich um einen geordneten Satz von Regeln handelt, die zusammen ausgewertet werden. Wenn also eine Regel in der Bedingung fehlschlägt, schlägt auch die Bedingung fehl. Sie können Regelbedingungen zur Laufzeit der Pipeline überschreiben. Die verfügbaren Regeln finden Sie in der Regelreferenz. Weitere Informationen finden Sie in der Referenz zur Regelstruktur unter[Referenz zur Regelstruktur](rule-reference.md). # Aktionsdeklaration Die Aktionsebene einer Pipeline hat eine grundlegende Struktur, die die folgenden Parameter und die folgende Syntax umfasst. Weitere Informationen finden Sie unter dem [ActionDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionDeclaration.html)Objekt im *CodePipeline API-Leitfaden*. Das folgende Beispiel zeigt die Aktionsebene der Pipeline-Struktur sowohl in JSON als auch in YAML. ------ #### [ YAML ] ``` . . . stages: - name: Source actions: - name: Source actionTypeId: category: Source owner: AWS provider: S3 version: '1' runOrder: 1 configuration: PollForSourceChanges: 'false' S3Bucket: amzn-s3-demo-bucket S3ObjectKey: codedeploy_linux.zip outputArtifacts: - name: SourceArtifact inputArtifacts: [] region: us-west-2 namespace: SourceVariables - name: Build actions: - name: Build actionTypeId: category: Build owner: AWS provider: CodeBuild version: '1' runOrder: 1 configuration: EnvironmentVariables: >- [{"name":"ETag","value":"#{SourceVariables.ETag}","type":"PLAINTEXT"}] ProjectName: my-project outputArtifacts: - name: BuildArtifact inputArtifacts: - name: SourceArtifact region: us-west-2 namespace: BuildVariables runOrder: 1 configuration: CustomData: >- Here are the exported variables from the build action: S3 ETAG: #{BuildVariables.ETag} outputArtifacts: [] inputArtifacts: [] region: us-west-2 ``` ------ #### [ JSON ] ``` . . . "stages": [ { "name": "Source", "actions": [ { "name": "Source", "actionTypeId": { "category": "Source", "owner": "AWS", "provider": "S3", "version": "1" }, "runOrder": 1, "configuration": { "PollForSourceChanges": "false", "S3Bucket": "amzn-s3-demo-bucket", "S3ObjectKey": "aws-codepipeline-s3-aws-codedeploy_linux.zip" }, "outputArtifacts": [ { "name": "SourceArtifact" } ], "inputArtifacts": [], "region": "us-west-2", "namespace": "SourceVariables" } ] }, { "name": "Build", "actions": [ { "name": "Build", "actionTypeId": { "category": "Build", "owner": "AWS", "provider": "CodeBuild", "version": "1" }, "runOrder": 1, "configuration": { "EnvironmentVariables": "[{\"name\":\"ETag\",\"value\":\"#{SourceVariables.ETag}\",\"type\":\"PLAINTEXT\"}]", "ProjectName": "my-build-project" }, "outputArtifacts": [ { "name": "BuildArtifact" } ], "inputArtifacts": [ { "name": "SourceArtifact" } ], "region": "us-west-2", "namespace": "BuildVariables" } ] . . . ``` ------ Eine Liste der Beispiel-`configuration` Details für den jeweiligen Anbietertyp finden Sie unter [Gültige Konfigurationsparameter für jeden Anbietertyp](structure-configuration-examples.md). Die Aktionsstruktur hat folgende Anforderungen: + Alle Aktionsnamen in einer Phase müssen eindeutig sein. + Für jede Pipeline ist eine Quellaktion erforderlich. + Quellaktionen, die keine Verbindung verwenden, können für die Änderungserkennung oder für die Deaktivierung der Änderungserkennung konfiguriert werden. Siehe [Methoden zur Änderungserkennung](change-detection-methods.md). + Dies trifft für alle Aktionen zu, unabhängig davon, ob sie in derselben Phase oder in folgenden Phasen enthalten sind. Das Eingabeartefakt muss aber nicht die nächste Aktion sein, die strikt auf die Aktion folgt, von der das Ausgabeartefakt bereitgestellt wurde. Parallele Aktionen können unterschiedliche Ausgabeartefaktpakete deklarieren, die im Gegenzug von verschiedenen Folgeaktionen genutzt werden. + Wenn Sie einen Amazon S3 S3-Bucket als Bereitstellungsort verwenden, geben Sie auch einen Objektschlüssel an. Ein Objektschlüssel kann ein Dateiname (Objekt) oder eine Kombination aus Präfix (Ordnerpfad) und Dateiname sein. Sie können Variablen verwenden, um den Namen des Speicherorts anzugeben, der von der Pipeline verwendet werden soll. Für Amazon S3-Bereitstellungsaktionen werden in Amazon S3-Objektschlüsseln die folgenden Variablen unterstützt. **Verwenden von Variablen in Amazon S3** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/action-requirements.html) ## `name` Den Namen der Aktion. ## `region` Für Aktionen, bei denen der Anbieter ein ist AWS-Service, AWS-Region der der Ressource. Bei regionsübergreifenden Aktionen wird in `Region` diesem Feld angegeben AWS-Region , wo die Aktionen erstellt werden sollen. Die für diese Aktion erstellten AWS Ressourcen müssen in derselben Region erstellt werden, die `region` im Feld angegeben wurde. Für die folgenden Aktionstypen können Sie keine regionsübergreifenden Aktionen erstellen: + Quellaktionen + Aktionen von Drittanbietern + Aktionen von benutzerdefinierten Anbietern ## `roleArn` Der ARN der IAM-Servicerolle, die die angegebene Aktion ausführt. Dies wird durch das RoleARN vorausgesetzt, das auf Pipeline-Ebene spezifiziert ist. ## `namespace` Aktionen können mit Variablen konfiguriert werden. Sie legen die Namespace- und Variableninformationen für Ausführungsvariablen im Feld `namespace` fest. Referenzinformationen zu Ausführungsvariablen und Aktionsausgabevariablen finden Sie unter [Variablen-Referenz](reference-variables.md). **Anmerkung** Für Amazon ECR, Amazon S3 oder CodeCommit Quellen können Sie auch eine Quellüberschreibung mithilfe des Eingabe-Transformationseintrags erstellen, um den `revisionValue` In EventBridge für Ihr Pipeline-Ereignis zu verwenden, wobei der von der Quellereignisvariablen für Ihren Objektschlüssel, Ihren Commit oder Ihre Image-ID abgeleitet `revisionValue` wird. Weitere Informationen finden Sie im optionalen Schritt für die Eingabe der Eingabetransformation, der in den Verfahren unter [Amazon ECR-Quellaktionen und Ressourcen EventBridge](create-cwe-ecr-source.md)[Verbindung zu Amazon S3 S3-Quellaktionen mit einer für Ereignisse aktivierten Quelle herstellen](create-S3-source-events.md), oder [CodeCommit Quellaktionen und EventBridge](triggering.md) enthalten ist. ## `actionTypeId` Die Aktionstyp-ID wird als Kombination der folgenden vier Felder identifiziert. ### `category` Die Art der Aktion oder des Schritts in der Pipeline, z. B. eine Quellaktion. Jeder Aktionstyp hat einen bestimmten Satz gültiger Aktionsanbieter. Eine Liste der gültigen Anbieter nach Aktionstyp finden Sie unter[Referenz der Aktionsstruktur](action-reference.md). Dies sind die gültigen `actionTypeId` Kategorien (Aktionstypen) für CodePipeline: + `Source` + `Build` + `Approval` + `Deploy` + `Test` + `Invoke` + `Compute` ### `owner` Für alle derzeit unterstützten Aktionstypen ist die einzig gültige Besitzerzeichenfolge`AWS`,`ThirdParty`, oder`Custom`. Die gültige Besitzerzeichenfolge für eine bestimmte Aktion finden Sie unter[Referenz der Aktionsstruktur](action-reference.md). Weitere Informationen finden Sie in der [CodePipeline -API-Referenz](https://docs.aws.amazon.com/codepipeline/latest/APIReference). ### `version` Die Version der Aktion. ### `provider` Der Aktionsanbieter, z. CodeBuild B. + Welche Anbietertypen für eine Aktionskategorie gültig sind, hängt von der Kategorie ab. Ein gültiger Anbietertyp für eine Quellaktionskategorie ist beispielsweise `S3``CodeStarSourceConnection`,`CodeCommit`, oder`Amazon ECR`. Dieses Beispiel zeigt die Struktur für eine Quellaktion mit einem `S3`-Anbieter: ``` "actionTypeId": { "category": "Source", "owner": "AWS", "version": "1", "provider": "S3"}, ``` ## `InputArtifacts` Dieses Feld enthält die Eingabeartefaktstruktur, sofern sie für die Aktionskategorie unterstützt wird. Das Eingabeartefakt einer Aktion muss exakt mit dem Ausgabeartefakt übereinstimmen, das in einer vorherigen Aktion deklariert wurde. Wenn beispielsweise eine vorherige Aktion die folgende Erklärung enthält: ``` "outputArtifacts": [ { "MyApp" } ], ``` und keine anderen Ausgabeartefakte vorhanden sind, muss das Eingabeartefakt einer nachfolgenden Aktion folgendermaßen lauten: ``` "inputArtifacts": [ { "MyApp" } ], ``` Beispielsweise kann eine Quellaktion keine Eingabeartefakte haben, da es sich um die erste Aktion in der Pipeline handelt. Eine Quellaktion hat jedoch immer Ausgabeartefakte, die von der folgenden Aktion verarbeitet werden. Bei den Ausgabeartefakten für eine Quellaktion handelt es sich um die Anwendungsdateien aus dem Quell-Repository, die gezippt und über den Artefakt-Bucket bereitgestellt werden. Sie werden durch die folgende Aktion verarbeitet, z. B. eine CodeBuild Aktion, die mit Build-Befehlen auf die Anwendungsdateien einwirkt. Ein Beispiel für Aktionen, die keine Ausgabeartefakte haben können, sind Bereitstellungsaktionen ohne Ausgabeartefakte, da diese Aktionen in der Regel die letzte Aktion in einer Pipeline sind. ### `name` Der Artefaktname für die Eingabeartefakte der Aktion. ## `outputArtifacts` Namen von Ausgabeartefakten müssen in einer Pipeline eindeutig sein. Eine Pipeline kann z. B. eine Aktion mit einem Ausgabeartefakt namens `"MyApp"` und eine weitere Aktion mit einem Ausgabeartefakt namens `"MyBuiltApp"` enthalten. Eine Pipeline kann jedoch nicht zwei Aktionen enthalten, die beide ein Ausgabeartefakt mit dem Namen `"MyApp"` haben. Dieses Feld enthält die Ausgabe-Artefaktstruktur, sofern sie für die Aktionskategorie unterstützt wird. Das Ausgabe-Artefakt einer Aktion muss exakt mit dem Ausgabe-Artefakt übereinstimmen, das in einer vorherigen Aktion deklariert wurde. Wenn beispielsweise eine vorherige Aktion die folgende Erklärung enthält: ``` "outputArtifacts": [ { "MyApp" } ], ``` und keine anderen Ausgabeartefakte vorhanden sind, muss das Eingabeartefakt einer nachfolgenden Aktion folgendermaßen lauten: ``` "inputArtifacts": [ { "MyApp" } ], ``` Beispielsweise kann eine Quellaktion keine Eingabeartefakte haben, da es sich um die erste Aktion in der Pipeline handelt. Eine Quellaktion hat jedoch immer Ausgabeartefakte, die von der folgenden Aktion verarbeitet werden. Bei den Ausgabeartefakten für eine Quellaktion handelt es sich um die Anwendungsdateien aus dem Quell-Repository, die gezippt und über den Artefakt-Bucket bereitgestellt werden. Sie werden durch die folgende Aktion verarbeitet, z. B. eine CodeBuild Aktion, die mit Build-Befehlen auf die Anwendungsdateien einwirkt. Ein Beispiel für Aktionen, die keine Ausgabeartefakte haben können, sind Bereitstellungsaktionen ohne Ausgabeartefakte, da diese Aktionen in der Regel die letzte Aktion in einer Pipeline sind. ### `name` Der Artefaktname für die Ausgabeartefakte der Aktion. ## `configuration`(nach Aktionsanbieter) Die Aktionskonfiguration enthält Details und Parameter, die dem Anbietertyp entsprechen. Im folgenden Abschnitt sind die Konfigurationsparameter für Beispielaktionen spezifisch für die S3-Quellaktion. Die Aktionskonfiguration und die input/output Artefaktgrenzen können je nach Aktionsanbieter variieren. Eine Liste mit Beispielen für die Aktionskonfiguration nach Aktionsanbietern finden Sie unter [Referenz der Aktionsstruktur](action-reference.md) und in [Gültige Konfigurationsparameter für jeden Anbietertyp](structure-configuration-examples.md) der Tabelle unter. Die Tabelle enthält einen Link zur Aktionsreferenz für jeden Anbietertyp, in der die Konfigurationsparameter für jede Aktion detailliert aufgeführt sind. Eine Tabelle mit den Grenzwerten für Eingabe- und Ausgabeartefakte für jeden Aktionsanbieter finden Sie unter[Gültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp](reference-action-artifacts.md). Die folgenden Überlegungen gelten für die Arbeit mit Aktionen: + Quellaktionen haben keine Eingabeartefakte und Bereitstellungsaktionen haben keine Ausgabeartefakte. + Bei Anbietern von Quellaktionen, die keine Verbindung verwenden, wie S3, müssen Sie den `PollForSourceChanges` Parameter verwenden, um anzugeben, ob Ihre Pipeline automatisch gestartet werden soll, wenn eine Änderung erkannt wird. Siehe [Gültige Einstellungen für den `PollForSourceChanges` Parameter](PollForSourceChanges-defaults.md). + Informationen zum Konfigurieren der automatischen Änderungserkennung zum Starten Ihrer Pipeline oder zum Deaktivieren der Änderungserkennung finden Sie unter[Quellaktionen und Methoden zur Erkennung von Änderungen](change-detection-methods.md). + Um Trigger mit Filterung zu konfigurieren, verwenden Sie die Quellaktion für Verbindungen[Automatisieren Sie das Starten von Pipelines mithilfe von Triggern und Filtern](pipelines-triggers.md). Weitere Informationen finden Sie unter. + Die Ausgabevariablen für die einzelnen Aktionen finden Sie unter[Variablen-Referenz](reference-variables.md). **Anmerkung** Für Amazon ECR, Amazon S3 oder CodeCommit Quellen können Sie auch eine Quellüberschreibung mithilfe des Eingabe-Transformationseintrags erstellen, um den `revisionValue` In EventBridge für Ihr Pipeline-Ereignis zu verwenden, wobei der von der Quellereignisvariablen für Ihren Objektschlüssel, Ihren Commit oder Ihre Image-ID abgeleitet `revisionValue` wird. Weitere Informationen finden Sie im optionalen Schritt für die Eingabe der Eingabetransformation, der in den Verfahren unter [Amazon ECR-Quellaktionen und Ressourcen EventBridge](create-cwe-ecr-source.md)[Verbindung zu Amazon S3 S3-Quellaktionen mit einer für Ereignisse aktivierten Quelle herstellen](create-S3-source-events.md), oder [CodeCommit Quellaktionen und EventBridge](triggering.md) enthalten ist. **Wichtig** Bei Pipelines, die länger als 30 Tage inaktiv sind, ist das Polling für die Pipeline deaktiviert. Weitere Informationen finden Sie [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)in der Referenz zur Pipeline-Struktur. Die Schritte zur Migration Ihrer Pipeline von der Abfrage zur ereignisbasierten Änderungserkennung finden Sie unter Methoden zur [Änderungserkennung](change-detection-methods.md). **Anmerkung** Für die Quellaktionen CodeCommit und S3 ist entweder eine konfigurierte Ressource zur Änderungserkennung (eine EventBridge Regel) erforderlich, oder Sie verwenden die Option, das Repository nach Quelländerungen abzufragen. Für Pipelines mit einer Bitbucket GitHub - oder GitHub Enterprise Server-Quellaktion musst du weder einen Webhook einrichten noch standardmäßig Polling verwenden. Die Aktion „Verbindungen“ verwaltet die Erkennung von Änderungen für dich. ## `runOrder` Eine positive Ganzzahl, die die Ausführungsreihenfolge der Aktion innerhalb der Phase angibt. Parallele Aktionen in der Phase werden so angezeigt, als hätten sie dieselbe Ganzzahl. Beispielsweise werden zwei Aktionen mit einer Ausführungsreihenfolge von zwei parallel ausgeführt, nachdem die erste Aktion in der Phase ausgeführt wurde. Der standardmäßige `runOrder`-Wert für eine Aktion ist 1. Der Wert muss eine positive Ganzzahl (natürliche Zahl) sein. Sie können keine Bruchzahlen, Dezimalzahlen, negative Zahlen oder Null verwenden. Für eine serielle Reihenfolge von Aktionen geben Sie die niedrigste Zahl für die erste Aktion und höhere Zahlen für jede der verbleibenden Aktionen in der Abfolge an. Parallele Aktionen geben Sie an, indem Sie dieselbe Ganzzahl für jede Aktion verwenden, die parallel ausgeführt werden soll. In der Konsole können Sie eine serielle Reihenfolge für eine Aktion angeben, indem **Sie Aktionsgruppe hinzufügen** auf der Ebene der Phase auswählen, auf der sie ausgeführt werden soll, oder Sie können eine parallel Reihenfolge angeben, indem Sie **Aktion hinzufügen** wählen. *Aktionsgruppe* bezieht sich auf eine Ausführungsreihenfolge einer oder mehrerer Aktionen auf derselben Ebene. Wenn Sie beispielsweise drei Aktionen der Reihe nach in einer Phase ausführen möchten, geben Sie der ersten Aktion den `runOrder`-Wert 1, der zweiten Aktion den `runOrder`-Wert 2 und der dritten den `runOrder`-Wert 3. Wenn Sie jedoch die zweite und dritte Aktion parallel ausführen möchten, geben Sie der ersten Aktion den `runOrder`-Wert 1 und sowohl der zweiten als auch der dritten Aktion den `runOrder`-Wert 2. **Anmerkung** Die Nummerierung aufeinanderfolgender Aktionen muss nicht in strenger Reihenfolge sein. Wenn Sie beispielsweise drei Aktionen in einer Reihenfolge haben und die zweite Aktion entfernen möchten, müssen Sie den `runOrder`-Wert der dritten Aktion nicht neu nummerieren. Da der `runOrder`-Wert dieser Aktion (3) höher ist als der `runOrder`-Wert der ersten Aktion (1), wird sie nach der ersten Aktion in der Phase ausgeführt. # Gültige Aktionsanbieter in CodePipeline Das Pipeline-Struktur-Format wird verwendet, um Aktionen und Phasen in einer Pipeline zu erstellen. Ein Aktionstyp besteht aus einer Aktionskategorie und einem Anbietertyp. Jede Aktionskategorie hat eine gültige Liste von Aktionsanbietern. Eine Referenz zu den gültigen Aktionsanbietern für jede Aktionskategorie finden Sie unter[Referenz der Aktionsstruktur](action-reference.md). Jede Aktionskategorie verfügt über einen designierten Satz von Anbietern. Jeder Aktionsanbieter, wie Amazon S3, hat einen Anbieternamen, z. B.`S3`, der in dem `Provider` Feld in der Aktionskategorie in Ihrer Pipeline-Struktur verwendet werden muss. Es gibt drei gültige Werte für das `Owner`-Feld im Abschnitt „Aktionskategorie“ in der Pipeline-Struktur: `AWS`, `ThirdParty` und `Custom`. Den Anbieternamen und die Eigentümerinformationen für Ihren Aktionsanbieter finden Sie unter [Referenz der Aktionsstruktur](action-reference.md) oder[Gültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp](reference-action-artifacts.md). Diese Tabelle führt die gültigen Anbieter nach Aktionstyp auf. **Anmerkung** Informationen zu Bitbucket GitHub - oder GitHub Enterprise Server-Aktionen findest du im Referenzthema [CodeStarSourceConnection für Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com und GitLab selbstverwaltete Aktionen](action-reference-CodestarConnectionSource.md) Aktionen. **Gültige Aktionsanbieter nach Aktionstyp** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/actions-valid-providers.html) Einige Aktionstypen in CodePipeline sind nur in ausgewählten AWS Regionen verfügbar. Es ist möglich, dass ein Aktionstyp in einer AWS Region verfügbar ist, aber ein AWS Anbieter für diesen Aktionstyp ist nicht verfügbar. Weitere Informationen zu den einzelnen Aktionsanbietern finden Sie unter [Integrationen mit CodePipeline Aktionstypen](integrations-action-type.md). # Gültige Einstellungen für den `PollForSourceChanges` Parameter Der Standard für den Parameter `PollForSourceChanges` wird von der Methode festgelegt, mit der die Pipeline erstellt wird, wie in der nachfolgenden Tabelle beschrieben. In vielen Fällen ist die Standardeinstellung für den Parameter `PollForSourceChanges` „true“ und muss deaktiviert werden. Wenn der `PollForSourceChanges`-Parameter standardmäßig „true“ ist, sollten Sie wie folgt vorgehen: + Fügen Sie den Parameter `PollForSourceChanges` der JSON-Datei oder der CloudFormation -Vorlage hinzu. + Erstellen Sie Ressourcen zur Änderungserkennung (CloudWatch Eventregel, sofern zutreffend). + Stellen Sie den `PollForSourceChanges`-Parameter auf "false" ein. **Anmerkung** Wenn Sie eine CloudWatch Ereignisregel oder einen Webhook erstellen, müssen Sie den Parameter auf false setzen, um zu verhindern, dass die Pipeline mehr als einmal ausgelöst wird. Der `PollForSourceChanges` Parameter wird nicht für Amazon ECR-Quellaktionen verwendet. + **`PollForSourceChanges`Standardwerte für Parameter** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/PollForSourceChanges-defaults.html) # Gültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp Je nach Aktionstyp und Anbieter können Sie über die folgende Anzahl von Eingabe- und Ausgabeartefakten verfügen. **Aktionstypbedingungen für Artefakte** | Eigentümer | Aktionstyp | Anbieter | Gültige Zahl der Eingabeartefakte | Gültige Zahl der Ausgabeartefakte | | --- | --- | --- | --- | --- | | AWS | Quelle | S3 | 0 | 1 | | AWS | Quelle | CodeCommit | 0 | 1 | | AWS | Quelle | ECR | 0 | 1 | | ThirdParty | Quelle | CodeStarSourceConnection | 0 | 1 | | AWS | Entwicklung | CodeBuild | 1 bis 5 | 0 bis 5 | | AWS | Test | CodeBuild | 1 bis 5 | 0 bis 5 | | AWS | Test | DeviceFarm | 1 | 0 | | AWS | Genehmigung | ThirdParty | 0 | 0 | | AWS | Bereitstellen | S3 | 1 | 0 | | AWS | Bereitstellen | CloudFormation | 0 bis 10 | 0 bis 1 | | AWS | Bereitstellen | CodeDeploy | 1 | 0 | | AWS | Bereitstellen | ElasticBeanstalk | 1 | 0 | | AWS | Bereitstellen | OpsWorks | 1 | 0 | | AWS | Bereitstellen | ECS | 1 | 0 | | AWS | Bereitstellen | ServiceCatalog | 1 | 0 | | AWS | Invoke | Lambda | 0 bis 5 | 0 bis 5 | | ThirdParty | Bereitstellen | AlexaSkillsKit | 1 bis 2 | 0 | | Custom | Entwicklung | Jenkins | 0 bis 5 | 0 bis 5 | | Custom | Test | Jenkins | 0 bis 5 | 0 bis 5 | | Custom | Jede unterstützte Kategorie | Wie in der benutzerdefinierten Aktion angegeben | 0 bis 5 | 0 bis 5 | # Gültige Konfigurationsparameter für jeden Anbietertyp In diesem Abschnitt werden gültige `configuration`-Parameter für jeden Aktionsanbieter aufgeführt. Jede Aktion muss eine gültige Aktionskonfiguration aufweisen in Abhängigkeit zum Anbietertyp für diese Aktion. In der folgenden Tabelle sind die erforderlichen Aktionskonfigurationselemente für jeden gültigen Anbietertyp aufgeführt: **Aktionskonfigurationseigenschaften für Anbietertypen** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/structure-configuration-examples.html) Das folgende Beispiel zeigt eine gültige Konfiguration für eine Bereitstellungsaktion, für die das Alexa Skills Kit verwendet wird: ``` "configuration": { "ClientId": "amzn1.application-oa2-client.aadEXAMPLE", "ClientSecret": "****", "RefreshToken": "****", "SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE" } ``` Das folgende Beispiel zeigt eine gültige Konfiguration für eine manuelle Genehmigung: ``` "configuration": { "CustomData": "Comments on the manual approval", "ExternalEntityLink": "http://my-url.com", "NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification" } ```