À chaque exécution parallèle, attribuez à chaque tâche un destinataire distinct et un identifiant de corrélation, puis attendez et vérifiez le message correspondant. Cette méthode convient aux tests de votre propre application ; cette semaine, commencez par vérifier si plusieurs tâches interrogent réellement la même boîte avant de modifier la concurrence de GitHub Actions.

Cet article s’adresse aux personnes qui maintiennent des flux de travail GitHub Actions et constatent des codes mal attribués, des échecs intermittents ou des messages écrasés.
Il concerne aussi les ingénieurs QA et les petites équipes qui veulent fiabiliser les tests d’inscription et de réinitialisation sans mélanger les données de test avec les courriels de travail.

Un échec intermittent n’indique pas forcément une lecture croisée

Un code de vérification qui ne correspond pas à l’action en cours peut venir de plusieurs endroits. La tâche de test peut avoir lu le message d’une autre exécution, mais l’application peut aussi avoir envoyé un code différent de celui attendu, ou le message peut simplement ne pas être arrivé au moment de la vérification. Ces causes se ressemblent dans un journal réduit à « code incorrect » ; elles exigent pourtant des corrections différentes.

Les symptômes suivants orientent vers un état de réception partagé, sans le prouver à eux seuls :

  • Le test passe lorsqu’il est exécuté seul, mais échoue quand plusieurs tâches tournent en même temps.
  • Le code attendu correspond à un autre compte ou à une autre tentative de test.
  • Le résultat dépend de l’ordre des tâches, alors que le code de test et les données n’ont pas changé.
  • Un échec disparaît à la relance, sans modification de l’application ni du test.

Il faut distinguer trois pistes avant de toucher au flux CI. Une erreur d’envoi de l’application se vérifie en comparant l’événement métier, le destinataire demandé et le message effectivement produit. Un retard de réception se manifeste lorsque le message attendu finit par apparaître, mais après la lecture ou la fin du délai prévu. Une lecture croisée est plausible si un test consomme un message dont le destinataire, le contenu ou l’identifiant appartient à une autre exécution.

Comment distinguer un retard d’une boîte partagée ? Vérifiez d’abord si le message correct apparaît plus tard, puis comparez le destinataire et l’identifiant de corrélation avec les journaux du test. Si le message est absent, examinez l’envoi et le délai ; s’il existe mais porte l’empreinte d’une autre tâche, cherchez une collision dans le mécanisme de lecture.

L’exécution parallèle expose les boîtes partagées

GitHub Actions n’attribue pas automatiquement une boîte distincte à chaque tâche. Une stratégie de matrice peut lancer plusieurs variantes d’un travail ; si chacune déclenche un courriel puis interroge le même état de réception, elles peuvent se disputer les mêmes messages. Cela décrit une faiblesse possible dans l’organisation du test, pas un défaut universel de la plateforme ni une défaillance du service de courrier.

La documentation GitHub sur les tâches en matrice indique que les combinaisons de matrice sont exécutées en parallèle par défaut et qu’une matrice peut créer jusqu’à 256 tâches dans un flux de travail. Ce plafond documenté ne signifie pas qu’un projet doit lancer autant de tâches ; il montre pourquoi une boîte unique devient une ressource partagée dès que les tests sont découpés en variantes.

Dans un scénario de collision, chaque tâche peut faire les choses correctement isolément : déclencher une inscription, attendre un courriel et lire le premier message disponible. Le défaut apparaît parce que « premier message disponible » ne signifie pas « message de cette tâche ». Une tâche peut récupérer le message d’un autre compte, tandis que la tâche propriétaire lit ensuite un message déjà consommé ou le mauvais élément d’une liste.

La première vérification consiste donc à inventorier les ressources partagées : adresse de réception, boîte, dossier, jeton de lecture, filtres de recherche et identifiants de comptes. Il faut aussi vérifier si une lecture marque le message comme consommé ou si plusieurs tâches peuvent lire le même état. Ces détails dépendent de la mise en œuvre de votre système de test ; la documentation de GitHub Actions ne permet pas de conclure à leur place.

Faut-il une adresse différente pour chaque tâche CI ? Oui, si les tâches peuvent déclencher des courriels et les lire en même temps. L’isolation doit suivre le niveau réel d’exécution parallèle : si chaque variante agit sur un compte séparé, donnez-lui un destinataire distinct ; si plusieurs étapes d’un même test doivent partager la conversation, elles peuvent conserver le même destinataire, à condition de ne pas le partager avec d’autres tâches simultanées.

Associer chaque message à son exécution

La séparation des destinataires limite les collisions ; un marqueur de corrélation permet de retrouver la cause d’un échec et de confirmer l’appartenance du courriel. Utilisez un identifiant généré par le flux de travail, par exemple l’identifiant d’exécution, la tentative et l’étiquette de matrice. GitHub expose ces valeurs dans le référentiel des contextes disponibles dans les flux de travail.

