Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
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.
# Exécution d'un flux de travail
Une *exécution* est une itération unique d’un flux de travail. Au cours d'une exécution, CodeCatalyst exécute les actions définies dans le fichier de configuration du flux de travail et génère les journaux, artefacts et variables associés.
Vous pouvez démarrer une exécution manuellement ou automatiquement via un *déclencheur de flux de travail*. Un exemple de déclencheur de flux de travail peut être un développeur de logiciels qui envoie un commit à votre branche principale.
Vous pouvez également arrêter manuellement l'exécution d'un flux de travail en cours de traitement si vous l'avez lancé par erreur.
Si plusieurs exécutions de flux de travail sont lancées à peu près au même moment, vous pouvez configurer la façon dont vous souhaitez que ces exécutions soient mises en file d'attente. Vous pouvez utiliser le comportement de mise en file d'attente par défaut, selon lequel les courses sont mises en file d'attente les unes après les autres dans l'ordre dans lequel elles ont été lancées, ou vous pouvez faire en sorte qu'une exécution ultérieure remplace (ou « prenne le relais ») par rapport à une précédente pour accélérer votre course. Il est également possible de configurer les exécutions de votre flux de travail pour qu'elles se déroulent en parallèle, de sorte qu'aucune exécution n'en attende une autre.
Après avoir lancé l'exécution d'un flux de travail, manuellement ou automatiquement, vous pouvez consulter le statut de l'exécution et d'autres détails. Par exemple, vous pouvez voir quand il a été lancé, par qui il a été lancé et s'il est toujours en cours d'exécution.
**Topics**
+ [Démarrage manuel de l’exécution d’un flux de travail](workflows-manually-start.md)
+ [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md)
+ [Configuration de déclencheurs manuels uniquement](workflows-manual-only.md)
+ [Arrêt d'une exécution de flux de travail](workflows-stop.md)
+ [Arrêter l'exécution d'un flux de travail](workflows-gates.md)
+ [Exiger des approbations lors des exécutions de flux](workflows-approval.md)
+ [Configuration du comportement de mise en file d'attente des exécutions](workflows-configure-runs.md)
+ [Mise en cache des fichiers entre les exécutions du flux de travail](workflows-caching.md)
+ [Afficher le statut et les détails de l'exécution du flux de travail](workflows-view-run.md)
# Démarrage manuel de l’exécution d’un flux de travail
Dans Amazon CodeCatalyst, vous pouvez démarrer un flux de travail exécuté manuellement depuis la CodeCatalyst console.
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Note**
Vous pouvez également démarrer automatiquement un flux de travail en [configurant un déclencheur](workflows-add-trigger.md).
**Pour démarrer un flux de travail exécuté manuellement**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Cliquez sur **Exécuter**.
# Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs
Vous pouvez démarrer un CodeCatalyst flux de travail Amazon exécuté automatiquement à l'aide d'un déclencheur de flux de travail.
Un *déclencheur de flux* de travail, ou simplement un *déclencheur*, vous permet de démarrer automatiquement un flux de travail lorsque certains événements se produisent, comme un envoi de code. Vous souhaiterez peut-être configurer des déclencheurs pour éviter à vos développeurs de logiciels d'avoir à lancer des exécutions de flux de travail manuellement via la CodeCatalyst console.
Vous pouvez utiliser trois types de déclencheurs :
+ **Push** : un déclencheur de code push déclenche l'exécution d'un flux de travail chaque fois qu'un commit est envoyé.
+ **Demande** d'extraction : un déclencheur de demande d'extraction entraîne le démarrage d'un flux de travail chaque fois qu'une demande d'extraction est créée, révisée ou fermée.
+ **Planification** : un déclencheur de planification entraîne le démarrage d'un flux de travail selon un calendrier que vous définissez. Envisagez d'utiliser un déclencheur de planification pour exécuter des versions nocturnes de votre logiciel afin que les développeurs puissent travailler sur la dernière version le lendemain matin.
Vous pouvez utiliser les déclencheurs push, pull request et schedule seuls ou en combinaison dans le même flux de travail.
Les déclencheurs sont facultatifs : si vous n'en configurez aucun, vous ne pouvez démarrer un flux de travail que manuellement.
**Astuce**
Pour voir un déclencheur en action, lancez un projet avec un plan. La plupart des plans contiennent un flux de travail avec un déclencheur. Recherchez la `Trigger` propriété dans le fichier de définition du flux de travail du plan. Pour plus d'informations sur les modèles de présentation, consultez [Création d'un projet à l'aide d'un plan](projects-create.md#projects-create-console-template).
**Topics**
+ [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md)
+ [Directives d'utilisation pour les déclencheurs et les branches](workflows-add-trigger-considerations.md)
+ [Ajouter des déclencheurs aux flux de travail](workflows-add-trigger-add.md)
# Exemples : déclencheurs dans les flux de travail
Les exemples suivants montrent comment ajouter différents types de déclencheurs dans un fichier de définition de CodeCatalyst flux de travail Amazon.
Pour plus d'informations sur les déclencheurs, consultez [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
**Topics**
+ [Exemple : un simple déclencheur push à code](#workflows-add-trigger-examples-push-simple)
+ [Exemple : un simple déclencheur « push to main »](#workflows-add-trigger-examples-push-main)
+ [Exemple : un simple déclencheur de pull request](#workflows-add-trigger-examples-pull-simple)
+ [Exemple : un simple déclencheur de planification](#workflows-add-trigger-examples-schedule-simple)
+ [Exemple : un déclencheur avec un calendrier et des branches](#workflows-add-trigger-examples-schedule-branches)
+ [Exemple : un déclencheur avec un calendrier, un push et des branches](#workflows-add-trigger-examples-schedule-push-branches)
+ [Exemple : une gâchette avec une traction et des branches](#workflows-add-trigger-examples-pull-branches)
+ [Exemple : un déclencheur avec un pull, des branches et un événement « CLOSED »](#workflows-add-trigger-examples-push-pull-close)
+ [Exemple : un déclencheur avec un push, des branches et des fichiers](#workflows-add-trigger-examples-push-multi)
+ [Exemple : un déclencheur manuel](#workflows-add-trigger-examples-manual)
+ [Exemple : déclencheurs dans une configuration à CI/CD flux de travail multiples](#workflows-add-trigger-usecases)
## Exemple : un simple déclencheur push à code
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois que du code est *envoyé* à une branche de votre référentiel source.
Lorsque ce déclencheur est activé, CodeCatalyst lance un flux de travail exécuté à l'aide des fichiers de la branche vers laquelle vous *pointez* (c'est-à-dire la branche de destination).
Par exemple, si vous envoyez un commit à`main`, CodeCatalyst lance un flux de travail exécuté à l'aide du fichier de définition du flux de travail et d'autres fichiers source. `main`
Autre exemple, si vous envoyez un commit à`feature-branch-123`, CodeCatalyst lance un flux de travail exécuté à l'aide du fichier de définition du flux de travail et d'autres fichiers source. `feature-branch-123`
```
Triggers:
- Type: PUSH
```
**Note**
Si vous souhaitez qu'un flux de travail ne démarre que lorsque vous appuyez dessus`main`, consultez[Exemple : un simple déclencheur « push to main »](#workflows-add-trigger-examples-push-main).
## Exemple : un simple déclencheur « push to main »
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois que du code est transmis à la `main` branche (et *uniquement* à la `main` branche) de votre référentiel source.
```
Triggers:
- Type: PUSH
Branches:
- main
```
## Exemple : un simple déclencheur de pull request
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois qu'une pull request est créée ou révisée dans votre référentiel source.
Lorsque ce déclencheur est activé, CodeCatalyst lance un flux de travail exécuté à l'aide du fichier de définition du flux de travail et des autres fichiers source de la branche *d'*où vous effectuez l'extraction (c'est-à-dire la branche source).
Par exemple, si vous créez une pull request avec une branche source appelée `feature-123` et une branche de destination appelée`main`, CodeCatalyst lance un flux de travail exécuté à l'aide du fichier de définition du flux de travail et d'autres fichiers source. `feature-123`
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## Exemple : un simple déclencheur de planification
L'exemple suivant montre un déclencheur qui lance un flux de travail exécuté à minuit (UTC\$10) du lundi au vendredi.
Lorsque ce déclencheur est activé, CodeCatalyst lance une seule exécution de flux de travail pour chaque branche de votre référentiel source contenant un fichier de définition de flux de travail avec ce déclencheur.
Par exemple, si votre référentiel source comporte trois branches,, `main` `release-v1``feature-123`, et que chacune de ces branches contient un fichier de définition de flux de travail avec le déclencheur suivant, CodeCatalyst lance trois exécutions de flux de travail : une utilisant les fichiers dans`main`, une autre utilisant les fichiers dans `release-v1` et une autre utilisant les fichiers dans`feature-123`.
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 ? * MON-FRI *"
```
Pour plus d'exemples d'expressions cron que vous pouvez utiliser dans la `Expression` propriété, consultez[Expression](workflow-reference.md#workflow.triggers.expression).
## Exemple : un déclencheur avec un calendrier et des branches
L'exemple suivant montre un déclencheur qui lance un flux de travail exécuté à 18h15 (UTC\$10) tous les jours.
Lorsque ce déclencheur est activé, CodeCatalyst lance un flux de travail à l'aide des fichiers de la `main` branche et lance des exécutions supplémentaires pour chaque branche commençant par`release-`.
Par exemple, si vous avez des branches nommées`main`, `release-v1``bugfix-1`, `bugfix-2` dans votre référentiel source, CodeCatalyst démarre deux exécutions de flux de travail : l'une utilisant les fichiers dans`main`, l'autre utilisant les fichiers dans`release-v1`. Il ne lance *pas* les exécutions de flux de travail pour les `bugfix-1` branches `bugfix-1` et.
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
Pour plus d'exemples d'expressions cron que vous pouvez utiliser dans la `Expression` propriété, consultez[Expression](workflow-reference.md#workflow.triggers.expression).
## Exemple : un déclencheur avec un calendrier, un push et des branches
L'exemple suivant montre un déclencheur qui lance un flux de travail exécuté à minuit (UTC\$10) tous les jours, et chaque fois que le code est envoyé à la branche. `main`
Dans cet exemple :
+ L'exécution d'un flux de travail commence tous les jours à minuit. Le flux de travail exécuté utilise le fichier de définition du flux de travail et les autres fichiers source de la `main` branche.
+ Une exécution de flux de travail démarre également chaque fois que vous envoyez un commit à la `main` branche. Le flux de travail exécuté utilise le fichier de définition du flux de travail et les autres fichiers source de la branche de destination (`main`).
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 * * ? *"
Branches:
- main
- Type: PUSH
Branches:
- main
```
Pour plus d'exemples d'expressions cron que vous pouvez utiliser dans la `Expression` propriété, consultez[Expression](workflow-reference.md#workflow.triggers.expression).
## Exemple : une gâchette avec une traction et des branches
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois que quelqu'un ouvre ou modifie une pull request avec une branche de destination appelée`main`. Bien que la branche spécifiée dans la `Triggers` configuration le soit`main`, le flux de travail exécuté utilisera le fichier de définition du flux de travail et les autres fichiers *source de la branche source* (qui est la branche dont vous *extrayez*).
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
## Exemple : un déclencheur avec un pull, des branches et un événement « CLOSED »
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois qu'une pull request est fermée sur une branche commençant par`main`.
Dans cet exemple :
+ Lorsque vous fermez une pull request dont la branche de destination commence par`main`, l'exécution du flux de travail démarre automatiquement en utilisant le fichier de définition du flux de travail et les autres fichiers source de la branche source (désormais fermée).
+ Si vous avez configuré votre dépôt source pour supprimer automatiquement les branches après la fusion d'une pull request, ces branches n'auront jamais la possibilité d'entrer dans l'`CLOSED`état. Cela signifie que les branches fusionnées n'activeront pas le `CLOSED` déclencheur de pull request. Dans ce scénario, le seul moyen d'activer le `CLOSED` déclencheur est de fermer la pull request sans la fusionner.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- CLOSED
```
## Exemple : un déclencheur avec un push, des branches et des fichiers
L'exemple suivant montre un déclencheur qui lance l'exécution d'un flux de travail chaque fois qu'une modification est apportée au `filename.txt` fichier, ou à tout autre fichier du `src` répertoire, sur la `main` branche.
Lorsque ce déclencheur est activé, CodeCatalyst lance un flux de travail exécuté à l'aide du fichier de définition du flux de travail et des autres fichiers source de la `main` branche.
```
Triggers:
- Type: PUSH
Branches:
- main
FilesChanged:
- filename.txt
- src\/.*
```
## Exemple : un déclencheur manuel
Pour configurer un déclencheur manuel, omettez la `Triggers` section dans le fichier de définition du flux de travail. Sans cette section, les utilisateurs sont obligés de démarrer le flux de travail manuellement en cliquant sur le bouton **Exécuter** de la CodeCatalyst console. Pour de plus amples informations, veuillez consulter [Démarrage manuel de l’exécution d’un flux de travail](workflows-manually-start.md).
## Exemple : déclencheurs dans une configuration à CI/CD flux de travail multiples
Cet exemple décrit comment configurer des déclencheurs lorsque vous souhaitez utiliser des CodeCatalyst flux de travail Amazon distincts pour l'intégration continue (CI) et le déploiement continu (CD).
Dans ce scénario, vous configurez deux flux de travail :
+ un **flux de travail CI** : ce flux de travail crée et teste votre application lorsqu'une pull request est créée ou révisée.
+ un **flux de travail sur CD** : ce flux de travail crée et déploie votre application lorsqu'une pull request est fusionnée.
Le fichier de définition du **flux de travail CI** ressemblerait à ceci :
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
Actions:
BuildAction:
instructions-for-building-the-app
TestAction:
instructions-for-test-the-app
```
Le `Triggers` code indique de démarrer automatiquement un flux de travail chaque fois qu'un développeur de logiciel crée une pull request (ou en [modifie une](pull-requests-update.md)) demandant de fusionner sa branche de fonctionnalités avec la `main` branche. CodeCatalyst lance le flux de travail exécuté à l'aide du code source dans la branche source (qui est la branche des fonctionnalités).
Le fichier de définition du **flux de travail du CD** ressemblerait à ceci :
```
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildAction:
instructions-for-building-the-app
DeployAction:
instructions-for-deploying-the-app
```
Le `Triggers` code indique de démarrer le flux de travail automatiquement lorsqu'une fusion a `main` lieu. CodeCatalyst lance l'exécution du flux de travail à l'aide du code source de la `main` branche.
# Directives d'utilisation pour les déclencheurs et les branches
Cette section décrit certaines des principales directives relatives à la configuration des CodeCatalyst déclencheurs Amazon incluant des succursales.
Pour plus d'informations sur les déclencheurs, consultez [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
+ **Règle 1 :** Pour les déclencheurs de requêtes push et pull, si vous souhaitez spécifier une branche, vous devez spécifier la branche de destination (ou « vers ») dans la configuration du déclencheur. Ne spécifiez jamais la branche source (ou « de »).
Dans l'exemple suivant, une commande push depuis n'importe quelle branche `main` active le flux de travail.
```
Triggers:
- Type: PUSH
Branches:
- main
```
Dans l'exemple suivant, une pull request provenant de n'importe quelle branche `main` active le flux de travail.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
+ **Règle 2 :** Pour les déclencheurs push, une fois le flux de travail activé, le flux de travail s'exécute à l'aide du fichier de définition du flux de travail et des fichiers source dans la branche de *destination*.
+ **Règle 3 :** Pour les déclencheurs de pull request, une fois le flux de travail activé, le flux de travail s'exécute à l'aide du fichier de définition du flux de travail et des fichiers *source de la branche source* (même si vous avez spécifié la branche de destination dans la configuration du déclencheur).
+ **Règle 4 :** Le même déclencheur dans une branche peut ne pas s'exécuter dans une autre branche.
Considérez le déclencheur suivant :
```
Triggers:
- Type: PUSH
Branches:
- main
```
Si le fichier de définition du flux de travail contenant ce déclencheur existe dans `main` et est cloné dans celui-ci`test`, le flux de travail ne démarrera jamais automatiquement en utilisant les fichiers dans `test` (bien que vous puissiez démarrer le flux de travail *manuellement* pour qu'il utilise les fichiers dans`test`). Consultez la **directive 2** pour comprendre pourquoi le flux de travail ne s'exécutera jamais automatiquement en utilisant les fichiers contenus dans`test`.
Tenez également compte du déclencheur de pull request suivant :
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
Si le fichier de définition du flux de travail contenant ce déclencheur existe dans`main`, le flux de travail ne s'exécutera jamais à l'aide des fichiers contenus dans`main`. (Toutefois, si vous créez une `test` branche à partir de`main`, le flux de travail s'exécutera en utilisant les fichiers contenus dans`test`.) Consultez **la directive 3** pour comprendre pourquoi.
# Ajouter des déclencheurs aux flux de travail
Suivez les instructions suivantes pour ajouter un déclencheur push, pull ou de planification à votre CodeCatalyst flux de travail Amazon.
Pour plus d'informations sur les déclencheurs, consultez [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
------
#### [ Visual ]
**Pour ajouter un déclencheur (éditeur visuel)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, sélectionnez la case **Source** et **déclencheurs**.
1. Dans le volet de configuration, choisissez **Ajouter un déclencheur**.
1. Dans la boîte de dialogue **Ajouter un déclencheur**, entrez les informations dans les champs, comme suit.
**Type de déclencheur**
Spécifiez le type de déclencheur. Vous pouvez utiliser l'une des valeurs suivantes :
+ **Push** (éditeur visuel) ou `PUSH` (éditeur YAML)
Un déclencheur push lance l'exécution d'un flux de travail lorsqu'une modification est transmise à votre référentiel source. Le flux de travail exécuté utilisera les fichiers de la branche *vers* laquelle vous transférez (c'est-à-dire la branche de destination).
+ **Pull request** (éditeur visuel) ou `PULLREQUEST` (éditeur YAML)
Un déclencheur de pull request lance un flux de travail lorsqu'une pull request est ouverte, mise à jour ou fermée dans votre référentiel source. *Le flux de travail exécuté utilisera les fichiers de la branche d'où vous les extrayez (c'est-à-dire la branche source).*
+ **Calendrier** (éditeur visuel) ou `SCHEDULE` (éditeur YAML)
Un déclencheur de planification lance des exécutions de flux de travail selon un calendrier défini par une expression cron que vous spécifiez. Un flux de travail distinct démarrera pour chaque branche de votre référentiel source à l'aide des fichiers de la branche. (Pour limiter les branches sur lesquelles le déclencheur est activé, utilisez le champ **Branches** (éditeur visuel) ou la `Branches` propriété (éditeur YAML).)
Lorsque vous configurez un déclencheur de planification, suivez les instructions suivantes :
+ N'utilisez qu'un seul déclencheur de planification par flux de travail.
+ Si vous avez défini plusieurs flux de travail dans votre CodeCatalyst espace, nous vous recommandons de ne pas en planifier plus de 10 pour qu'ils démarrent simultanément.
+ Assurez-vous de configurer l'expression cron du déclencheur avec un délai suffisant entre les exécutions. Pour de plus amples informations, veuillez consulter [Expression](workflow-reference.md#workflow.triggers.expression).
Pour obtenir des exemples, consultez [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
**Événements pour la pull request**
Ce champ n'apparaît que si vous avez sélectionné le type de déclencheur de **demande Pull**.
Spécifiez le type d'événements de pull request qui lanceront l'exécution d'un flux de travail. Les valeurs valides sont les suivantes :
+ **Une pull request est créée** (éditeur visuel) ou `OPEN` (éditeur YAML)
L'exécution du flux de travail démarre lorsqu'une pull request est créée.
+ La **pull request est fermée** (éditeur visuel) ou `CLOSED` (éditeur YAML)
L'exécution du flux de travail démarre lorsqu'une pull request est fermée. Le comportement de l'`CLOSED`événement est délicat et il est préférable de le comprendre à l'aide d'un exemple. Pour plus d’informations, consultez [Exemple : un déclencheur avec un pull, des branches et un événement « CLOSED »](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close).
+ **Une nouvelle révision est apportée à la pull request** (éditeur visuel) ou `REVISION` (éditeur YAML)
L'exécution du flux de travail démarre lorsqu'une révision d'une pull request est créée. La première révision est créée lors de la création de la pull request. Ensuite, une nouvelle révision est créée chaque fois que quelqu'un envoie un nouveau commit vers la branche source spécifiée dans la pull request. Si vous incluez l'`REVISION`événement dans votre déclencheur de pull request, vous pouvez l'`OPEN`omettre, car il s'`REVISION`agit d'un sur-ensemble de. `OPEN`
Vous pouvez spécifier plusieurs événements dans le même déclencheur de pull request.
Pour obtenir des exemples, consultez [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
**Schedule**
Ce champ n'apparaît que si vous avez sélectionné le type de déclencheur **Schedule**.
Spécifiez l'expression cron qui décrit le moment où vous souhaitez que votre flux de travail planifié ait lieu.
Les expressions Cron CodeCatalyst utilisent la syntaxe à six champs suivante, où chaque champ est séparé par un espace :
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**Exemples d'expressions cron**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
Lorsque vous spécifiez des expressions cron dans CodeCatalyst, assurez-vous de suivre les instructions suivantes :
+ Spécifiez une seule expression cron par `SCHEDULE` déclencheur.
+ Mettez l'expression cron entre guillemets (`"`) dans l'éditeur YAML.
+ Spécifiez l'heure en temps universel coordonné (UTC). Les autres fuseaux horaires ne sont pas pris en charge.
+ Configurez au moins 30 minutes entre les exécutions. Une cadence plus rapide n'est pas prise en charge.
+ Spécifiez le *days-of-week* champ *days-of-month* ou, mais pas les deux. Si vous spécifiez une valeur ou un astérisque (`*`) dans l'un des champs, vous devez utiliser un point d'interrogation (`?`) dans l'autre. L'astérisque signifie « tout » et le point d'interrogation signifie « tout ».
Pour plus d'exemples d'expressions cron et des informations sur les caractères génériques tels que`?`, et `*``L`, consultez la [référence des expressions Cron](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) dans le guide de l'utilisateur *Amazon EventBridge *. Les expressions Cron entrent EventBridge et CodeCatalyst fonctionnent exactement de la même manière.
Pour des exemples de déclencheurs de planification, voir[Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
**Branches** et **modèle de branches**
(Facultatif)
Spécifiez les branches de votre référentiel source que le déclencheur surveille afin de savoir quand démarrer une exécution de flux de travail. Vous pouvez utiliser des modèles regex pour définir les noms de vos branches. Par exemple, utilisez `main.*` pour faire correspondre toutes les branches commençant par`main`.
Les branches à spécifier sont différentes selon le type de déclencheur :
+ Pour un déclencheur, spécifiez les branches *vers* lesquelles vous poussez, c'est-à-dire les branches de *destination*. Une exécution de flux de travail démarrera par branche correspondante, en utilisant les fichiers de la branche correspondante.
Exemples : `main.*`, `mainline`
+ Pour un déclencheur de pull request, spécifiez les branches *vers* lesquelles vous pointez, c'est-à-dire les branches de *destination*. Une exécution de flux de travail démarrera par branche correspondante, en utilisant le fichier de définition du flux de travail et les fichiers **source de la branche source** (et *non* de la branche correspondante).
Exemples :`main.*`,`mainline`, `v1\-.*` (correspond aux branches commençant par`v1-`)
+ Pour un déclencheur de planification, spécifiez les branches contenant les fichiers que vous souhaitez que votre exécution planifiée utilise. Une exécution de flux de travail démarrera par branche correspondante, en utilisant le fichier de définition du flux de travail et les fichiers source de la branche correspondante.
Exemples : `main.*`, `version\-1\.0`
**Note**
Si vous *ne spécifiez pas* de branches, le déclencheur surveille toutes les branches de votre référentiel source et lancera l'exécution d'un flux de travail à l'aide du fichier de définition du flux de travail et des fichiers source dans :
La branche vers laquelle vous poussez (*pour* les déclencheurs). Pour de plus amples informations, veuillez consulter [Exemple : un simple déclencheur push à code](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple).
La branche d'où vous effectuez *l'*extraction (pour les déclencheurs de pull request). Pour de plus amples informations, veuillez consulter [Exemple : un simple déclencheur de pull request](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple).
Toutes les succursales (pour les déclencheurs de calendrier). Une exécution de flux de travail démarrera par branche de votre référentiel source. Pour de plus amples informations, veuillez consulter [Exemple : un simple déclencheur de planification](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple).
Pour plus d'informations sur les branches et les déclencheurs, consultez[Directives d'utilisation pour les déclencheurs et les branches](workflows-add-trigger-considerations.md).
Pour obtenir plus d’exemples, consultez [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
**Fichiers modifiés**
Ce champ n'apparaît que si vous avez sélectionné le type de déclencheur de **demande **Push** ou Pull**.
Spécifiez les fichiers ou les dossiers de votre référentiel source que le déclencheur surveille afin de savoir quand démarrer une exécution de flux de travail. Vous pouvez utiliser des expressions régulières pour faire correspondre les noms de fichiers ou les chemins.
Pour obtenir des exemples, consultez [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter un déclencheur (éditeur YAML)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Ajoutez une `Triggers` section et les propriétés sous-jacentes en utilisant l'exemple suivant comme guide. Pour en savoir plus, consultez [Triggers](workflow-reference.md#triggers-reference) dans la rubrique [Définition du flux de travail YAML](workflow-reference.md).
Un déclencheur de code push peut ressembler à ceci :
```
Triggers:
- Type: PUSH
Branches:
- main
```
Un déclencheur de pull request peut ressembler à ceci :
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- OPEN
- REVISION
- CLOSED
```
Un déclencheur de planification peut ressembler à ceci :
```
Triggers:
- Type: SCHEDULE
Branches:
- main.*
# Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023
Expression: "15 1 ? * FRI 2022-2023"
```
Pour plus d'exemples d'expressions cron que vous pouvez utiliser dans la `Expression` propriété, consultez[Expression](workflow-reference.md#workflow.triggers.expression).
Pour plus d'exemples de déclencheurs push, pull request et schedule, consultez[Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Configuration de déclencheurs manuels uniquement
Vous pouvez limiter un flux de travail afin qu'il ne puisse être démarré manuellement que par votre équipe à l'aide du bouton **Exécuter** de la CodeCatalyst console. Pour configurer cette fonctionnalité, vous devez supprimer la `Triggers` section dans le fichier de définition du flux de travail. La `Triggers` section est incluse par défaut lorsque vous créez un flux de travail, mais elle est facultative et peut être supprimée.
Suivez les instructions ci-dessous pour supprimer la `Triggers` section du fichier de définition du flux de travail afin que le flux de travail ne puisse être démarré que manuellement.
Pour plus d'informations sur les déclencheurs, consultez [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
Pour plus d'informations sur l'exécution des flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
------
#### [ Visual ]
**Pour supprimer la section « Déclencheurs » (éditeur visuel)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Choisissez la case **Source** dans le diagramme du flux de travail.
1. Sous **Déclencheurs**, cliquez sur l'icône de la corbeille pour supprimer la `Triggers` section du flux de travail.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour supprimer la section « Déclencheurs » (éditeur YAML)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Trouvez la `Triggers` section et supprimez-la.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Arrêt d'une exécution de flux de travail
Utilisez la procédure suivante pour arrêter une exécution de flux de travail en cours. Vous voudrez peut-être arrêter une course si elle a été lancée par accident.
Lorsque vous arrêtez l'exécution d'un flux de CodeCatalyst travail, attendez que les actions en cours soient terminées avant de marquer l'exécution comme **arrêtée** dans la CodeCatalyst console. Les actions qui n'ont pas eu la chance de démarrer ne seront pas lancées et seront marquées comme **abandonnées**.
**Note**
Si une exécution est en file d'attente (c'est-à-dire qu'aucune action n'est en cours), elle est immédiatement arrêtée.
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Pour arrêter l'exécution d'un flux de travail**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Sous **Workflows**, choisissez **Exécutions** et choisissez l'exécution en cours dans la liste.
1. Choisissez **Arrêter**.
# Arrêter l'exécution d'un flux de travail
Une *porte* est un composant du flux de travail que vous pouvez utiliser pour empêcher l'exécution d'un flux de travail si certaines conditions ne sont pas remplies. Un exemple de porte est la porte d'**approbation** où les utilisateurs doivent soumettre une approbation dans la CodeCatalyst console avant que l'exécution du flux de travail ne soit autorisée à se poursuivre.
Vous pouvez ajouter des barrières entre les séquences d'actions d'un flux de travail ou avant la première action (qui s'exécute immédiatement après le téléchargement de la **source**). Vous pouvez également ajouter des portes après la dernière action, si nécessaire.
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Topics**
+ [Types de portes](#workflows-gates-types)
+ [Puis-je configurer une porte pour qu'elle s'exécute en parallèle à une autre action ?](#workflows-approval-parallel)
+ [Puis-je utiliser une porte pour empêcher le démarrage d'un flux de travail ?](#workflows-gates-prevent)
+ [Limites des portes](#workflows-gate-limitations)
+ [Ajouter une porte à un flux de travail](workflows-gates-add.md)
+ [Séquençage des portes et des actions](workflows-gates-depends-on.md)
+ [Spécifier la version d'une porte](workflows-gates-version.md)
## Types de portes
Amazon CodeCatalyst prend actuellement en charge un type de portail : le portail **d'approbation**. Pour de plus amples informations, veuillez consulter [Exiger des approbations lors des exécutions de flux](workflows-approval.md).
## Puis-je configurer une porte pour qu'elle s'exécute en parallèle à une autre action ?
Non. Les portes ne peuvent fonctionner qu'avant ou après une action. Pour de plus amples informations, veuillez consulter [Séquençage des portes et des actions](workflows-gates-depends-on.md).
## Puis-je utiliser une porte pour empêcher le démarrage d'un flux de travail ?
Oui, avec des qualifications.
Vous pouvez empêcher l'exécution d'un flux de travail d'*exécuter des tâches*, ce qui est légèrement différent de l'empêcher de *démarrer*.
Pour empêcher un flux de travail d'exécuter des tâches, ajoutez une barrière avant la toute première action d'un flux de travail. Dans ce scénario, une exécution de flux de travail *démarrera*, c'est-à-dire qu'il téléchargera les fichiers de votre référentiel source, mais il ne sera pas autorisé à effectuer des tâches tant que la porte ne sera pas déverrouillée.
**Note**
Les flux de travail qui démarrent puis sont bloqués par une porte sont toujours pris en compte dans votre *nombre maximum d'exécutions simultanées par quota d'espace* et dans d'autres quotas. Pour vous assurer de ne pas dépasser les quotas de flux de travail, pensez à utiliser un déclencheur de flux de travail pour démarrer un flux de travail de manière conditionnelle au lieu d'utiliser une porte. Pensez également à utiliser une règle d'approbation par pull request au lieu d'une porte. Pour plus d'informations sur les quotas, les déclencheurs et les règles d'approbation des pull requests[Quotas pour les flux de travail dans CodeCatalyst](workflows-quotas.md), consultez[Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md), et[Gestion des exigences relatives à la fusion d'une pull request avec les règles d'approbation](source-pull-requests-approval-rules.md).
## Limites des portes
Les barrières présentent les limites suivantes :
+ Les portes ne peuvent pas être utilisées conjointement avec la fonction de partage de calcul. Pour en savoir plus sur cette fonction, consultez [Partage du calcul entre les actions](compute-sharing.md).
+ Les portes ne peuvent pas être utilisées dans les groupes d'action. Pour plus d'informations sur les groupes d'actions, consultez[Regrouper les actions dans des groupes d'action](workflows-group-actions.md).
# Ajouter une porte à un flux de travail
Sur Amazon CodeCatalyst, vous pouvez ajouter une barrière à un flux de travail pour l'empêcher de se poursuivre si certaines conditions ne sont pas remplies. Suivez les instructions ci-dessous pour ajouter une porte à un flux de travail.
Pour plus d'informations sur les portes, voir[Arrêter l'exécution d'un flux de travail](workflows-gates.md).
**Pour ajouter et configurer un portail**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Sur la gauche, choisissez **Gates**.
1. Dans le catalogue de portes, recherchez une porte, puis choisissez le signe plus (**\$1**) pour ajouter la porte à votre flux de travail.
1. Configurez le portail. Choisissez **Visual** pour utiliser l'éditeur visuel ou **YAML** pour utiliser l'éditeur YAML. Pour des instructions détaillées, voir :
+ [Ajouter une porte « d'approbation »](workflows-approval-add.md)
1. (Facultatif) Choisissez **Valider** pour vous assurer que le code YAML est valide.
1. Choisissez **Valider** pour valider vos modifications.
# Séquençage des portes et des actions
Dans Amazon CodeCatalyst, vous pouvez configurer une porte à exécuter avant ou après une action de flux de travail, un groupe d'actions ou une porte. Par exemple, vous pouvez configurer une `Approval` porte pour qu'elle s'exécute avant une `Deploy` action. Dans ce cas, on dit que l'`Deploy`action *dépend* de la `Approval` porte.
Pour configurer les dépendances entre les portes et les actions, configurez la propriété **Depends on** de la porte ou de l'action. Pour obtenir des instructions, consultez [Configuration des dépendances entre les actions](workflows-depends-on-set-up.md). Les instructions référencées font référence aux *actions* du flux de travail mais s'appliquent également aux portes.
Pour un exemple de configuration de la propriété **Depends on** avec une porte, voir[Exemple : une porte « d'approbation »](workflows-approval-example.md).
Pour plus d'informations sur les portes, voir[Arrêter l'exécution d'un flux de travail](workflows-gates.md).
Pour plus d'informations sur les actions du flux de travail, consultez[Configuration des actions du flux de travail](workflows-actions.md).
# Spécifier la version d'une porte
Par défaut, lorsque vous ajoutez une porte à un flux de travail, la version complète est CodeCatalyst ajoutée au fichier de définition du flux de travail au format suivant :
`vmajor.minor.patch`
Par exemple :
```
My-Gate:
Identifier: aws/approval@v1
```
Vous pouvez allonger la version afin que le flux de travail utilise une version majeure ou mineure spécifique de la porte. Pour obtenir des instructions, consultez [Spécification de la version de l'action à utiliser](workflows-action-versions.md). La rubrique référencée fait référence aux actions du flux de travail mais s'applique également aux portes.
Pour plus d'informations sur Gates in CodeCatalyst, consultez[Arrêter l'exécution d'un flux de travail](workflows-gates.md).
# Exiger des approbations lors des exécutions de flux
Vous pouvez configurer l'exécution d'un flux de travail de manière à ce qu'il nécessite une approbation avant de pouvoir continuer. Pour ce faire, vous devez ajouter une [porte](workflows-gates.md) **d'approbation** au flux de travail. Une *porte d'approbation* empêche le déroulement d'un flux de travail tant qu'un utilisateur ou un groupe d'utilisateurs n'a pas soumis une ou plusieurs approbations dans la CodeCatalyst console. Une fois que toutes les approbations ont été données, la porte est « déverrouillée » et le flux de travail peut reprendre.
Utilisez une porte d'**approbation** dans votre flux de travail pour donner à vos équipes de développement, d'exploitation et de direction l'occasion d'examiner vos modifications avant qu'elles ne soient déployées auprès d'un public plus large.
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Topics**
+ [Comment déverrouiller une porte d'approbation ?](#workflows-approval-conditions)
+ [Quand utiliser le portail « Approbation »](#workflows-approval-when)
+ [Qui peut fournir une approbation ?](#workflows-approval-who)
+ [Comment informer les utilisateurs qu'une approbation est requise ?](#workflows-approval-notify-methods)
+ [Puis-je utiliser une porte « d'approbation » pour empêcher le démarrage d'un flux de travail ?](#workflows-approval-prevent)
+ [Comment fonctionnent les approbations de flux de travail avec les modes d'exécution en file d'attente, remplacé et parallèle ?](#workflows-approval-run-mode)
+ [Exemple : une porte « d'approbation »](workflows-approval-example.md)
+ [Ajouter une porte « d'approbation »](workflows-approval-add.md)
+ [Configuration des notifications d'approbation](workflows-approval-notify.md)
+ [Approuver ou rejeter l'exécution d'un flux de travail](workflows-approval-approve.md)
+ [Porte « d'approbation » YAML](approval-ref.md)
## Comment déverrouiller une porte d'approbation ?
Pour déverrouiller une porte **d'approbation**, *toutes les* conditions suivantes doivent être remplies :
+ **Condition 1** : Le nombre requis d'approbations doit être soumis. Le nombre d'approbations requis est configurable et chaque utilisateur est autorisé à soumettre une seule approbation.
+ **Condition 2** : Toutes les approbations doivent être soumises avant l'expiration de la porte. Le portail expire 14 jours après son activation. Cette période n'est pas configurable.
+ **Condition 3** : Personne ne doit rejeter l'exécution du flux de travail. Un seul rejet entraînera l'échec de l'exécution du flux de travail.
+ **Condition 4** : (Ne s'applique que si vous utilisez le mode d'exécution remplacé.) L'exécution ne doit pas être remplacée par une exécution ultérieure. Pour de plus amples informations, veuillez consulter [Comment fonctionnent les approbations de flux de travail avec les modes d'exécution en file d'attente, remplacé et parallèle ?](#workflows-approval-run-mode).
Si l'une des conditions n'est pas remplie, CodeCatalyst arrête le flux de travail et définit le statut d'exécution sur **Échec** (dans le cas des **conditions 1** à **3**) ou sur **Remplacé** (dans le cas de la **condition 4**).
## Quand utiliser le portail « Approbation »
Généralement, vous utiliserez une porte d'**approbation** dans un flux de travail qui déploie des applications et d'autres ressources sur un serveur de production ou tout environnement dans lequel les normes de qualité doivent être validées. En plaçant la porte avant le déploiement en production, vous permettez aux réviseurs de valider votre nouvelle révision logicielle avant qu'elle ne soit mise à la disposition du public.
## Qui peut fournir une approbation ?
Tout utilisateur membre de votre projet et ayant le rôle de **contributeur** ou d'**administrateur de projet** peut fournir une approbation. Les utilisateurs dotés du rôle d'**administrateur de l'espace** qui appartiennent à l'espace de votre projet peuvent également fournir une approbation.
**Note**
Les utilisateurs dotés du rôle de **réviseur** ne peuvent pas fournir d'approbations.
## Comment informer les utilisateurs qu'une approbation est requise ?
Pour informer les utilisateurs qu'une approbation est requise, vous devez :
+ CodeCatalyst Demandez-leur de leur envoyer une notification Slack. Pour de plus amples informations, veuillez consulter [Configuration des notifications d'approbation](workflows-approval-notify.md).
+ Accédez à la page de la CodeCatalyst console où se trouvent les boutons **Approuver** et **Rejeter**, puis collez l'URL de cette page dans un e-mail ou une application de messagerie adressée aux approbateurs. Pour plus d'informations sur la manière d'accéder à cette page, consultez[Approuver ou rejeter l'exécution d'un flux de travail](workflows-approval-approve.md).
## Puis-je utiliser une porte « d'approbation » pour empêcher le démarrage d'un flux de travail ?
Oui, avec des qualifications. Pour de plus amples informations, veuillez consulter [Puis-je utiliser une porte pour empêcher le démarrage d'un flux de travail ?](workflows-gates.md#workflows-gates-prevent).
## Comment fonctionnent les approbations de flux de travail avec les modes d'exécution en file d'attente, remplacé et parallèle ?
[Lorsque vous utilisez le mode d'exécution en file d'attente, remplacé ou parallèle, la porte d'**approbation** fonctionne de la même manière que les actions.](workflows-actions.md) Nous vous conseillons de lire les [À propos du mode d'exécution parallèle](workflows-configure-runs.md#workflows-configure-runs-parallel) sections [À propos du mode d'exécution en file d'attente](workflows-configure-runs.md#workflows-configure-runs-queued)[À propos du mode d'exécution remplacé](workflows-configure-runs.md#workflows-configure-runs-superseded),, pour vous familiariser avec ces modes d'exécution. Une fois que vous les aurez compris de base, revenez à cette section pour découvrir comment fonctionnent ces modes d'exécution lorsque la porte **d'approbation** est présente.
Lorsque la porte **d'approbation** est présente, les essais sont traités comme suit :
+ Si vous utilisez le [mode d'exécution en file](workflows-configure-runs.md#workflows-configure-runs-queued) d'attente, les exécutions seront placées en file d'attente après l'exécution en attente d'approbation à la porte. Lorsque cette porte est déverrouillée (c'est-à-dire que toutes les approbations ont été données), le prochain passage de la file d'attente passe à la porte et attend les approbations. Ce processus se poursuit avec le traitement des essais en file d'attente via le portail. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)illustre ce processus.
+ Si vous utilisez le mode d'[exécution remplacé, le comportement est le même que celui du mode](workflows-configure-runs.md#workflows-configure-runs-superseded) d'exécution en file d'attente, sauf qu'au lieu de laisser les essais s'accumuler dans la file d'attente à la porte, les nouveaux essais remplacent (prennent le relais) des essais précédents. Il n'y a pas de file d'attente, et toute course actuellement en attente d'approbation sera annulée et remplacée par une course plus récente. [Figure 2](#figure-2-workflow-superseded-run-mode-ma)illustre ce processus.
+ Si vous utilisez le [mode d'exécution parallèle](workflows-configure-runs.md#workflows-configure-runs-parallel), les exécutions démarrent en parallèle et aucune file d'attente ne se forme. Chaque course est traitée immédiatement par la porte puisqu'il n'y a aucune course devant elle. [Figure 3](#figure-3-workflow-parallel-run-mode-ma)illustre ce processus.
**Figure 1** **: « Mode d'exécution en file d'attente » et porte d'approbation**
![\[Comment fonctionne une porte « d'approbation » avec le « mode d'exécution en file d'attente »\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**Figure 2** **: « Mode d'exécution remplacé » et porte d'approbation**
![\[Comment fonctionne une porte « d'approbation » avec le « mode d'exécution remplacé »\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**Figure 3** **: « Mode d'exécution parallèle » et porte d'approbation**
![\[Comment fonctionne une porte « d'approbation » avec le « mode de fonctionnement parallèle »\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# Exemple : une porte « d'approbation »
L'exemple suivant montre comment ajouter une porte **d'approbation** appelée `Approval_01` entre deux actions appelées`Staging`, et`Production`. L'`Staging`action s'exécute en premier, la `Approval_01` porte en second et l'`Production`action en dernier. L'`Production`action ne s'exécute que si le `Approval_01` portail est déverrouillé. La `DependsOn` propriété garantit que les `Production` phases `Staging``Approval_01`, et s'exécutent dans un ordre séquentiel.
Pour plus d'informations sur la porte **d'approbation**, consultez[Exiger des approbations lors des exécutions de flux](workflows-approval.md).
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# Ajouter une porte « d'approbation »
Pour configurer votre flux de travail afin d'exiger une approbation, vous devez ajouter la porte **d'approbation** au flux de travail. Suivez les instructions ci-dessous pour ajouter une porte d'**approbation** à votre flux de travail.
Pour plus d'informations sur cette porte, consultez[Exiger des approbations lors des exécutions de flux](workflows-approval.md).
------
#### [ Visual ]
**Pour ajouter une porte « d'approbation » à un flux de travail (éditeur visuel)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. En haut à gauche, choisissez **Gates**.
1. Dans le catalogue **Gates**, dans **Approbation**, choisissez le signe plus (**\$1**).
1. Choisissez **Entrées**, puis dans le champ **Dépend** de, procédez comme suit.
Spécifiez une action, un groupe d'actions ou une porte qui doit s'exécuter correctement pour que cette porte s'exécute. Par défaut, lorsque vous ajoutez une porte à un flux de travail, la porte est définie pour dépendre de la dernière action de votre flux de travail. Si vous supprimez cette propriété, la porte ne dépendra de rien et s'exécutera en premier, avant les autres actions.
**Note**
Une porte doit être configurée pour s'exécuter avant ou après une action, un groupe d'actions ou une porte. Il ne peut pas être configuré pour fonctionner en parallèle avec d'autres actions, groupes d'actions et portes.
Pour plus d'informations sur la fonctionnalité **Depends on**, consultez[Séquençage des portes et des actions](workflows-gates-depends-on.md).
1. Cliquez sur l’onglet **Configuration**.
1. Dans le champ **Nom de la porte**, procédez comme suit.
Spécifiez le nom que vous souhaitez donner à la porte. Tous les noms de portes doivent être uniques dans le flux de travail. Les noms de portes sont limités aux caractères alphanumériques (a-z, A-Z, 0-9), aux traits d'union (-) et aux traits de soulignement (\$1). Les espaces ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les caractères spéciaux et les espaces dans les noms de portes.
1. (Facultatif) Dans le champ **Nombre d'approbations**, procédez comme suit.
Spécifiez le nombre minimum d'approbations requises pour déverrouiller la porte **d'approbation**. Le minimum est`1`. Le maximum est de`2`. En cas d'omission, la valeur par défaut est`1`.
**Note**
Si vous souhaitez omettre cette `ApprovalsRequired` propriété, supprimez la `Configuration` section de la porte du fichier de définition du flux de travail.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter une porte « d'approbation » à un flux de travail (éditeur YAML)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Ajoutez une `Approval` section et les propriétés sous-jacentes en utilisant l'exemple suivant comme guide. Pour en savoir plus, consultez [Porte « d'approbation » YAML](approval-ref.md) dans la rubrique [Définition du flux de travail YAML](workflow-reference.md).
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
Pour obtenir un autre exemple, consultez [Exemple : une porte « d'approbation »](workflows-approval-example.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Configuration des notifications d'approbation
Vous pouvez CodeCatalyst envoyer une notification à une chaîne Slack pour informer les utilisateurs qu'un flux de travail nécessite une approbation. Les utilisateurs voient la notification et cliquent sur le lien qu'elle contient. Le lien les dirige vers une page d' CodeCatalyst approbation où ils peuvent approuver ou rejeter le flux de travail.
Vous pouvez également configurer des notifications pour informer les utilisateurs qu'un flux de travail a été approuvé, rejeté ou que la demande d'approbation a expiré.
Suivez les instructions ci-dessous pour configurer les notifications Slack.
**Avant de commencer**
Assurez-vous d'avoir ajouté une porte d'**approbation** à votre flux de travail. Pour de plus amples informations, veuillez consulter [Ajouter une porte « d'approbation »](workflows-approval-add.md).
**Pour envoyer des notifications d'approbation de flux de travail à une chaîne Slack**
1. Configurez CodeCatalyst avec Slack. Pour de plus amples informations, veuillez consulter [Commencer à utiliser les notifications Slack](getting-started-notifications.md).
1. Dans le CodeCatalyst projet contenant le flux de travail qui nécessite une approbation, activez les notifications, si elles ne le sont pas déjà. Pour activer les notifications :
1. Accédez à votre projet et dans le volet de navigation, sélectionnez **Paramètres du projet**.
1. En haut de la page, choisissez **Notifications**.
1. Dans **Événements de notification**, choisissez **Modifier les notifications**.
1. Activez l'option « **En attente d'approbation du flux** de travail » et choisissez une chaîne Slack sur laquelle CodeCatalyst vous enverrez la notification.
1. (Facultatif) Activez des notifications supplémentaires pour avertir les utilisateurs des approbations approuvées, rejetées ou expirées. Vous pouvez activer l'exécution du **flux de travail approuvée, l'exécution** du **flux de travail rejetée**, **l'approbation du flux de travail remplacée** et l'**approbation du flux de travail expirée.** À côté de chaque notification, choisissez le canal Slack sur lequel CodeCatalyst vous souhaitez envoyer la notification.
1. Choisissez **Save** (Enregistrer).
# Approuver ou rejeter l'exécution d'un flux de travail
Les exécutions de flux de travail qui incluent la porte d'**approbation** devront être approuvées ou rejetées. Les utilisateurs peuvent fournir leur approbation ou leur rejet à partir de :
+ la CodeCatalyst console
+ un lien fourni par un membre de l'équipe
+ une notification automatique sur Slack
Une fois qu'un utilisateur a donné son approbation ou son rejet, cette décision ne peut pas être annulée.
**Note**
Seuls certains utilisateurs peuvent approuver ou rejeter l'exécution d'un flux de travail. Pour de plus amples informations, veuillez consulter [Qui peut fournir une approbation ?](workflows-approval.md#workflows-approval-who).
**Avant de commencer**
Assurez-vous d'avoir ajouté une porte d'**approbation** à votre flux de travail. Pour de plus amples informations, veuillez consulter [Ajouter une porte « d'approbation »](workflows-approval-add.md).
**Pour approuver ou rejeter un flux de travail exécuté à partir de la CodeCatalyst console**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Dans le diagramme du flux de travail, sélectionnez la case représentant la porte **d'approbation**.
Un panneau latéral apparaît.
**Note**
À ce stade, vous pouvez envoyer l'URL de cette page à d'autres approbateurs si vous le souhaitez.
1. Sous **Révision de la décision**, choisissez **Approuver** ou **Rejeter**.
1. (Facultatif) Dans **Commentaire - facultatif**, entrez un commentaire indiquant pourquoi vous avez approuvé ou rejeté l'exécution du flux de travail.
1. Sélectionnez **Soumettre**.
**Pour approuver ou rejeter l'exécution d'un flux de travail à partir d'un lien fourni par un membre de l'équipe**
1. Choisissez le lien qui vous a été envoyé par le membre de votre équipe. (Vous pouvez demander au membre de votre équipe de lire la procédure précédente pour obtenir le lien.)
1. Connectez-vous à CodeCatalyst, si vous y êtes invité.
Vous êtes redirigé vers la page d'approbation de l'exécution du flux de travail.
1. Sous **Révision de la décision**, choisissez **Approuver** ou **Rejeter**.
1. (Facultatif) Dans **Commentaire - facultatif**, entrez un commentaire indiquant pourquoi vous avez approuvé ou rejeté l'exécution du flux de travail.
1. Sélectionnez **Soumettre**.
**Pour approuver ou rejeter l'exécution d'un flux de travail à partir d'une notification automatique de Slack**
1. Assurez-vous que les notifications Slack sont configurées. Consultez [Configuration des notifications d'approbation](workflows-approval-notify.md).
1. Dans Slack, dans le canal auquel la notification d'approbation a été envoyée, choisissez le lien dans la notification d'approbation.
1. Connectez-vous à CodeCatalyst, si vous y êtes invité.
Vous êtes redirigé vers la page d'exécution du flux de travail.
1. Dans le diagramme du flux de travail, choisissez la porte d'approbation.
1. Sous **Révision de la décision**, choisissez **Approuver** ou **Rejeter**.
1. (Facultatif) Dans **Commentaire - facultatif**, entrez un commentaire indiquant pourquoi vous avez approuvé ou rejeté l'exécution du flux de travail.
1. Sélectionnez **Soumettre**.
# Porte « d'approbation » YAML
Voici la définition YAML de la porte d'**approbation**. Pour savoir comment utiliser cette porte, voir[Exiger des approbations lors des exécutions de flux](workflows-approval.md).
Cette définition d'action existe sous forme de section au sein d'un fichier de définition de flux de travail plus large. Pour plus d’informations sur ce fichier, consultez [Définition du flux de travail YAML](workflow-reference.md).
**Note**
La plupart des propriétés YAML suivantes ont des éléments d'interface utilisateur correspondants dans l'éditeur visuel. Pour rechercher un élément de l'interface utilisateur, utilisez **Ctrl\$1F**. L'élément sera répertorié avec sa propriété YAML associée.
```
# The workflow definition starts here.
# See Propriétés de haut niveau for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(Obligatoire)
Spécifiez le nom que vous souhaitez donner à la porte. Tous les noms de portes doivent être uniques dans le flux de travail. Les noms de portes sont limités aux caractères alphanumériques (a-z, A-Z, 0-9), aux traits d'union (-) et aux traits de soulignement (\$1). Les espaces ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les caractères spéciaux et les espaces dans les noms de portes.
Par défaut : `Approval_nn`.
Interface utilisateur correspondante : onglet Configuration/nom de **la porte**
## Identifier
(*Approval*/**Identifier**)
(Obligatoire)
Identifie le portail. La porte **d'approbation** prend en charge la version`1.0.0`. Ne modifiez pas cette propriété, sauf si vous souhaitez raccourcir la version. Pour de plus amples informations, veuillez consulter [Spécification de la version de l'action à utiliser](workflows-action-versions.md).
Par défaut : `aws/approval@v1`.
**Interface utilisateur correspondante : diagramme de flux de travail/ Approval \$1nn/ aws/approval @v1 label**
## DependsOn
(*Approval*/**DependsOn**)
(Facultatif)
Spécifiez une action, un groupe d'actions ou une porte qui doit s'exécuter correctement pour que cette porte s'exécute. Par défaut, lorsque vous ajoutez une porte à un flux de travail, la porte est définie pour dépendre de la dernière action de votre flux de travail. Si vous supprimez cette propriété, la porte ne dépendra de rien et s'exécutera en premier, avant les autres actions.
**Note**
Une porte doit être configurée pour s'exécuter avant ou après une action, un groupe d'actions ou une porte. Il ne peut pas être configuré pour fonctionner en parallèle avec d'autres actions, groupes d'actions et portes.
Pour plus d'informations sur la fonctionnalité **Depends on**, consultez[Séquençage des portes et des actions](workflows-gates-depends-on.md).
Interface utilisateur correspondante : onglet **Entrées/dépend de**
## Configuration
(*Approval*/**Configuration**)
(Facultatif)
Section dans laquelle vous pouvez définir les propriétés de configuration de la porte.
Interface utilisateur correspondante : onglet **Configuration**
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(Facultatif)
Spécifiez le nombre minimum d'approbations requises pour déverrouiller la porte **d'approbation**. Le minimum est`1`. Le maximum est de`2`. En cas d'omission, la valeur par défaut est`1`.
**Note**
Si vous souhaitez omettre cette `ApprovalsRequired` propriété, supprimez la `Configuration` section de la porte du fichier de définition du flux de travail.
Interface utilisateur correspondante : onglet **Configuration/Nombre d'approbations**
# Configuration du comportement de mise en file d'attente des exécutions
Par défaut CodeCatalyst, sur Amazon, lorsque plusieurs flux de travail sont exécutés en même temps, ils sont placés en CodeCatalyst file d'attente et traités un par un, dans l'ordre dans lequel ils ont été démarrés. Vous pouvez modifier ce comportement par défaut en spécifiant un *mode d'exécution*. Il existe quelques modes d'exécution :
+ (Par défaut) Mode d'exécution en file d'attente : CodeCatalyst les processus s'exécutent un par un
+ Mode d'exécution remplacé : CodeCatalyst les processus s'exécutent un par un, les nouvelles exécutions remplaçant les anciennes
+ Mode d'exécution parallèle : CodeCatalyst les processus s'exécutent en parallèle
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Topics**
+ [À propos du mode d'exécution en file d'attente](#workflows-configure-runs-queued)
+ [À propos du mode d'exécution remplacé](#workflows-configure-runs-superseded)
+ [À propos du mode d'exécution parallèle](#workflows-configure-runs-parallel)
+ [Configuration du mode d'exécution](#workflows-configure-runs-configure)
## À propos du mode d'exécution en file d'attente
En *mode exécution en file* d'attente, les exécutions se produisent en série, les séries en attente formant une file d'attente.
Les files d'attente se forment aux points d'entrée des actions et des groupes d'actions. Vous pouvez donc avoir *plusieurs files d'attente dans le même flux de travail* (voir[Figure 1](#figure-1-workflow-queued-run-mode)). Lorsqu'une exécution en file d'attente entre dans une action, celle-ci est verrouillée et aucune autre exécution ne peut y entrer. Lorsque l'exécution se termine et quitte l'action, l'action est déverrouillée et prête pour la prochaine exécution.
[Figure 1](#figure-1-workflow-queued-run-mode)illustre un flux de travail configuré en mode d'exécution en file d'attente. Il contient les éléments suivants :
+ Sept cycles se frayent un chemin dans le flux de travail.
+ Deux files d'attente : une en dehors de l'entrée de la source d'entrée (**Repo:Main**) et une en dehors de l'entrée de l'action. **BuildTestActionGroup**
+ Deux blocs verrouillés : la source d'entrée (**Repo:main**) et le. **BuildTestActionGroup**
Voici comment les choses se dérouleront au fur et à mesure que le flux de travail terminera le traitement :
+ **Lorsque **Run-4d444** aura fini de cloner le référentiel source, il quittera la source d'entrée et rejoindra la file d'attente située derrière Run-3c333.** Ensuite, **RUN-5e555** entrera dans la source d'entrée.
+ Lorsque **Run-1a111** aura fini de créer et de tester, il quittera l'**BuildTestActionGroup**action et entrera dans l'action. **DeployAction** Ensuite, **Run-2b222** entrera dans l'action. **BuildTestActionGroup**
**Figure 1** : Un flux de travail configuré en « mode exécution en file d'attente »
![\[Un flux de travail configuré en « mode d'exécution en file d'attente »\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Utilisez le mode d'exécution en file d'attente si :
+ **Vous souhaitez conserver une one-to-one relation entre les fonctionnalités et les exécutions. Ces fonctionnalités peuvent être regroupées lorsque vous utilisez le mode remplacé.** Par exemple, lorsque vous fusionnez la fonctionnalité 1 dans le commit 1, l'exécution 1 démarre, et lorsque vous fusionnez l'entité 2 dans le commit 2, l'exécution 2 démarre, etc. Si vous deviez utiliser le mode remplacé au lieu du mode en file d'attente, vos fonctionnalités (et vos validations) seront regroupées lors de l'exécution qui remplacera les autres.
+ **Vous souhaitez éviter les conditions de course et les problèmes inattendus qui peuvent survenir lors de l'utilisation du mode parallel**. Par exemple, si deux développeurs de logiciels, Wang et Saanvi, lancent des exécutions de flux de travail à peu près au même moment pour les déployer sur un cluster Amazon ECS, l'exécution de Wang peut lancer des tests d'intégration sur le cluster tandis que celle de Saanvi déploie un nouveau code d'application sur le cluster, ce qui entraîne l'échec des tests de Wang ou le test du mauvais code. Autre exemple, vous pouvez avoir une cible dépourvue de mécanisme de verrouillage, auquel cas les deux essais peuvent remplacer les modifications de l'autre de manière inattendue.
+ **Vous souhaitez limiter la charge** sur les ressources de calcul CodeCatalyst utilisées pour traiter vos exécutions. Par exemple, si votre flux de travail comporte trois actions, vous pouvez exécuter au maximum trois exécutions en même temps. L'imposition d'une limite au nombre d'exécutions pouvant être effectuées simultanément rend le débit d'exécution plus prévisible.
+ **Vous souhaitez limiter le nombre de demandes adressées à des services tiers** par le flux de travail. Par exemple, votre flux de travail peut comporter une action de génération qui inclut des instructions pour extraire une image de Docker Hub. [Docker Hub limite le nombre de pull requests](https://www.docker.com/increase-rate-limits) que vous pouvez effectuer à un certain nombre par heure et par compte, et vous serez bloqué si vous dépassez cette limite. L'utilisation du mode d'exécution en file d'attente pour ralentir votre débit d'exécution aura pour effet de générer moins de demandes à Docker Hub par heure, limitant ainsi les risques de verrouillages et d'échecs de compilation et d'exécution qui en résultent.
**Taille maximale de la file d'attente** : 50
Remarques sur la **taille maximale de la file d'attente** :
+ La taille maximale de la file d'attente fait référence au nombre maximum d'exécutions autorisées dans *toutes les files d'attente* du flux de travail.
+ Si une file d'attente dépasse 50 essais, la 51e et les suivantes sont supprimées. CodeCatalyst
**Comportement de défaillance** :
Si une exécution ne répond plus alors qu'elle est traitée par une action, les exécutions qui la suivent sont maintenues dans la file d'attente jusqu'à ce que l'action expire. Les actions expirent au bout d'une heure.
Si une exécution échoue dans le cadre d'une action, la première exécution en file d'attente qui la suit est autorisée à se poursuivre.
## À propos du mode d'exécution remplacé
Le mode d'*exécution remplacé est identique au mode* d'*exécution en file d'attente sauf* que :
+ Si une exécution en file d'attente rattrape une autre course de la file d'attente, la dernière remplace (remplace) la précédente, et la précédente est annulée et marquée comme « remplacée ».
+ En raison du comportement décrit dans le premier point, une file d'attente ne peut inclure qu'une seule exécution lorsque le mode d'exécution remplacé est utilisé.
En utilisant le flux de travail [Figure 1](#figure-1-workflow-queued-run-mode) comme guide, l'application d'un mode d'exécution remplacé à ce flux de travail entraînerait les résultats suivants :
+ **Run-7g777** **remplacerait les deux autres exécutions de sa file d'attente et serait la seule exécution restante dans la file \$11.** **Run-6f666** et **Run-5e555** seraient annulés.
+ **Run-3c333** **remplacerait **Run-2b222 et serait le seul run restant** dans la file d'attente \$12.** **Run-2b222 serait annulé**.
Utilisez le mode d'exécution remplacé si vous souhaitez :
+ meilleur débit qu'en mode file d'attente
+ encore moins de demandes adressées à des services tiers qu'en mode file d'attente ; cela est avantageux si le service tiers impose des limites de débit, comme Docker Hub
## À propos du mode d'exécution parallèle
En *mode d'exécution parallèle*, les exécutions sont indépendantes les unes des autres et n'attendez pas la fin des autres exécutions pour démarrer. Il n'y a pas de files d'attente et le débit d'exécution n'est limité que par la rapidité avec laquelle les actions du flux de travail sont effectuées.
Utilisez le mode d'exécution parallèle dans les environnements de développement où chaque utilisateur possède sa propre branche de fonctionnalités et effectue des déploiements sur des cibles qui ne sont pas partagées par d'autres utilisateurs.
**Important**
Si vous avez une cible partagée vers laquelle plusieurs utilisateurs peuvent effectuer un déploiement, telle qu'une fonction Lambda dans un environnement de production, n'utilisez pas le mode parallel, car cela pourrait entraîner des conditions de course. Une *situation de course* se produit lorsque des workflows parallèles tentent de modifier une ressource partagée en même temps, ce qui entraîne des résultats imprévisibles.
**Nombre maximum de courses en parallèle** : 1000 par CodeCatalyst espace
## Configuration du mode d'exécution
Vous pouvez définir le mode d'exécution sur queued, superseded ou parallel. La valeur par défaut est mise en file d'attente.
Lorsque vous passez du mode d'exécution en file d'attente ou remplacé au mode parallèle CodeCatalyst , vous annulez les exécutions mises en file d'attente et autorisez les exécutions en cours de traitement par une action à se terminer avant de les annuler.
Lorsque vous passez du mode d'exécution de parallel à un mode en file d'attente ou à un mode remplacé, CodeCatalyst toutes les exécutions parallèles en cours d'exécution sont terminées. Toutes les exécutions que vous démarrez après avoir changé le mode d'exécution en mode file d'attente ou remplacé utilisent le nouveau mode.
------
#### [ Visual ]
**Pour modifier le mode d'exécution à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. En haut à droite, sélectionnez **Propriétés du flux de travail**.
1. Développez le mode **Avancé**, puis sous **Mode d'exécution**, choisissez l'une des options suivantes :
1. **En file d'attente — voir** [À propos du mode d'exécution en file d'attente](#workflows-configure-runs-queued)
1. **Remplacé — voir** [À propos du mode d'exécution remplacé](#workflows-configure-runs-superseded)
1. **Parallèle** — voir [À propos du mode d'exécution parallèle](#workflows-configure-runs-parallel)
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour modifier le mode d'exécution à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Ajoutez la `RunMode` propriété, comme suit :
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Pour plus d'informations, consultez la description de la `RunMode` propriété dans la [Propriétés de haut niveau](workflow-reference.md#workflow.top.level) section du[Définition du flux de travail YAML](workflow-reference.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Mise en cache des fichiers entre les exécutions du flux de travail
Lorsque la mise en cache de fichiers est activée, les actions de génération et de test enregistrent les fichiers sur disque dans un cache et les restaurent à partir de ce cache lors des exécutions de flux de travail suivantes. La mise en cache réduit la latence causée par la création ou le téléchargement de dépendances qui n'ont pas changé entre les exécutions. CodeCatalyst prend également en charge les caches de secours, qui peuvent être utilisés pour restaurer des caches partiels contenant certaines des dépendances nécessaires. Cela permet de réduire l'impact sur la latence d'un échec du cache.
**Note**
La mise en cache des fichiers n'est disponible qu'avec les actions de CodeCatalyst [compilation](build-workflow-actions.md) et de [test](test-workflow-actions.md) Amazon, et uniquement lorsqu'elles sont configurées pour utiliser le [type de **EC2**calcul](workflows-working-compute.md#compute.types).
**Topics**
+ [À propos de la mise en cache de fichiers](#workflows-caching.files)
+ [Création d'un cache](#workflows-caching.fallback)
+ [Contraintes de mise en cache de fichiers](#workflows-caching.constraints)
## À propos de la mise en cache de fichiers
La mise en cache des fichiers vous permet d'organiser vos données dans plusieurs caches, chacun référencé sous la `FileCaching` propriété. Chaque cache enregistre un répertoire spécifié par un chemin donné. Le répertoire spécifié sera restauré lors des futures exécutions du flux de travail. Voici un exemple d'extrait de code YAML pour la mise en cache avec plusieurs caches nommés et. `cacheKey1` `cacheKey2`
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**Note**
CodeCatalyst utilise une mise en cache multicouche, composée d'un cache local et d'un cache distant. Lorsque des flottes provisionnées ou des machines à la demande rencontrent une erreur de cache dans un cache local, les dépendances sont restaurées à partir d'un cache distant. Par conséquent, le téléchargement d'un cache distant peut entraîner une latence lors de l'exécution de certaines actions.
CodeCatalyst applique des restrictions d'accès au cache pour garantir qu'une action dans un flux de travail ne peut pas modifier les caches d'un autre flux de travail. Cela protège chaque flux de travail contre d'autres qui pourraient transmettre des données incorrectes ayant un impact sur les builds ou les déploiements. Les restrictions sont appliquées grâce à des étendues de cache qui isolent les caches pour chaque flux de travail et chaque association de branches. Par exemple, `workflow-A` la branche `feature-A` possède un cache de fichiers différent de celui `workflow-A` de la branche `feature-B` sœur.
Des erreurs de cache se produisent lorsqu'un flux de travail recherche un cache de fichiers spécifié et ne parvient pas à le trouver. Cela peut se produire pour plusieurs raisons, par exemple lorsqu'une nouvelle branche est créée ou lorsqu'un nouveau cache est référencé alors qu'il n'a pas encore été créé. Cela peut également se produire lorsqu'un cache expire, ce qui se produit par défaut 14 jours après sa dernière utilisation. Pour atténuer les erreurs de cache et augmenter le taux d'accès au cache, CodeCatalyst prend en charge les caches de secours. Les caches de secours sont des caches alternatifs et permettent de restaurer des caches partiels, qui peuvent être une ancienne version d'un cache. Un cache est restauré en recherchant d'abord une correspondance sous le nom `FileCaching` de propriété et, s'il n'est pas trouvé, il est évalué. `RestoreKeys` En cas d'erreur de cache à la fois pour le nom de la propriété et pour l'ensemble des propriétés`RestoreKeys`, le flux de travail continuera de s'exécuter, car la mise en cache est une solution optimale et n'est pas garantie.
## Création d'un cache
Vous pouvez utiliser les instructions suivantes pour ajouter un cache à votre flux de travail.
------
#### [ Visual ]
**Pour ajouter un cache à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action à laquelle vous souhaitez ajouter votre cache.
1. Choisissez **Configuration**.
1. Sous **Mise en cache de fichiers - facultatif**, choisissez **Ajouter un cache** et entrez les informations dans les champs, comme suit :
**Clé**
Spécifiez le nom de votre propriété de cache principale. Les noms des propriétés du cache doivent être uniques dans votre flux de travail. Chaque action peut comporter jusqu'à cinq entrées`FileCaching`.
**Chemin**
Spécifiez le chemin associé à votre cache.
**Clés de restauration : facultatif**
Spécifiez la clé de restauration à utiliser comme solution de secours lorsque la propriété de cache principale est introuvable. Les noms des clés de restauration doivent être uniques dans votre flux de travail. Chaque cache peut contenir jusqu'à cinq entrées`RestoreKeys`.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter un cache à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans une action de flux de travail, ajoutez un code similaire au suivant :
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
## Contraintes de mise en cache de fichiers
Les contraintes relatives au nom de la propriété sont les `RestoreKeys` suivantes :
+ Les noms doivent être uniques dans un flux de travail.
+ Les noms sont limités aux caractères alphanumériques (A-Z, a-z, 0-9), aux tirets (-) et aux traits de soulignement (\$1).
+ Les noms peuvent comporter jusqu'à 180 caractères.
+ Chaque action peut contenir jusqu'à cinq caches. `FileCaching`
+ Chaque cache peut contenir jusqu'à cinq entrées`RestoreKeys`.
Les contraintes relatives aux chemins sont les suivantes :
+ Les astérisques (\$1) ne sont pas autorisés.
+ Les chemins peuvent comporter jusqu'à 255 caractères.
# Afficher le statut et les détails de l'exécution du flux de travail
Dans Amazon CodeCatalyst, vous pouvez consulter le statut et les détails d'une seule exécution de flux de travail ou de plusieurs exécutions simultanées.
Pour une liste des états d'exécution possibles, voir[États d'exécution du flux de travail](workflows-view-run-status.md).
**Note**
Vous pouvez également consulter l'état du flux de travail, qui est différent de l'état d'*exécution* du flux de travail. Pour de plus amples informations, veuillez consulter [Afficher le statut d'un flux de travail](workflows-view-status.md).
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Topics**
+ [Afficher le statut et les détails d'une seule exécution](#workflows-view-run-single)
+ [Afficher le statut et les détails de toutes les exécutions de votre projet](#workflows-view-run-all)
+ [Afficher le statut et les détails de toutes les exécutions d'un flux de travail spécifique](#workflows-view-run-wf)
+ [Affichage des exécutions d'un flux de travail dans le diagramme du flux de travail](#workflows-view-run-wf-diagram)
## Afficher le statut et les détails d'une seule exécution
Vous souhaiterez peut-être consulter le statut et les détails d'une seule exécution de flux de travail pour vérifier si elle a réussi, à quelle heure elle s'est terminée ou pour savoir qui ou quoi l'a lancée.
**Pour afficher le statut et les détails d'une seule exécution**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Sous le nom du flux de travail, choisissez **Runs**.
1. Dans **Historique** des exécutions, dans la colonne **Run ID**, sélectionnez une exécution. Par exemple, `Run-95a4d`.
1. Sous le nom de l'exécution, effectuez l'une des opérations suivantes :
+ **Visuel** illustrant un diagramme de flux de travail montrant les actions de votre flux de travail exécutées et leur statut (voir[États d'exécution du flux de travail](workflows-view-run-status.md)). Cette vue montre également le référentiel source et la branche utilisés lors de l'exécution.
Dans le diagramme du flux de travail, choisissez une action pour voir les détails tels que les journaux, les rapports et les résultats générés par l'action pendant l'exécution. Les informations affichées dépendent du type d'action sélectionné. Pour plus d'informations sur l'affichage des journaux de création ou de déploiement, consultez [Afficher les résultats d'une action de construction](build-view-results.md) ou[Afficher les journaux de déploiement](deploy-deployment-logs.md).
+ **YAML** pour voir le fichier de définition du flux de travail utilisé pour l'exécution.
+ **Artefacts** permettant de voir les artefacts produits par le flux de travail exécuté. Pour plus d'informations sur les artefacts, consultez [Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
+ **Rapports** permettant de consulter les rapports de test et les autres types de rapports produits par le flux de travail exécuté. Pour plus d'informations sur les rapports, consultez[Types de rapports sur la qualité](test-workflow-actions.md#test-reporting).
+ **Variables** permettant de voir les variables de sortie produites par le flux de travail exécuté. Pour plus d'informations sur les variables, consultez[Utilisation de variables dans les flux de travail](workflows-working-with-variables.md).
**Note**
Si le flux de travail parent de l'exécution a été supprimé, un message indiquant ce fait apparaît en haut de la page des détails de l'exécution.
## Afficher le statut et les détails de toutes les exécutions de votre projet
Vous souhaiterez peut-être consulter le statut et les détails de toutes les exécutions de flux de travail au sein de votre projet, comprendre le niveau d'activité du flux de travail dans votre projet et en savoir plus sur l'état général de vos flux de travail.
**Pour consulter le statut et les détails de toutes les exécutions de votre projet**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Sous **Workflows**, choisissez **Runs**.
Toutes les exécutions, pour tous les flux de travail, dans toutes les branches, dans tous les référentiels de votre projet, sont affichées.
La page comprend les colonnes suivantes :
+ **ID d'exécution** : identifiant unique de l'exécution. Cliquez sur le lien Run ID pour afficher des informations détaillées sur l'exécution.
+ **État — État** du traitement du flux de travail exécuté. Pour plus d'informations sur les états d'exécution, consultez[États d'exécution du flux de travail](workflows-view-run-status.md).
+ **Déclencheur** : personne, commit, pull request (PR) ou calendrier qui a lancé l'exécution du flux de travail. Pour de plus amples informations, veuillez consulter [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
+ **Flux de travail** : nom du flux de travail pour lequel une exécution a été lancée, ainsi que du référentiel source et de la branche où réside le fichier de définition du flux de travail. Il se peut que vous deviez augmenter la largeur de la colonne pour voir ces informations.
**Note**
Si cette colonne est définie sur **Non disponible**, c'est généralement parce que le flux de travail associé a été supprimé ou déplacé.
+ **Heure de début : heure** à laquelle l'exécution du flux de travail a commencé.
+ **Durée : durée** de traitement du flux de travail. Des durées très longues ou très courtes peuvent indiquer des problèmes.
+ **Heure de fin : heure** à laquelle l'exécution du flux de travail s'est terminée.
## Afficher le statut et les détails de toutes les exécutions d'un flux de travail spécifique
Vous souhaiterez peut-être consulter le statut et les détails de toutes les exécutions associées à un flux de travail spécifique pour voir si certaines d'entre elles créent des goulots d'étranglement dans le flux de travail, ou pour voir quelles exécutions sont en cours ou terminées.
**Pour afficher le statut et les détails de toutes les exécutions d'un flux de travail spécifique**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Sous le nom du flux de travail, choisissez **Runs**.
Les exécutions associées au flux de travail choisi apparaissent.
La page est divisée en deux sections :
+ **Exécutions actives** : affiche les séries en cours. Ces courses se dérouleront dans l'un des états suivants : **En cours**.
+ **Historique** des exécutions : affiche les exécutions terminées (c'est-à-dire non en cours).
Pour plus d'informations sur les états d'exécution, consultez[États d'exécution du flux de travail](workflows-view-run-status.md).
## Affichage des exécutions d'un flux de travail dans le diagramme du flux de travail
Vous pouvez consulter le statut de toutes les exécutions d'un flux de travail au fur et à mesure qu'elles progressent ensemble dans le flux de travail. Les exécutions sont affichées dans le diagramme du flux de travail (et non dans une vue de liste). Cela vous donne une représentation visuelle des exécutions traitées par quelles actions, et des exécutions en attente dans une file d'attente.
**Pour afficher le statut de plusieurs exécutions au fur et à mesure qu'elles progressent ensemble dans un flux de travail**
**Note**
Cette procédure s'applique uniquement si votre flux de travail utilise le mode d'exécution en file d'attente ou remplacé. Pour de plus amples informations, veuillez consulter [Configuration du comportement de mise en file d'attente des exécutions](workflows-configure-runs.md).
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
**Note**
Assurez-vous de consulter une page de flux de travail et non une page d'exécution.
1. Choisissez l'onglet **État le plus récent** en haut à gauche.
Un diagramme de flux de travail apparaît.
1. Passez en revue le diagramme du flux de travail. Le diagramme montre toutes les exécutions en cours dans le flux de travail, ainsi que les dernières exécutions terminées. Plus précisément :
+ Les exécutions qui apparaissent en haut, avant **Sources**, sont mises en file d'attente et attendent de démarrer.
+ Les exécutions qui apparaissent entre les actions sont mises en file d'attente et attendent d'être traitées par l'action suivante.
+ Les exécutions qui apparaissent dans une action sont 1. en cours de traitement par l'action, 2. ont fini d'être traitées par l'action, ou 3. n'ont pas été traitées par l'action (généralement parce qu'une action précédente a échoué).