CodePipeline Referenz zur Pipeline-Struktur - AWS CodePipeline

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

Standardmäßig hat jede in AWS CodePipeline erfolgreich erstellte Pipeline eine gültige Struktur. Wenn Sie jedoch eine JSON-Datei manuell erstellen oder bearbeiten, um eine Pipeline über die AWS CLI zu erstellen oder zu aktualisieren, könnten Sie unbeabsichtigt eine Struktur schaffen, 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, die für alle Pipelines gelten.

Gültige Aktionstypen und Anbieter 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.

Nachfolgend sehen Sie die gültigen Aktionskategorien in CodePipeline:

  • Quelle

  • Entwicklung

  • Test

  • Bereitstellen

  • Genehmigung

  • Aufrufen

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.

Informationen zum Anbieternamen und Eigentümerinformationen für Ihren Aktionsanbieter finden Sie unter Referenz der Aktionsstruktur oder Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp.

Diese Tabelle führt die gültigen Anbieter nach Aktionstyp auf.

Anmerkung

Informationen zu Bitbucket Cloud- GitHub, GitHub Enterprise Server- oder GitLab .com-Aktionen findest du im Referenzthema CodeStarSourceConnection für Bitbucket Cloud, GitHub, GitHub Enterprise Server, GitLab.com und GitLab selbstverwaltete Aktionen Aktionen.

Gültige Aktionsanbieter nach Aktionstyp
Aktionskategorie Gültige Aktionsanbieter Aktionsreferenz
Quelle Amazon S3 Quellaktion für Amazon S3
Amazon ECR Amazon ECR
CodeCommit CodeCommit
CodeStarSourceConnection (für Bitbucket Cloud- GitHub, GitHub Enterprise Server- oder GitLab .com-Aktionen) CodeStarSourceConnection für Bitbucket Cloud, GitHub, GitHub Enterprise Server, GitLab.com und GitLab selbstverwaltete Aktionen
Entwicklung CodeBuild AWS CodeBuild
Benutzerdefiniert CloudBees Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Benutzerdefiniert Jenkins Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Benutzerdefiniert TeamCity Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Test CodeBuild AWS CodeBuild
AWS Device Farm Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
ThirdParty GhostInspector Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Benutzerdefiniert Jenkins Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
ThirdParty Micro Focus StormRunner Load Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
ThirdParty Nouvola Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Bereitstellen Amazon S3 Amazon S3 S3-Aktionen
AWS CloudFormation AWS CloudFormation
AWS CloudFormation StackSets (beinhaltet die Aktionen CloudFormationStackSet undCloudFormationStackInstances) AWS CloudFormation StackSets
CodeDeploy Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Amazon ECS Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Amazon ECS (blau/grün) (dies ist die CodeDeployToECS-Aktion) Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Elastic Beanstalk Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
AWS AppConfig AWSAppConfig
AWS OpsWorks Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Service Catalog Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Amazon Alexa Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Benutzerdefiniert XebiaLabs Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Genehmigung Manuell Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp
Aufrufen AWS Lambda AWS Lambda
AWS Step Functions AWS Step Functions

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.

In den folgenden Abschnitten finden Sie Beispiele für Anbieterinformationen und Konfigurationseigenschaften für jeden Aktionstyp.

Anforderungen an die Pipeline- und Phasenstruktur in CodePipeline

Eine zweiphasige Pipeline hat die folgende Grundstruktur:

{ "roleArn": "An IAM ARN for a service role, such as arn:aws:iam::80398EXAMPLE:role/CodePipeline_Service_Role", "stages": [ { "name": "SourceStageName", "actions": [ ... See Anforderungen an die Aktionsstruktur in CodePipeline ... ] }, { "name": "NextStageName", "actions": [ ... See Anforderungen an die Aktionsstruktur in CodePipeline ... ] } ], "artifactStore": { "type": "S3", "location": "The name of the Amazon S3 bucket automatically generated for you the first time you create a pipeline using the console, such as codepipeline-us-east-2-1234567890, or any Amazon S3 bucket you provision for this purpose" }, "name": "YourPipelineName", "version": 1 }