À titre de schéma, une adresse ou une valeur de test peut être construite à partir de github.run_id, github.run_attempt et matrix.shard, si votre application et votre système de réception acceptent ces identifiants. Le principe est plus important que le format : la valeur doit être propre à l’exécution concernée, transmise à l’action testée et retrouvée dans le résultat observé. N’utilisez pas une adresse personnelle ni une donnée permettant d’identifier un utilisateur réel.

Quand l’application permet de personnaliser le contenu en environnement de test, elle peut également inclure un identifiant non sensible dans l’objet ou le corps du message. Le test peut alors rechercher un courriel dont le destinataire, cet identifiant et le type d’action concordent. Si le contenu ne peut pas être modifié, filtrez au minimum sur le destinataire et sur des éléments propres au scénario, puis vérifiez le lien ou le code avant de poursuivre.

Le test ne devrait pas se contenter d’extraire une suite de caractères ressemblant à un code. Il doit confirmer que le message vise le compte de test attendu, qu’il correspond à l’action déclenchée et que le lien ou le code est bien celui de cette opération. Cette vérification détecte également un défaut de génération côté application, au lieu de le confondre avec une erreur de réception.

Un identifiant de corrélation ne doit pas devenir un secret. Évitez d’imprimer des liens de réinitialisation complets, des jetons d’accès ou des codes valides dans des journaux accessibles à des personnes qui n’en ont pas besoin. La documentation de GitHub sur l’utilisation sécurisée des flux de travail recommande de traiter les données sensibles avec précaution ; appliquez ce principe aux sorties de test et aux pièces jointes de diagnostic.

Attendre le bon message plutôt que le premier message

Une attente robuste possède une condition de sortie explicite : le message correspondant est trouvé, ou le délai maximal prévu par le test est atteint. À chaque vérification, le test doit réappliquer ses filtres de destinataire et de corrélation. Une nouvelle lecture sans filtre ne corrige pas le problème : elle augmente seulement le risque de consommer un message sans rapport.

En cas d’échec, conservez les éléments qui permettent de départager les hypothèses : identifiant d’exécution, tentative, variante de matrice, destinataire de test, critères de recherche, état de l’envoi et résultat de l’assertion. Les journaux doivent préciser si aucun message n’a été trouvé, si un message a été trouvé mais rejeté par le filtre, ou si le message trouvé appartenait à une autre tâche. Évitez d’y inclure le contenu complet d’un lien de réinitialisation.

Une séquence d’analyse utile est la suivante :

  • Le déclenchement de l’action est-il bien confirmé dans l’application ?
  • Le destinataire enregistré correspond-il à celui attribué à la tâche ?
  • Le message attendu est-il arrivé, mais après la fin de l’attente ?
  • Les filtres ont-ils exclu le message parce que l’objet ou le corps différait ?
  • Un autre travail a-t-il lu ou consommé ce message en premier ?
  • Le lien ou le code extrait correspond-il à l’action de cette exécution ?

Ces contrôles évitent de traiter tout échec comme un problème de délai. Si le bon message arrive après la fin du test, ajustez la logique d’attente ou le traitement asynchrone. Si le message est absent, examinez l’envoi et les règles de réception. Si un autre scénario l’a consommé, séparez les destinataires ou l’état de lecture.

La concurrence contrôle les tâches, pas les boîtes

La configuration concurrency peut limiter l’exécution simultanée d’un groupe de travaux, mais elle ne crée pas d’adresses distinctes et ne rend pas une boîte partagée étanche. La documentation officielle sur la concurrence précise qu’un groupe de concurrence ne conserve qu’une exécution active et une exécution en attente ; une nouvelle exécution en attente peut remplacer celle qui attend déjà. Avec cancel-in-progress, une exécution active du même groupe peut aussi être annulée.

Cette politique est utile lorsqu’un test partage une ressource qui ne peut pas être isolée, par exemple un environnement de démonstration unique. Elle est moins adaptée comme correctif général à des courriels mélangés : limiter toute la suite réduit le parallélisme sans garantir qu’un message lu par un test sera bien le sien. Une annulation peut en outre transformer un défaut de configuration en échec de tâche ou supprimer une exécution utile au diagnostic.

Placez la limitation au niveau du travail qui utilise réellement la ressource commune, si ce niveau suffit. Avant de l’activer, vérifiez le nom du groupe, les règles d’annulation et l’effet sur les exécutions en attente. Si chaque tâche possède son propre destinataire et ses propres critères, préserver le parallélisme est généralement préférable à sérialiser toute la suite.

