Définition du flux de travail YAML - Amazon CodeCatalyst
Exemple de fichier de définition de flux de travailConsignes et conventions de syntaxePropriétés de haut niveau

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. Le fichier est stocké dans un ~/.codecatalyst/workflows/ dossier à la racine de votre dépôt source. Le fichier peut avoir une extension .yml ou .yaml.

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 plus d’informations, consultez Utilisation des éditeurs visuels et YAML de la CodeCatalyst console.

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+F. L'élément sera répertorié avec sa propriété YAML associée.

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 etTest. Pour plus d’informations, consultez À propos du fichier de définition du flux de travail.

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, 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 (_). 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înemy 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 TriggersType, 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 (_). 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 : éditeur visuel/propriétés du flux de travail/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 estQUEUED.

Pour plus d’informations, consultez Configuration du comportement de mise en file d'attente des exécutions.

Interface utilisateur correspondante : éditeur visuel/propriétés du flux de travail/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 plus d’informations, consultez Partage du calcul entre les actions.

Pour plus d'informations sur le calcul, consultezConfiguration des images Docker de l'environnement de calcul et d'exécution pour un flux de travail.

Interface utilisateur correspondante : aucune

Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:  
  Type: EC2 | Lambda
  Fleet: fleet-name
  SharedInstance: true | false

Type

(Compute/Type)

(Obligatoire s'Computeil 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, veuillez consulter Types de calcul.

Interface utilisateur correspondante : éditeur visuel/propriétés du flux de travail/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, consultezPropriétés de flotte à la demande.

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 du parc provisionné

S'il Fleet est omis, la valeur par défaut estLinux.x86-64.Large.

Pour plus d'informations sur les flottes de calcul, consultezFlottes informatiques.

Interface utilisateur correspondante : éditeur visuel/propriétés du flux de travail/Advanced/ Compute fleet

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 :

  • TRUEsignifie que l'image de l'environnement d'exécution est partagée entre les actions du flux de travail.

  • FALSEsignifie 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, consultezPartage du calcul entre les actions.

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.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/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'Triggersil 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 plus d’informations, consultez Expression.

Pour obtenir des exemples, consultez Exemples de déclencheurs.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/déclencheurs/type de déclencheur

Events

(Triggers/Events)

(Obligatoire si le déclencheur Type est réglé surPULLREQUEST)

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

  • 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'OPENomettre, car il s'REVISIONagit 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 de déclencheurs.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/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 parmain.

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 parv1-)

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

Pour plus d'informations sur les branches et les déclencheurs, consultezConsidérations relatives aux déclencheurs lors du branchement.

Pour obtenir plus d’exemples, consultez Exemples de déclencheurs.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/déclencheurs/branches

FilesChanged

(Triggers/FilesChanged)

(Facultatif si le déclencheur Type est réglé surPUSH, ouPULLREQUEST. Non pris en charge si le déclencheur Type est réglé surSCHEDULE.)

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 de déclencheurs.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/déclencheurs/fichiers modifiés

Expression

(Triggers/Expression)

(Obligatoire si le déclencheur Type est réglé surSCHEDULE)

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, heures, days-of-monthmois, days-of-weekannée

Exemples d'expressions cron

Minutes Heures Jours du mois Mois Jours de la semaine Année Signification

0

0

?

*

MON-FRI

*

Exécute un flux de travail à minuit (UTC+0) du lundi au vendredi.

0

2

*

*

?

*

Exécute un flux de travail à 2 h 00 (UTC+0) tous les jours.

15

22

*

*

?

*

Exécute un flux de travail à 22 h 15 (UTC+0) tous les jours.

0/30

22-2

?

*

SAT-SUN

*

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+0).

45

13

L

*

?

2023-2027

Exécute un flux de travail à 13 h 45 (UTC+0) 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-weekchamp days-of-monthou, 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 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, voirExemples de déclencheurs.

Interface utilisateur correspondante : éditeur visuel/diagramme de flux de travail/déclencheurs/calendrier

Actions

Séquence d'une ou 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, consultezTypes d'action. La Types d'action 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)

Remplacez action-name 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, consultezConsignes relatives à la syntaxe YAML.

Pour plus d'informations sur les pratiques de dénomination des actions, y compris les restrictions, consultez leaction-or-gate-name.

Interface utilisateur correspondante : éditeur visuel/nom de l'action/onglet de 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-nameRemplacez-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, consultezConsignes relatives à la syntaxe YAML.

Pour plus d'informations sur les groupes d'actions, consultezRegrouper les actions dans des groupes d'action.

Interface utilisateur correspondante : aucune