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