Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Déclaration relative au pipeline Le niveau du pipeline et des métadonnées d'un pipeline possède une structure de base qui inclut les paramètres et la syntaxe suivants. Le paramètre de pipeline représente la structure des actions et des étapes à exécuter dans le pipeline. Pour plus d'informations, consultez l'[PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)objet dans le *guide de l'CodePipeline API*. L'exemple suivant montre le niveau de pipeline et de métadonnées de la structure de pipeline en JSON et YAML pour un pipeline de type 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\+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": { ... }, "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` Nom du pipeline. Lorsque vous modifiez ou mettez à jour un pipeline, le nom du pipeline ne peut pas être modifié. **Note** Si vous souhaitez renommer un pipeline existant, vous pouvez utiliser la commande CLI `get-pipeline` pour générer un fichier JSON contenant la structure de votre pipeline. Par la suite, vous pouvez utiliser la commande CLI `create-pipeline` pour créer un pipeline avec cette structure et lui attribuer un nouveau nom. ## `roleArn` L'ARN IAM pour le rôle de CodePipeline service, tel que arn:aws:iam : :80398Example:Role/ \_Service\_Role. CodePipeline Pour utiliser la console afin d'afficher l'ARN du rôle du service de pipeline au lieu de la structure JSON, choisissez votre pipeline dans la console, puis sélectionnez **Paramètres**. Sous l'onglet **Général**, le champ **ARN du rôle de service** s'affiche. ## `artifactStore`OU `artifactStores` Le `artifactStore` champ contient le type de compartiment d'artefacts et l'emplacement d'un pipeline comportant toutes les actions dans la même AWS région. Si vous ajoutez des actions dans une région différente de votre pipeline, le `artifactStores` mappage est utilisé pour répertorier le compartiment d'artefacts pour chaque AWS région dans laquelle les actions sont exécutées. Lorsque vous créez ou modifiez un pipeline, vous devez avoir un compartiment d'artefact dans le pipeline Région, puis vous devez disposer d'un compartiment d'artefact par région dans laquelle vous prévoyez d'exécuter une action. **Note** Dans la structure du pipeline, vous devez inclure l'un `artifactStore` ou l'autre `artifactStores` de vos pipelines, mais vous ne pouvez pas utiliser les deux. Si vous créez une action entre régions dans votre pipeline, vous devez utiliser `artifactStores`. L'exemple suivant illustre la structure de base d'un pipeline avec des actions inter-régions qui utilise le paramètre `artifactStores` : ``` "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` Type d'emplacement du compartiment d'artefacts, spécifié comme Amazon S3. ### `location` Le nom du compartiment Amazon S3 généré automatiquement pour vous la première fois que vous créez un pipeline à l'aide de la console, par exemple codepipeline-us-east -2-1234567890, ou tout compartiment Amazon S3 que vous fournissez à cette fin ## `stages` Ce paramètre contient le nom de chaque étape du pipeline. Pour plus d'informations sur les paramètres et la syntaxe au niveau de l'étape de la structure du pipeline, consultez l'[StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)objet dans le *guide de l' CodePipeline API*. La structure du pipeline pour les étapes répond aux exigences suivantes : + Un pipeline doit contenir au moins deux étapes. + La première étape d'un pipeline doit contenir au moins une action source. Elle peut contenir des actions source uniquement. + Seule la première étape d'un pipeline peut contenir des actions source. + Au moins une étape dans chaque pipeline doit comporter une action autre qu'une action source. + Tous les noms d'étapes dans un pipeline doivent être uniques. + Les noms de scène ne peuvent pas être modifiés dans la CodePipeline console. Si vous modifiez le nom d'une étape à l'aide de AWS CLI, et que l'étape contient une action avec un ou plusieurs paramètres secrets (tels qu'un OAuth jeton), la valeur de ces paramètres secrets n'est pas préservée. Vous devez entrer manuellement les valeurs des paramètres (qui sont masquées par quatre astérisques dans le JSON renvoyé par l'interface AWS CLI) et les inclure dans la structure JSON. **Important** Les pipelines inactifs pendant plus de 30 jours verront l'interrogation désactivée pour le pipeline. Pour plus d'informations, reportez-vous [pollingDisabledAt](#metadata.pollingDisabledAt)à la référence sur la structure du pipeline. Pour connaître les étapes à suivre pour faire passer votre pipeline du sondage à la détection des modifications basée sur les événements, consultez la section Méthodes de [détection des modifications](change-detection-methods.md). ## `version` Le numéro de version d'un pipeline est automatiquement généré et mis à jour chaque fois que vous mettez à jour le pipeline. ## `executionMode` Vous pouvez définir le mode d'exécution du pipeline afin de pouvoir définir le comportement du pipeline pour des exécutions consécutives, telles que la mise en file d'attente, le remplacement ou l'exécution en mode parallèle. Pour de plus amples informations, veuillez consulter [Définir ou modifier le mode d'exécution du pipeline](execution-modes.md). **Important** Pour les pipelines en mode PARALLÈLE, la restauration par étapes n'est pas disponible. De même, les conditions de défaillance associées à un type de résultat de restauration ne peuvent pas être ajoutées à un pipeline en mode PARALLÈLE. ## `pipelineType` Le type de pipeline spécifie la structure et les fonctionnalités disponibles dans le pipeline, par exemple pour un pipeline de type V2. Pour de plus amples informations, veuillez consulter [Types de pipelines](pipeline-types.md). ## `variables` Les variables au niveau du pipeline sont définies lors de la création du pipeline et résolues au moment de son exécution. Pour de plus amples informations, veuillez consulter [Référence aux variables](reference-variables.md). Pour un didacticiel avec une variable au niveau du pipeline transmise au moment de l'exécution du pipeline, voir. [Tutoriel : Utiliser des variables au niveau du pipeline](tutorials-pipeline-variables.md) ## `triggers` Les déclencheurs vous permettent de configurer votre pipeline pour qu'il démarre sur un type d'événement particulier ou sur un type d'événement filtré, par exemple lorsqu'une modification est détectée sur une branche ou une pull request en particulier. Les déclencheurs sont configurables pour les actions source avec des connexions qui utilisent l'`CodeStarSourceConnection`action dans CodePipeline GitHub, telles que Bitbucket et GitLab. Pour plus d'informations sur les actions source qui utilisent des connexions, consultez[Ajoutez des fournisseurs de sources tiers aux pipelines à l'aide de CodeConnections](pipelines-connections.md). Pour plus d'informations et des exemples plus détaillés, consultez[Automatisez le démarrage des pipelines en utilisant des déclencheurs et des filtres](pipelines-triggers.md). Pour le filtrage, les modèles d'expressions régulières au format global sont pris en charge, comme indiqué dans[Utilisation de modèles globulaires dans la syntaxe](syntax-glob.md). **Note** Les actions source CodeCommit et S3 nécessitent soit une ressource de détection des modifications configurée (une EventBridge règle), soit l'option permettant d'interroger le référentiel pour connaître les modifications de source. Pour les pipelines dotés d'une action source Bitbucket ou GitHub Enterprise Server, il n'est pas nécessaire de configurer un webhook ou d'effectuer un sondage par défaut. GitHub L'action Connexions gère pour vous la détection des modifications. **Important** Les pipelines inactifs pendant plus de 30 jours verront l'interrogation désactivée pour le pipeline. Pour plus d'informations, reportez-vous [pollingDisabledAt](#metadata.pollingDisabledAt)à la référence sur la structure du pipeline. Pour connaître les étapes à suivre pour faire passer votre pipeline du sondage à la détection des modifications basée sur les événements, consultez la section Méthodes de [détection des modifications](change-detection-methods.md). ### Champs de `gitConfiguration` La configuration Git du déclencheur, y compris les types d'événements et tous les paramètres de filtrage par branches, chemins de fichiers, balises ou événements de pull request. Les champs de la structure JSON sont définis comme suit : + `sourceActionName`: nom de l'action source du pipeline avec la configuration Git. + `push`: événements push avec filtrage. Ces événements utilisent une opération OR entre différents filtres push et une opération AND à l'intérieur des filtres. + `branches`: les branches sur lesquelles filtrer. Les branches utilisent une opération AND entre les inclusions et les exclusions. + `includes`: modèles à filtrer pour les branches qui seront incluses. Inclut l'utilisation d'une opération OR. + `excludes`: modèles à filtrer pour les branches qui seront exclues. Exclut l'utilisation d'une opération OR. + `filePaths`: noms des chemins de fichiers sur lesquels filtrer. + `includes`: modèles à filtrer pour les chemins de fichiers qui seront inclus. Inclut l'utilisation d'une opération OR. + `excludes`: modèles à filtrer pour les chemins de fichiers qui seront exclus. Exclut l'utilisation d'une opération OR. + `tags`: les noms de balises sur lesquels filtrer. + `includes`: modèles à filtrer pour les balises qui seront incluses. Inclut l'utilisation d'une opération OR. + `excludes`: modèles à filtrer pour les balises qui seront exclues. Exclut l'utilisation d'une opération OR. + `pullRequest`: événements de pull request avec filtrage sur les événements de pull request et filtres de pull request. + `events`: filtre les événements de pull request ouverts, mis à jour ou fermés selon les spécifications. + `branches`: les branches sur lesquelles filtrer. Les branches utilisent une opération AND entre les inclusions et les exclusions. + `includes`: modèles à filtrer pour les branches qui seront incluses. Inclut l'utilisation d'une opération OR. + `excludes`: modèles à filtrer pour les branches qui seront exclues. Exclut l'utilisation d'une opération OR. + `filePaths`: noms des chemins de fichiers sur lesquels filtrer. + `includes`: modèles à filtrer pour les chemins de fichiers qui seront inclus. Inclut l'utilisation d'une opération OR. + `excludes`: modèles à filtrer pour les chemins de fichiers qui seront exclus. Exclut l'utilisation d'une opération OR. Voici un exemple de configuration du déclencheur pour les types d'événements de type push et pull request. ``` "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`Champs de type d'événement à inclure et à exclure Le comportement d'inclusion et d'exclusion pour les niveaux des champs de configuration Git pour les types d'événements **push** est indiqué dans la liste suivante : ``` 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`Champs de type d'événement à inclure et à exclure Le comportement d'inclusion et d'exclusion pour les niveaux des champs de configuration Git pour les types d'événements de **pull request** est indiqué dans la liste suivante : ``` 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` Les champs des métadonnées du pipeline sont différentes de la structure du pipeline et ne peuvent pas être modifiés. Lorsque vous mettez à jour un pipeline, la date du champ des métadonnées `updated` change automatiquement. ### `pipelineArn` Le nom de ressource Amazon (ARN) du pipeline. Pour utiliser la console pour afficher l'ARN du pipeline au lieu de la structure JSON, choisissez votre pipeline dans la console, puis sélectionnez **Paramètres**. Sous l'onglet **Général**, le champ **ARN du pipeline** s'affiche. ### `created` Date et heure de création du pipeline. ### `updated` Date et heure de la dernière mise à jour du pipeline. ### `pollingDisabledAt` Date et heure auxquelles, pour un pipeline configuré pour interroger afin de détecter les modifications, le sondage a été désactivé. Les pipelines inactifs pendant plus de 30 jours verront l'interrogation désactivée pour le pipeline. + Les pipelines inactifs seront désactivés après 30 jours sans exécution. + Les pipelines utilisant EventBridge des CodeStar connexions ou des webhooks ne seront pas affectés. + Les pipelines actifs ne seront pas affectés. Pour plus d'informations, consultez le `pollingDisabledAt` paramètre sous [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html)objet dans le *guide de l' CodePipeline API*. Pour connaître les étapes à suivre pour faire passer votre pipeline du sondage à la détection des modifications basée sur les événements, consultez la section Méthodes de [détection des modifications](change-detection-methods.md).