Configuration du comportement de mise en file d'attente des exécutions - Amazon CodeCatalyst

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.

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, consultezExécution d'un flux de travail.

À 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 (voirFigure 1). 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 participer. 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 1illustre 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'BuildTestActionGroupaction 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 exécution en file d'attente »

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 ECS cluster Amazon, 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 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 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 #1. Run-6f666 et Run-5e555 seraient annulés.

  • Run-3c333 remplacerait Run-2b222 et serait le seul run restant dans la file d'attente #2. 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/.

  2. Choisissez votre projet.

  3. Dans le volet de navigation, choisissez CI/CD, puis Workflows.

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

  5. Choisissez Modifier.

  6. En haut à droite, sélectionnez Propriétés du flux de travail.

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

    2. Remplacé — voir À propos du mode d'exécution remplacé

    3. Parallèle — voir À propos du mode d'exécution parallèle

  8. (Facultatif) Choisissez Valider pour valider le YAML code du flux de travail avant de le valider.

  9. Choisissez Valider, entrez un message de validation, puis choisissez à nouveau Valider.

YAML
Pour modifier le mode d'exécution à l'aide de l'YAMLéditeur
  1. Ouvrez la CodeCatalyst console à l'adresse https://codecatalyst.aws/.

  2. Choisissez votre projet.

  3. Dans le volet de navigation, choisissez CI/CD, puis Workflows.

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

  5. Choisissez Modifier.

  6. Choisissez YAML.

  7. 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 section duYAMLDéfinition du flux de travail.

  8. (Facultatif) Choisissez Valider pour valider le YAML code du flux de travail avant de le valider.

  9. Choisissez Valider, entrez un message de validation, puis choisissez à nouveau Valider.