Die Pipeline-Struktur hat folgende 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 der AWS CLI bearbeiten und die Phase eine Aktion mit einem oder mehreren geheimen Parametern (z. B. ein OAuth-Token) enthält, wird der Wert dieser geheimen Parameter nicht erhalten. 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.

  • Das artifactStore Feld enthält den Artefakt-Bucket-Typ und den Speicherort 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.

    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 codepipeline-us-east-1-1234567890" }, "us-west-2": { "type": "S3", "location": "S3 artifact bucket name, such as codepipeline-us-west-2-1234567890" } }, "stages": [ { ...
  • 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.

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

Die Versionsnummer einer Pipeline wird bei jedem Pipeline-Update automatisch generiert und aktualisiert.

Anforderungen an die Aktionsstruktur in CodePipeline

Eine Aktion hat die folgende anspruchsvolle Struktur:

[ { "inputArtifacts": [ An input artifact structure, if supported for the action category ], "name": "ActionName", "region": "Region", "namespace": "source_namespace", "actionTypeId": { "category": "An action category", "owner": "AWS", "version": "1" "provider": "A provider type for the action category", }, "outputArtifacts": [ An output artifact structure, if supported for the action category ], "configuration": { Configuration details appropriate to the provider type }, "runOrder": A positive integer that indicates the run order within the stage, } ]

Eine Liste der Beispiel-configuration Details für den jeweiligen Anbietertyp finden Sie unter Konfigurationsdetails nach Anbietertyp.

