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 sur le pipeline
Le pipeline et le niveau de métadonnées d'un pipeline ont une structure de base qui inclut les paramètres et la syntaxe suivants. Le paramètre du pipeline représente la structure des actions et des étapes à exécuter dans le pipeline.
Pour plus d'informations, consultez l'PipelineDeclarationobjet dans le Guide de CodePipeline l'API.
L'exemple suivant montre le pipeline et le niveau de métadonnées de la structure du pipeline à la fois en JSON et en YAML pour un pipeline de type V2.
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 : :80398 _. EXAMPLE:role/CodePipeline Service_Role
Pour utiliser la console afin d'afficher l'ARN du rôle de service de pipeline au lieu de la structure JSON, choisissez votre pipeline dans la console, puis choisissez 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 avec toutes les actions dans la même AWS région. Si vous ajoutez des actions dans une région différente de celle 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 dans votre pipeline, 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 pour le 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, tel que codepipeline-us-east-2-1234567890, ou tout compartiment Amazon S3 que vous provisionnez à cette fin
étapes
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'StageDeclarationobjet du 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 des scènes ne peuvent pas être modifiés dans la CodePipeline console. Si vous modifiez le nom d'un stage à l'aide de AWS CLI, et que le stage contient une action avec un ou plusieurs paramètres secrets (comme un jeton OAuth), 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 sondages seront désactivés pour les pipelines qui sont inactifs pendant plus de 30 jours. Pour plus d'informations, consultez la section « sondage » DisabledAt dans la référence sur la structure du pipeline. Pour connaître les étapes à suivre pour migrer votre pipeline de la détection des modifications par sondage vers la détection des modifications basée sur les événements, consultez la section Méthodes de détection des modifications.
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 spécifier 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.
Important
Pour les pipelines en mode PARALLÈLE, la restauration des étapes n'est pas disponible. De même, les conditions de défaillance avec un type de résultat d'annulation ne peuvent pas être ajoutées à un pipeline en mode PARALLÈLE.
Type de pipeline
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 canalisations.
variables
Les variables au niveau du pipeline sont définies lorsque le pipeline est créé et résolues au moment de l'exécution du pipeline. Pour de plus amples informations, veuillez consulter Référence des variables. Pour un didacticiel avec une variable au niveau du pipeline qui est transmise au moment de l'exécution du pipeline, consultez. Tutoriel : Utiliser des variables au niveau du pipeline
déclencheurs
Les déclencheurs vous permettent de configurer votre pipeline pour qu'il démarre sur un type d'événement particulier ou un type d'événement filtré, par exemple lorsqu'une modification sur une branche particulière ou une pull request est détectée. Les déclencheurs sont configurables pour les actions source avec des connexions qui utilisent l'CodeStarSourceConnectionaction dans CodePipeline, par exemple GitHub, Bitbucket et GitLab. Pour plus d'informations sur les actions source qui utilisent des connexions, consultezAjoutez des fournisseurs de sources tiers aux pipelines à l'aide de CodeConnections.
Pour plus d'informations et des exemples plus détaillés, consultezAutomatisez le démarrage des pipelines en utilisant des déclencheurs et des filtres.
Pour le filtrage, les modèles d'expressions régulières au format glob sont pris en charge, comme indiqué dansUtilisation de modèles globulaires dans la syntaxe.
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'utilisation de l'option permettant d'interroger le référentiel pour détecter les modifications apportées à la source. Pour les pipelines comportant une action source Bitbucket ou GitHub Enterprise Server, il n'est pas nécessaire de configurer un webhook ou de lancer un sondage par défaut. GitHub L'action Connections gère la détection des modifications pour vous.
Important
Les sondages seront désactivés pour les pipelines qui sont inactifs pendant plus de 30 jours. Pour plus d'informations, consultez la section « sondage » DisabledAt dans la référence sur la structure du pipeline. Pour connaître les étapes à suivre pour migrer votre pipeline de la détection des modifications par sondage vers la détection des modifications basée sur les événements, consultez la section Méthodes de détection des modifications.
Champs de configuration Git
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 ET à l'intérieur des filtres.-
branches: Les branches sur lesquelles filtrer. Les branches utilisent une opération ET 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: les noms des chemins de fichier sur lesquels filtrer.-
includes: modèles à utiliser pour filtrer les chemins de fichiers qui seront inclus. Inclut l'utilisation d'une opération OR. -
excludes: modèles à utiliser pour filtrer 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 sur lesquels filtrer les balises qui seront exclues. Exclut l'utilisation d'une opération OR.
-
-
-
pullRequest: événements de demande d'extraction avec filtrage sur les événements de demande d'extraction et filtres de demande d'extraction.-
events: filtre les événements de pull request ouverts, mis à jour ou fermés, comme spécifié. -
branches: Les branches sur lesquelles filtrer. Les branches utilisent une opération ET 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: les noms des chemins de fichier sur lesquels filtrer.-
includes: modèles à utiliser pour filtrer les chemins de fichiers qui seront inclus. Inclut l'utilisation d'une opération OR. -
excludes: modèles à utiliser pour filtrer les chemins de fichiers qui seront exclus. Exclut l'utilisation d'une opération OR.
-
-
Voici un exemple de configuration des déclencheurs 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" ] } } ] } } ],
Champs push de type d'événement pour 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 illustré 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)
Champs de demande d'extraction de type d'événement pour 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 illustré 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 afin d'afficher l'ARN du pipeline au lieu de la structure JSON, choisissez votre pipeline dans la console, puis choisissez Paramètres. Sous l'onglet Général, le champ Pipeline ARN s'affiche.
créé
Date et heure de création du pipeline.
updated
Date et heure de la dernière mise à jour du pipeline.
sondage DisabledAt
Date et heure auxquelles, pour un pipeline configuré pour le sondage pour la détection des modifications, le sondage a été désactivé.
Les sondages seront désactivés pour les pipelines qui sont inactifs pendant plus de 30 jours.
-
Les sondages seront désactivés pour les pipelines inactifs 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 object dans le Guide de l' CodePipeline API. Pour connaître les étapes à suivre pour migrer votre pipeline de la détection des modifications par sondage vers la détection des modifications basée sur les événements, consultez la section Méthodes de détection des modifications.