GitHub Actions peut-il corriger à lui seul les courriels attribués au mauvais test ? Non. La concurrence gère l’exécution des flux ou des tâches ; l’isolation des courriels relève de la conception des destinataires, des filtres et de l’état de réception. Utilisez la concurrence pour protéger une ressource réellement commune, pas comme substitut à un mécanisme d’association des messages.

Choisir le niveau d’isolation adapté

Avant de modifier le flux, cochez les actions vérifiées. Si un point reste incertain, traitez-le comme une hypothèse à tester plutôt que comme une cause établie.

  • [ ] Chaque tâche parallèle possède un destinataire ou un espace de réception qui lui est propre.
  • [ ] Le test connaît l’identifiant de son exécution et, le cas échéant, sa variante.
  • [ ] La recherche du message filtre sur le destinataire et sur un marqueur lié à l’action.
  • [ ] Le test confirme l’appartenance du lien ou du code avant de le valider.
  • [ ] L’attente se termine lorsque le message correspondant est trouvé ou lorsque son délai explicite expire.
  • [ ] Les journaux distinguent absence, retard, filtre incompatible et message attribué à une autre tâche.
  • [ ] La configuration de concurrence ne peut pas annuler des tests sans rapport avec la ressource partagée.
  • [ ] Les journaux et pièces jointes n’exposent pas de données personnelles réelles ni de jetons actifs.

Le tableau ci-dessous compare les options selon leur rôle, pas selon une promesse de rapidité ou de taux de réussite. Le bon choix dépend surtout de la capacité à isoler les destinataires et à retrouver les messages après un échec.

Approche Quand la retenir Risque restant Appréciation
Un destinataire distinct par tâche Les tâches parallèles déclenchent des messages indépendants Il faut gérer la création et le nettoyage des destinataires de test Meilleur choix pour limiter les lectures croisées
Une boîte commune avec marqueurs forts Le système ne permet pas de séparer les destinataires, mais les messages sont filtrables Les filtres et la consommation des messages doivent être vérifiés Acceptable si chaque message peut être attribué sans ambiguïté
Concurrence limitée sur une ressource partagée L’environnement ou la boîte ne peut réellement pas être utilisé simultanément Attente, remplacement d’une exécution en file ou annulation possible selon la configuration Solution de repli ciblée
Toute la suite exécutée séquentiellement Le parallélisme n’est pas nécessaire et le coût de durée est acceptable pour l’équipe Ne prouve pas l’isolation et peut masquer une collision À éviter comme correctif par défaut

Les artefacts de flux de travail peuvent aider à conserver des journaux expurgés ou des résultats d’assertion pour comparer plusieurs tâches. GitHub décrit les artefacts de flux de travail comme un moyen de partager des fichiers entre travaux et de les conserver après l’exécution. Déposez-y des métadonnées utiles, comme l’identifiant de corrélation et le résultat du filtre, mais pas des liens de réinitialisation utilisables ni des boîtes contenant des données personnelles.

Symptôme observé Vérification prioritaire Action suivante
Le code reçu correspond à un autre scénario Comparer destinataire, identifiant de corrélation et matrice Isoler les destinataires ou filtrer le message avant lecture
Aucun message n’est trouvé, puis le bon apparaît ensuite Comparer l’heure de déclenchement, l’attente et les journaux de réception Corriger la condition d’attente sans augmenter arbitrairement les délais
Le message existe mais le test le rejette Examiner les critères de recherche et les variations de l’objet ou du corps Ajuster le filtre et conserver une assertion sur le destinataire
Les échecs disparaissent quand le parallélisme est réduit Rechercher une boîte, un compte ou un état de lecture partagé Corriger l’isolation ; limiter uniquement la ressource impossible à séparer
Des tâches sont annulées après l’ajout de concurrency Vérifier le groupe et les options d’annulation Restreindre la règle aux travaux réellement en conflit

Pour une vérification manuelle ponctuelle de courriels envoyés par votre propre application, une boîte temporaire peut éviter de mélanger les tests avec une adresse personnelle ou professionnelle. VoidFwd peut servir à cette inspection lorsqu’un destinataire temporaire suffit, mais ne remplace ni l’isolation par tâche, ni les filtres de corrélation, ni l’analyse des retards d’envoi. Les tests automatisés qui exigent une boîte durable, une réponse par courriel ou une récupération à long terme doivent conserver une solution maîtrisée par l’équipe ; pour choisir entre une boîte temporaire et une adresse réutilisable, le comparatif entre adresse anonyme et alias aide à évaluer les limites de chaque option. Pour un contrôle occasionnel, VoidFwd permet d’ouvrir une boîte sans inscription et de l’utiliser immédiatement. Les règles de confidentialité sont détaillées dans la page consacrée à la protection des données.