Die Aktionsstruktur hat folgende Anforderungen:

  • Alle Aktionsnamen in einer Phase müssen eindeutig sein.

  • Das Eingabeartefakt einer Aktion muss exakt mit dem in einer vorherigen Aktion deklarierten Ausgabeartefakt übereinstimmen. 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" } ],

    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.

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

  • Bei regionsübergreifenden Aktionen wird das Region Feld verwendet, um die AWS Region anzugeben, in der 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

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

  • Für alle derzeit unterstützten Aktionstypen ist die einzig gültige BesitzerzeichenfolgeAWS,ThirdParty, oderCustom. Weitere Informationen finden Sie in der CodePipeline -API-Referenz.

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

  • 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 UTC-Zeitstempel im folgenden Format: <JJJJ>-<MM>-TT>_<HH>-<MM>-<SS>

    Beispiel:

    js-application/2019-01-10_07-39-57.zip

    uuid js-application/{uuid}.zip Die UUID ist ein global eindeutiger Bezeichner, der garantiert mit keinem der vorhandenen Bezeichner identisch ist. Die UUID hat das Format (alle Ziffern im Hexadezimalformat): <8-Ziffern>-<4-Ziffern>-4-Ziffern>-<4-Ziffern>-<12-Ziffern>

    Beispiel:

    js-application/54a60075-b96a-4bf3-9013-db3a9EXAMPLE.zip

  • Dies sind die gültigen actionTypeId Kategorien für CodePipeline:

    • Source

    • Build

    • Approval

    • Deploy

    • Test

    • Invoke

    Einige Anbietertypen und Konfigurationsoptionen werden hier angegeben.

  • Welche Anbietertypen für eine Aktionskategorie gültig sind, hängt von der Kategorie ab. Beispielsweise ist ein gültiger Anbietertyp für einen Quellaktionstyp S3, GitHub, 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"},
  • 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
    Name des Anbieters Anbietername in Aktionstyp Konfigurationseigenschaften Erforderliche Eigenschaft?
    Amazon S3 (Aktionsanbieter bereitstellen) Weitere Informationen, einschließlich Beispielen zu Amazon S3 S3-Bereitstellungsaktionsparametern, finden Sie unterAmazon S3 S3-Aktionen.
    Amazon S3 (Quellaktionsanbieter) Weitere Informationen, einschließlich Beispielen zu Amazon S3 S3-Quellaktionsparametern, finden Sie unterQuellaktion für Amazon S3.
    Amazon ECR Weitere Informationen, einschließlich Beispielen zu Amazon ECR-Parametern, finden Sie unterAmazon ECR.
    CodeCommit Weitere Informationen, einschließlich Beispielen zu CodeCommit Parametern, finden Sie unterCodeCommit.
    GitHub Weitere Informationen, einschließlich Beispielen zu GitHub Parametern, finden Sie unterGitHub Referenz zur Quellaktionsstruktur der Version 1.
    AWS CloudFormation Weitere Informationen, einschließlich Beispiele im Zusammenhang mit AWS CloudFormation-Parametern, finden Sie unter AWS CloudFormation.
    CodeBuild Weitere Beschreibungen und Beispiele zu CodeBuild Parametern finden Sie unterAWS CodeBuild.
    CodeDeploy Weitere Beschreibungen und Beispiele zu CodeDeploy Parametern finden Sie unterAWS CodeDeploy.
    AWS Device Farm Weitere Informationen und Beispiele für AWS Device Farm-Parameter finden Sie unter AWS Device Farm.
    AWS Elastic Beanstalk ElasticBeanstalk ApplicationName Erforderlich
    EnvironmentName Erforderlich
    AWS Lambda Weitere Informationen, einschließlich Beispiele im Zusammenhang mit AWS Lambda-Parametern, finden Sie unter AWS Lambda.
    AWS OpsWorks Stacks OpsWorks Stack Erforderlich
    Layer Optional
    App Erforderlich
    Amazon ECS Weitere Beschreibungen und Beispiele zu Amazon ECS-Parametern finden Sie unterAmazon Elastic Container Service.
    Amazon ECS und CodeDeploy (Blau/Grün) Weitere Beschreibungen und Beispiele zu Amazon ECS und den CodeDeploy Blau/Grün-Parametern finden Sie unter. Amazon Elastic Container Service undCodeDeploy Blau-Grün-
    Service Catalog ServiceCatalog TemplateFilePath Erforderlich
    ProductVersionName Erforderlich
    ProductType Erforderlich
    ProductVersionDescription Optional
    ProductId Erforderlich
    Alexa Skills Kit AlexaSkillsKit ClientId Erforderlich
    ClientSecret Erforderlich
    RefreshToken Erforderlich
    SkillId Erforderlich
    Jenkins Der Name der Aktion, die Sie im CodePipeline Plugin für Jenkins angegeben haben (zum Beispiel) MyJenkinsProviderName ProjectName Erforderlich
    Manuelle Genehmigung Manual CustomData Optional
    ExternalEntityLink Optional
    NotificationArn Optional

Anzahl der Eingabe- und Ausgabe-Artefakte für jeden Aktionstyp

Je nach Aktionstyp können Sie die folgenden Zahlen für Eingabe- und Ausgabeartefakte verwenden:

Aktionstypbedingungen für Artefakte
Eigentümer Aktionstyp Anbieter Gültige Zahl der Eingabeartefakte Gültige Zahl der Ausgabeartefakte
AWS Quelle Amazon S3 0 1
AWS Quelle CodeCommit 0 1
AWS Quelle Amazon ECR 0 1
ThirdParty Quelle GitHub 0 1
AWS Entwicklung CodeBuild 1 bis 5 0 bis 5
AWS Test CodeBuild 1 bis 5 0 bis 5
AWS Test AWS Device Farm 1 0
AWS Genehmigung Manuell 0 0
AWS Bereitstellen Amazon S3 1 0
AWS Bereitstellen AWS CloudFormation 0 bis 10 0 bis 1
AWS Bereitstellen CodeDeploy 1 0
AWS Bereitstellen AWS Elastic Beanstalk 1 0
AWS Bereitstellen AWS OpsWorks Stacks 1 0
AWS Bereitstellen Amazon ECS 1 0
AWS Bereitstellen Service Catalog 1 0
AWS Aufrufen AWS Lambda 0 bis 5 0 bis 5
ThirdParty Bereitstellen Alexa Skills Kit 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

