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. # Définition du flux de travail YAML Vous trouverez ci-dessous la documentation de référence pour le fichier de définition du flux de travail. Un *fichier de définition de flux* de travail est un fichier YAML qui décrit votre flux de travail. Par défaut, le fichier est stocké dans un `~/.codecatalyst/workflows/` dossier à la racine de votre [référentiel source](source-repositories.md). Le fichier peut avoir une extension .yml ou .yaml, et l'extension doit être en minuscules. Pour créer et modifier le fichier de définition du flux de travail, vous pouvez utiliser un éditeur tel que vim, ou vous pouvez utiliser l'éditeur visuel ou l'éditeur YAML de la CodeCatalyst console. Pour de plus amples informations, veuillez consulter [Utilisation des éditeurs visuels et YAML de la CodeCatalyst console](workflow.md#workflow.editors). **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. **Topics** + [Exemple de fichier de définition de flux de travail](#workflow.anatomy) + [Consignes et conventions de syntaxe](#workflow.terms.syntax.conv) + [Propriétés de haut niveau](#workflow.top.level) ## Exemple de fichier de définition de flux de travail Voici un exemple de fichier de définition de flux de travail simple. Il inclut quelques propriétés de haut niveau, une `Triggers` section et une `Actions` section comportant deux actions : `Build` et`Test`. Pour de plus amples informations, veuillez consulter [À propos du fichier de définition du flux de travail](workflow.md#workflow.example). ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . Test: Identifier: aws/managed-test@v1 DependsOn: - Build Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test ``` ## Consignes et conventions de syntaxe Cette section décrit les règles de syntaxe du fichier de définition du flux de travail, ainsi que les conventions de dénomination utilisées dans cette documentation de référence. ### Consignes relatives à la syntaxe YAML Le fichier de définition du flux de travail est écrit en YAML et suit la [spécification YAML 1.1](https://yaml.org/spec/), de sorte que tout ce qui est autorisé dans cette spécification est également autorisé dans le flux de travail YAML. Si vous débutez avec le langage YAML, voici quelques instructions rapides pour vous assurer que vous fournissez un code YAML valide. + **distinction majuscules/majuscules** : le fichier de définition du flux de travail distingue les majuscules et minuscules. Assurez-vous donc d'utiliser le boîtier présenté dans cette documentation. + **Caractères spéciaux** : nous vous recommandons d'utiliser des guillemets ou des guillemets doubles autour des valeurs de propriété qui incluent l'un des caractères spéciaux suivants : `{` `}` `[``]`,,`*`,`#`,`?`,,`|`,`-`,,, <, >`=`,`!`,`%`,, `@``:`, ``` et `,` Si vous n'incluez pas les guillemets, les caractères spéciaux répertoriés précédemment risquent d'être interprétés de manière inattendue. + **Noms des propriétés** : les *noms des* propriétés (par opposition aux *valeurs* des propriétés) 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 ou de guillemets doubles pour activer les caractères spéciaux et les espaces dans les noms de propriétés. Non autorisé : `'My#Build@action'` `My#Build@action` `My Build Action` Autorisé : `My-Build-Action_1` + **Codes d'échappement** : si la valeur de votre propriété inclut des codes d'échappement (par exemple, `\n` ou`\t`), suivez les instructions suivantes : + Utilisez des guillemets simples pour renvoyer le code d'échappement sous forme de chaîne. Par exemple`'my string \n my string'`, renvoie la chaîne`my string \n my string`. + Utilisez des guillemets pour analyser le code d'échappement. Par exemple`"my string \n my new line"`, renvoie : ``` my string my new line ``` + **Commentaires** : Préfacez les commentaires par`#`. Exemple : ``` Name: MyWorkflow # This is a comment. SchemaVersion: 1.0 ``` + **Triple tiret (`---`)** : Ne l'utilisez pas `---` dans votre code YAML. CodeCatalyst ignore tout ce qui se trouve après le. `---` ### Convention d'appellation Dans ce guide, nous utilisons les termes *propriété* et *section* pour désigner les principaux éléments d'un fichier de définition de flux de travail. + Une *propriété* est un élément qui inclut deux points (`:`). Par exemple, dans l'extrait de code suivant, toutes les propriétés suivantes sont des propriétés :`Name`,,`SchemaVersion`, `RunMode` `Triggers``Type`, et. `Branches` + Une *section* est une propriété qui possède des sous-propriétés. Dans l'extrait de code suivant, il y a une `Triggers` section. **Note** Dans ce guide, les « sections » sont parfois appelées « propriétés », et vice versa, selon le contexte. ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main ``` ## Propriétés de haut niveau Vous trouverez ci-dessous la documentation de référence pour les propriétés de haut niveau du fichier de définition du flux de travail. ``` # Name Name: workflow-name # Schema version SchemaVersion: 1.0 # Run mode RunMode: QUEUED|SUPERSEDED|PARALLEL # Compute Compute: ... # Triggers Triggers: ... # Actions Actions: ... ``` ### Name (Obligatoire) Nom du flux de travail. Le nom du flux de travail est affiché dans la liste des flux de travail et mentionné dans les notifications et les journaux. Le nom du flux de travail et le nom du fichier de définition du flux de travail peuvent correspondre, ou vous pouvez les nommer différemment. Les noms des flux de travail ne doivent pas nécessairement être uniques. Les noms des flux de travail sont limités aux caractères alphanumériques (a-z, A-Z, 0-9), aux tirets (-) 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 des flux de travail. **Interface utilisateur correspondante : editor/Workflow propriétés visuelles/nom du flux de travail** ### SchemaVersion (Obligatoire) Version du schéma de la définition du flux de travail. Actuellement, la seule valeur valide est `1.0`. Interface utilisateur correspondante : *aucune* ### RunMode (Facultatif) Comment CodeCatalyst gère plusieurs essais. Vous pouvez utiliser l'une des valeurs suivantes : + `QUEUED`— Plusieurs exécutions sont mises en file d'attente et exécutées les unes après les autres. Vous pouvez avoir jusqu'à 50 essais dans une file d'attente. + `SUPERSEDED`— Plusieurs exécutions sont mises en file d'attente et exécutées les unes après les autres. Une file d'attente ne peut comporter qu'une seule exécution. Ainsi, si deux séries se retrouvent ensemble dans la même file, la dernière remplace (prend le relais) de la précédente et l'exécution précédente est annulée. + `PARALLEL`— Plusieurs exécutions ont lieu simultanément. Si cette propriété est omise, la valeur par défaut est`QUEUED`. Pour de plus amples informations, veuillez consulter [Configuration du comportement de mise en file d'attente des exécutions](workflows-configure-runs.md). **Interface utilisateur correspondante : editor/Workflow propriétés visuelles/mode avancé/exécution** ### Compute (Facultatif) Le moteur informatique utilisé pour exécuter les actions de votre flux de travail. Vous pouvez spécifier le calcul au niveau du flux de travail ou au niveau de l'action, mais pas les deux. Lorsqu'elle est spécifiée au niveau du flux de travail, la configuration de calcul s'applique à toutes les actions définies dans le flux de travail. Au niveau du flux de travail, vous pouvez également exécuter plusieurs actions sur la même instance. Pour de plus amples informations, veuillez consulter [Partage du calcul entre les actions](compute-sharing.md). Pour plus d'informations sur le calcul, consultez[Configuration des images de calcul et d'exécution](workflows-working-compute.md). Interface utilisateur correspondante : *aucune* ``` Name: MyWorkflow SchemaVersion: 1.0 ... Compute: Type: EC2 | Lambda Fleet: fleet-name SharedInstance: true | false ``` #### Type (Compute/**Type**) (Obligatoire s'`Compute`il est défini) Type de moteur de calcul. Vous pouvez utiliser l'une des valeurs suivantes : + **EC2** (éditeur visuel) ou `EC2` (éditeur YAML) Optimisé pour la flexibilité lors des courses d'action. + **Lambda** (éditeur visuel) ou `Lambda` (éditeur YAML) Vitesses de démarrage des actions optimisées. Pour plus d’informations sur les types de calcul, consultez [Types de calcul](workflows-working-compute.md#compute.types). **Interface utilisateur correspondante : editor/Workflow propriétés visuelles/avancé/type de calcul** #### Fleet (Compute/**Fleet**) (Facultatif) Spécifiez la machine ou le parc qui exécutera votre flux de travail ou vos actions de flux de travail. Dans le cas des flottes à la demande, lorsqu'une action démarre, le flux de travail fournit les ressources dont il a besoin et les machines sont détruites à la fin de l'action. Exemples de flottes à la demande :`Linux.x86-64.Large`,`Linux.x86-64.XLarge`. Pour plus d'informations sur les flottes à la demande, consultez[Propriétés de la flotte à la demande](workflows-working-compute.md#compute.on-demand). Avec les flottes provisionnées, vous configurez un ensemble de machines dédiées pour exécuter les actions de votre flux de travail. Ces machines restent inactives, prêtes à exécuter des actions immédiatement. Pour plus d'informations sur les flottes provisionnées, consultez. [Propriétés de la flotte de véhicules provisionnée](workflows-working-compute.md#compute.provisioned-fleets) S'il `Fleet` est omis, la valeur par défaut est`Linux.x86-64.Large`. Pour plus d'informations sur les flottes de calcul, consultez[Flottes informatiques](workflows-working-compute.md#compute.fleets). **Interface utilisateur correspondante : editor/Workflow propriétés visuelles/avancée/parc de calcul** #### SharedInstance (Compute/**SharedInstance**) (Facultatif) Spécifiez la capacité de partage de calcul pour vos actions. Avec le partage de calcul, les actions d'un flux de travail s'exécutent sur la même instance (image de l'environnement d'exécution). Vous pouvez utiliser l'une des valeurs suivantes : + `TRUE`signifie que l'image de l'environnement d'exécution est partagée entre les actions du flux de travail. + `FALSE`signifie qu'une image d'environnement d'exécution distincte est démarrée et utilisée pour chaque action d'un flux de travail. Vous ne pouvez donc pas partager de ressources telles que des artefacts et des variables sans configuration supplémentaire. Pour plus d'informations sur le partage de calcul, consultez[Partage du calcul entre les actions](compute-sharing.md). Interface utilisateur correspondante : *aucune* ### Triggers (Facultatif) Séquence d'un ou de plusieurs déclencheurs pour ce flux de travail. Si aucun déclencheur n'est spécifié, vous devez démarrer manuellement votre flux de travail. 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). **Interface utilisateur correspondante : editor/workflow diagramme visuel/déclencheurs** ``` Name: MyWorkflow SchemaVersion: 1.0 ... Triggers: - Type: PUSH Branches: - branch-name FilesChanged: - folder1/file - folder2/ - Type: PULLREQUEST Events: - OPEN - CLOSED - REVISION Branches: - branch-name FilesChanged: - file1.txt - Type: SCHEDULE # Run the workflow at 10:15 am (UTC+0) every Saturday Expression: "15 10 ? * 7 *" Branches: - branch-name ``` #### Type (Triggers/**Type**) (Obligatoire s'`Triggers`il est défini) 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.triggers.expression). Pour obtenir des exemples, consultez [Exemples : déclencheurs dans les flux de travail](workflows-add-trigger-examples.md). **Interface utilisateur correspondante : editor/workflow diagramme visuel/Déclencheurs/Type de déclencheur** #### Events (Triggers/**Events**) (Obligatoire si le déclencheur `Type` est réglé sur`PULLREQUEST`) 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). Interface utilisateur correspondante : editor/workflow diagramme **visuel/déclencheurs/événements** pour la pull request #### Branches (Triggers/**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). Interface utilisateur correspondante : visualeditor/workflow diagram/Triggers//**Branches** #### FilesChanged (Triggers/**FilesChanged**) (Facultatif si le déclencheur `Type` est réglé sur`PUSH`, ou`PULLREQUEST`. Non pris en charge si le déclencheur `Type` est réglé sur`SCHEDULE`.) 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). **Interface utilisateur correspondante : editor/workflow diagramme visuel/déclencheurs/fichiers modifiés** #### Expression (Triggers/**Expression**) (Obligatoire si le déclencheur `Type` est réglé sur`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** | Minutes | Heures | Jours du mois | Mois | Jours de la semaine | Année | Signification | | --- | --- | --- | --- | --- | --- | --- | | 0 | 0 | ? | \$1 | MON-FRI | \$1 | Exécute un flux de travail à minuit (UTC\$10) du lundi au vendredi. | | 0 | 2 | \$1 | \$1 | ? | \$1 | Exécute un flux de travail à 2 h 00 (UTC\$10) tous les jours. | | 15 | 22 | \$1 | \$1 | ? | \$1 | Exécute un flux de travail à 22 h 15 (UTC\$10) tous les jours. | | 0/30 | 22-2 | ? | \$1 | SAT-SUN | \$1 | Exécute un flux de travail toutes les 30 minutes du samedi au dimanche entre 22 h 00 le jour de départ et 2 h 00 le jour suivant (UTC\$10). | | 45 | 13 | L | \$1 | ? | 2023-2027 | Exécute un flux de travail à 13 h 45 (UTC\$10) le dernier jour du mois entre 2023 et 2027 inclus. | 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). Interface utilisateur correspondante : editor/workflow diagram/Triggers **visuel/calendrier** ### Actions Séquence d'une ou de plusieurs actions pour ce flux de travail. CodeCatalyst prend en charge plusieurs types d'actions, tels que les actions de création et de test, qui offrent différents types de fonctionnalités. Chaque type d'action comporte les éléments suivants : + une `Identifier` propriété qui indique l'identifiant unique et codé en dur de l'action. Par exemple, `aws/build@v1` identifie l'action de génération. + une `Configuration` section qui contient les propriétés spécifiques à l'action. Pour plus d'informations sur chaque type d'action, consultez[Types d'action](workflows-actions.md#workflows-actions-types). La [Types d'action](workflows-actions.md#workflows-actions-types) rubrique contient des liens vers la documentation de chaque action. Voici la référence YAML pour les actions et les groupes d'actions dans le fichier de définition du flux de travail. ``` Name: MyWorkflow SchemaVersion: 1.0 ... Actions: action-or-gate-name: Identifier: identifier Configuration: ... #Action groups action-group-name: Actions: ... ``` #### action-or-gate-name (Actions/*action-or-gate-name*) (Obligatoire) *action-name*Remplacez-le par le nom que vous souhaitez attribuer à l'action. Les noms d'action doivent être uniques dans le flux de travail et ne doivent inclure que des caractères alphanumériques, des traits d'union et des traits de soulignement. Pour plus d'informations sur les règles de syntaxe, consultez[Consignes relatives à la syntaxe YAML](#workflow.syntax.conv). Pour plus d'informations sur les pratiques de dénomination des actions, y compris les restrictions, consultez le[action-or-gate-name](#workflow.actions.name). **Interface utilisateur correspondante : éditeur visuel/ *action-name* /onglet Configuration/Nom de l'action ou **nom d'affichage de l'action**** #### action-group-name (Actions/*action-group-name*) (Facultatif) Un *groupe d'actions* contient une ou plusieurs actions. Le regroupement des actions dans des groupes d'actions vous aide à organiser votre flux de travail et vous permet également de configurer les dépendances entre les différents groupes. *action-group-name*Remplacez-le par le nom que vous souhaitez attribuer au groupe d'actions. Les noms des groupes d'actions doivent être uniques dans le flux de travail et ne doivent inclure que des caractères alphanumériques, des traits d'union et des traits de soulignement. Pour plus d'informations sur les règles de syntaxe, consultez[Consignes relatives à la syntaxe YAML](#workflow.syntax.conv). Pour plus d'informations sur les groupes d'actions, consultez[Regrouper les actions dans des groupes d'action](workflows-group-actions.md). Interface utilisateur correspondante : *aucune*