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 ActionDeclarationObjekt im CodePipeline APIHandbuch.
Das folgende Beispiel zeigt die Aktionsebene der Pipeline-Struktur JSON sowohl in als auchYAML.
Eine Liste der Beispiel-configuration
Details für den jeweiligen Anbietertyp finden Sie unter Gültige Konfigurationsparameter für jeden Anbietertyp.
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.
-
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 Variable Beispiel für Konsoleneingabe Ausgang datetime js-application/{datetime}.zip UTCZeitstempel in diesem Format: < YYYY>-< MM >- DD >_< HH >-< MM >-< SS > Beispiel:
js-application/2019-01-10_07-39-57.zip
uuid js-application/{uuid}.zip Das UUID ist eine weltweit eindeutige Kennung, die sich garantiert von jeder anderen Kennung unterscheidet. Der UUID hat dieses Format (alle Ziffern im Hexadezimalformat): < 8-stellig >-< 4-stellig >- 4-stellig >-< 4-stellig >-< 12-stellig > Beispiel:
EXAMPLEjs-application/54a60075-b96a-4bf3-9013-db3a9 .zip
name
Den Namen der Aktion.
region
Für Aktionen, bei denen der Anbieter ein ist, der der Ressource. AWS-Service AWS-Region
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
Die ARN IAM Dienstrolle, die die deklarierte Aktion ausführt. Davon wird ausgegangen roleArn , was auf der Pipeline-Ebene angegeben 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.
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 unterReferenz der Aktionsstruktur.
Dies sind die gültigen actionTypeId
Kategorien (Aktionstypen) für CodePipeline:
-
Source
-
Build
-
Approval
-
Deploy
-
Test
-
Invoke
owner
Für alle derzeit unterstützten Aktionstypen ist die einzig gültige BesitzerzeichenfolgeAWS
,ThirdParty
, oderCustom
. Die gültige Besitzerzeichenfolge für eine bestimmte Aktion finden Sie unterReferenz der Aktionsstruktur.
Weitere Informationen finden Sie in der CodePipeline APIReferenz.
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
, oderAmazon ECR
. Dieses Beispiel zeigt die Struktur für eine Quellaktion mit einemS3
-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 Grenzwerte für Eingabe-/Ausgabeartefakte können je nach Aktionsanbieter variieren. Eine Liste mit Beispielen für die Aktionskonfiguration nach Aktionsanbietern finden Sie unter Referenz der Aktionsstruktur und in der Tabelle unter. Gültige Konfigurationsparameter für jeden Anbietertyp 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 unterGültige Eingabe- und Ausgabeartefakte für jeden Aktionstyp.
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. -
Informationen zum Konfigurieren der automatischen Änderungserkennung zum Starten Ihrer Pipeline oder zum Deaktivieren der Änderungserkennung finden Sie unterQuellaktionen und Methoden zur Erkennung von Änderungen.
-
Um Trigger mit Filterung zu konfigurieren, verwenden Sie die Quellaktion für VerbindungenAutomatisieren Sie das Starten von Pipelines mithilfe von Triggern und Filtern. Weitere Informationen finden Sie unter.
-
Die Ausgabevariablen für die einzelnen Aktionen finden Sie unterVariablen-Referenz.
Anmerkung
Die Quellaktionen CodeCommit und S3 erfordern entweder eine konfigurierte Ressource zur Änderungserkennung (eine EventBridge Regel) oder 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.