Standardeinstellungen für den Parameter PollForSourceChanges

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 AWS 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
    Quelle Erstellungsmethode Beispiel für „Konfiguration“ JSON-Struktur-Ausgabe
    CodeCommit Pipeline wird mit der Konsole erstellt (und die Konsole erstellt Änderungserkennungsressourcen). Der Parameter wird in der Pipeline-Strukturausgabe angezeigt und ist standardmäßig false.
    BranchName": "main", "PollForSourceChanges": "false", "RepositoryName": "my-repo"
    Die Pipeline wird mit der CLI oder erstelltAWS CloudFormation, und der PollForSourceChanges Parameter wird nicht in der JSON-Ausgabe angezeigt, sondern auf true .² gesetzt.
    BranchName": "main", "RepositoryName": "my-repo"
    Amazon S3 Pipeline wird mit der Konsole erstellt (und die Konsole erstellt Änderungserkennungsressourcen). Der Parameter wird in der Pipeline-Strukturausgabe angezeigt und ist standardmäßig false.
    "S3Bucket": "my-bucket", "S3ObjectKey": "object.zip", "PollForSourceChanges": "false"
    Die Pipeline wird mit der CLI oder erstelltAWS CloudFormation, und der PollForSourceChanges Parameter wird nicht in der JSON-Ausgabe angezeigt, sondern auf true .² gesetzt.
    "S3Bucket": "my-bucket", "S3ObjectKey": "object.zip"
    GitHub Pipeline wird mit der Konsole erstellt (und die Konsole erstellt Änderungserkennungsressourcen). Der Parameter wird in der Pipeline-Strukturausgabe angezeigt und ist standardmäßig false.
    "Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName" "PollForSourceChanges": "false", "Branch": "main" "OAuthToken": "****"
    Die Pipeline wird mit der CLI oder erstelltAWS CloudFormation, und der PollForSourceChanges Parameter wird nicht in der JSON-Ausgabe angezeigt, sondern auf true .² gesetzt.
    "Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName", "Branch": "main", "OAuthToken": "****"

    ² Wenn PollForSourceChanges zu irgendeinem Zeitpunkt der JSON-Struktur oder der AWS CloudFormation Vorlage hinzugefügt wurde, wird sie wie folgt angezeigt:

    "PollForSourceChanges": "true",

    ³ Informationen zu den Ressourcen zur Änderungserkennung, die für jeden Quellanbieter gelten, finden Sie unter Methoden zur Änderungserkennung.

Konfigurationsdetails nach Anbietertyp

In diesem Abschnitt werden gültige configuration-Parameter für jeden Aktionsanbieter aufgeführt.

Das folgende Beispiel zeigt eine gültige Konfiguration für eine Bereitstellungsaktion, die Service Catalog verwendet, für eine Pipeline, die in der Konsole ohne separate Konfigurationsdatei erstellt wurde:

"configuration": { "TemplateFilePath": "S3_template.json", "ProductVersionName": "devops S3 v2", "ProductType": "CLOUD_FORMATION_TEMPLATE", "ProductVersionDescription": "Product version description", "ProductId": "prod-example123456" }

Das folgende Beispiel zeigt eine gültige Konfiguration für eine Bereitstellungsaktion, die Service Catalog verwendet, für eine Pipeline, die in der Konsole mit einer separaten sample_config.json Konfigurationsdatei erstellt wurde:

"configuration": { "ConfigurationFilePath": "sample_config.json", "ProductId": "prod-example123456" }

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" }