Lab 3.3 - Lire le log de déploiement, et ce que .forceignore lui cache¶

Niveau : 3 Release Manager

Durée : ~45 min

Vous allez : lire correctement un log de déploiement, relire une Pull Request dont le contrôle échoue sur un champ qui est pourtant dans son diff et trouver le fichier qui le cache, puis rattraper des actions de post-déploiement en échec après un merge, sans redéployer.

La situation¶

Merger la correction de présentation de page de Mariia a démarré un job de déploiement. La plupart des gens regardent la couleur et passent à autre chose.

Un release manager le lit, parce que le log de déploiement est le seul endroit qui dise ce qui a réellement atteint l'org, et que l'écart entre cela et ce que vous pensiez livrer est l'origine des incidents.

Avant de commencer¶

Lab 3.2 terminé : la correction de présentation de page de Mariia mergée dans integration

Partie 1 : lire le log¶

1. Ouvrir le job¶

Onglet Actions de votre fork (votre copie personnelle du repository du cours sur GitHub, par exemple github.com/my-username/sfdx-hardis-training), l'exécution Process Deployment (sfdx-hardis) qui a démarré quand vous avez mergé.

Ou depuis VS Code : le panneau DevOps Pipeline pose le job sur la flèche entre integration et son org (1), coloré selon son statut, et la légende sous le diagramme (2) dit ce que signifie chaque couleur. Cliquez sur le marqueur pour ouvrir l'exécution.

2. Le lire en cinq parties¶

Un log de déploiement sfdx-hardis a toujours la même forme :

Un : l'authentification. Quelle org, quel mécanisme. Sur integration, il dit auth URL : le raccourci du Niveau 1, que le Lab 3.1 a laissé en place. Sur preprod et main, il dit JWT. S'il dit un jour autre chose, c'est que quelque chose a changé sans que vous le changiez.

Deux : ce qu'il faut déployer. Le package qu'il a calculé, et d'où. C'est la partie intéressante et l'étape 3 en parle.

Trois : les actions pre-deploy. Tout ce qui est déclaré pour tourner avant, avec son résultat.

Quatre : le déploiement Salesforce. Composants déployés, tests lancés, couverture, durée. Sur un job de merge, cherchez Deployment mode: FULL + Quick Deploy. Le job de contrôle de votre Pull Request avait déjà validé ce package exact, tests compris, et le job de merge a demandé à Salesforce d'appliquer cette validation plutôt que de redéployer. C'est pourquoi il prend quelques secondes, et pourquoi il ne lance lui-même aucun test.

Cinq : les actions post-deploy, puis la notification.

3. Comprendre pourquoi le package est plus gros que le diff¶

Vous avez modifié un composant. Lisez maintenant ce que le job a réellement envoyé.

Ouvrez le package : panneau DevOps Pipeline, menu Deployment packages, Package XML. Il liste toute l'application Helios, quelques dizaines de composants, et c'est cela le package : sur ce projet chaque déploiement vers integration envoie le tout, quoi qu'ait dit le diff. Le compteur de composants envoyés du log le dira.

C'est le comportement par défaut, et il vaut la peine de le ressentir une fois avant d'apprendre ce qui le corrige.

Le déploiement delta. Au lieu d'envoyer le package déclaré, sfdx-hardis calcule ce qui a changé entre le commit déjà déployé dans cette org et le nouveau, et n'envoie que cela. Un déploiement Salesforce complet d'un projet mature prend 40 minutes ; un delta en prend 3. La contrepartie est que l'org doit vraiment être au commit où la pipeline la croit.

Ce projet a le delta désactivé, exprès

useDeltaDeployment est absent de config/.sfdx-hardis.yml : chaque déploiement de ce cours envoie donc le package complet. Lisez-le vous-même : DevOps Pipeline, menu engrenage, Pipeline Settings, portée Global Settings (1), onglet Deployment (2). Use Delta Deployment (3) affiche Disabled.

L'application Helios fait maintenant une soixantaine de composants : un déploiement complet coûte une minute et le delta n'économiserait rien tout en ajoutant une façon pour le cours d'échouer de manière déroutante sur une dépendance manquante. Activez-le quand un déploiement commence à vous coûter du temps réel, ce qui sur un vrai projet arrive vite. Il y a une deuxième clé pour les promotions entre branches majeures, enableDeltaDeploymentBetweenMajorBranches, dans l'onglet Danger Zone, et elle est désactivée par défaut pour la même raison : une promotion transporte davantage, et c'est l'endroit le plus risqué où en envoyer moins.

Trouvez la ligne Components: N deployed dans le log, sous Deployment summary. Sur une exécution standard de ce cours, elle tourne autour de soixante. Comparez-la avec l'unique fichier de votre Pull Request. L'écart est le coût du delta désactivé, et c'est l'argument pour l'activer.

4. Savoir ce qu'est Smart Deploy, et ce qu'il n'est pas¶

"Smart Deploy" est le nom de la commande, pas celui d'un filtre. sf hardis:project:deploy:smart est l'orchestrateur : il décide du package, réutilise un déploiement validé en Quick Deploy quand il le peut, lance les actions pre et post déploiement, traduit les erreurs Salesforce en conseils, et écrit le commentaire de la Pull Request. Il est intelligent sur le job, pas sur la comparaison entre votre repository et l'org composant par composant.

Deux choses qu'on suppose souvent en faire partie et qui n'en font pas partie :

Rien ne compare chaque composant à l'org pour écarter les identiques. Il existe un mécanisme optionnel qui en fait quelque chose d'approchant, manifest/packageDeployOnChange.xml, et il ne regarde jamais que les composants listés dans ce fichier. Le fichier n'existe pas dans ce projet, et il ne fait rien tant qu'il n'existe pas
Le nettoyage n'est pas un filtre de déploiement. Il a tourné sur la machine d'un contributeur, au moment du commit. L'étape 3 de la section sous le capot ci-dessous en parle

La réponse honnête à "pourquoi a-t-il déployé soixante composants pour en changer un" est donc : parce que rien n'a été configuré pour l'en empêcher. C'est une décision de ce projet, pas quelque chose que l'outil fait pour vous.

5. Vérifier dans l'org, pas dans le log¶

Ouvrez helios-integration depuis Orgs Manager : trouvez-la par son alias (2), vérifiez qu'elle dit toujours Connected (3), puis Open dans le menu d'actions au bout de sa ligne. Si elle dit déconnectée à la place, ce même menu propose Reconnect, et Add Org (1) est la façon de connecter une org que le tableau n'a pas du tout.

Vérifiez que votre modification est bien là : ouvrez un enregistrement Installation, et Total Capacity (kW) est de retour sur la présentation de page, dans la colonne de droite à côté du champ de plafond de Mariia.

Un log est une affirmation. L'org est le fait. Sur un vrai projet, vous vérifiez l'org après chaque déploiement vers un environnement majeur, et cela prend trente secondes.

Partie 2 : ce que .forceignore cache¶

6. Une Pull Request qui échoue sur un champ qu'elle transporte¶

Romain a une story pour les planificateurs. Training: Level 3 > Simulate my teammates, et choisissez US-056 Show the panels each crew member has to lay. Cela ouvre sa Pull Request vers integration.

Attendez ses contrôles. Le contrôle de déploiement échoue, et le commentaire sfdx-hardis nomme un champ :

Installation__c-Installation Layout  In field: field - no CustomField named Installation__c.Crew_Workload__c found

Ouvrez maintenant Files changed. Crew_Workload__c.field-meta.xml y est, dans le diff. Le champ est dans la Pull Request, et le déploiement dit qu'il n'existe pas.

7. Trouver ce que le déploiement n'a jamais vu¶

Quand un composant est dans la branche et pas dans le déploiement, le premier fichier à ouvrir est .forceignore. Il dit à la CLI Salesforce ce qu'il faut ignorer à la récupération et au déploiement, et un composant qu'il capture est invisible dans les deux sens, sans erreur ni avertissement.

Le diff de Romain le modifie lui aussi :

# My scratch test fields, never versioned (Romain)
**/objects/Installation__c/fields/Crew_W*.field-meta.xml

Cette ligne est un motif, pas un nom de fichier. Le * tient lieu de n'importe quel texte : il capture donc tout champ d'Installation dont le nom commence par Crew_W, son champ de test bricolé, et Crew_Workload__c, le champ de sa propre story. Le déploiement l'a laissé de côté, la présentation de page et le permission set qui s'en servent ont atteint l'org sans lui, et Salesforce les a refusés.

.forceignore est un fichier à l'échelle du projet, et c'est au release manager de le garder : une seule ligne négligente change ce que chaque déploiement envoie, pour tout le monde, à partir de là.

8. Le renvoyer avec la correction nommée¶

Laissez un commentaire de revue sur la ligne .forceignore du diff :

This wildcard also matches Crew_Workload__c, the field of this story, so no deployment ever sends it. Name your test field exactly, with no *, so nothing else can match by accident.

Un chemin exact vieillit mal lui aussi, mais il vieillit bruyamment : le jour où le fichier disparaît, rien d'autre ne se met à être ignoré.

Romain répond : Simulate my teammates > US-056 Romain names his test field exactly in .forceignore. Cela ajoute son commit à la même Pull Request, le contrôle retourne, et il passe au vert. Lisez le diff de son nouveau commit, puis mergez.

Sous le capot : d'où vient le package, et où se fait vraiment le nettoyage

Le job a lancé :

sf hardis:project:deploy:smart

et le package qu'il a envoyé a été construit ainsi :

Partir de manifest/package.xml, le package déclaré, plus manifest/destructiveChanges.xml pour ce qui est retiré
Le delta, si useDeltaDeployment est activé : sfdx-git-delta calcule les composants modifiés entre le dernier commit déployé et HEAD, et tout le reste est ressorti du package. enableDeltaDeploymentBetweenMajorBranches décide si la même chose s'applique à un déploiement de majeure à majeure, et est désactivé par défaut parce qu'une promotion vers la production est le pire endroit possible pour découvrir que l'org a dérivé
Le gestionnaire d'écrasement, quand le package contient quelque chose que manifest/package-no-overwrite.xml liste : l'org est interrogée, et tout composant listé dans ce fichier que l'org possède déjà est retiré. Quand rien dans le package ne correspond à la liste, l'org n'est pas interrogée du tout, et le log le dit. Il est limité à sa propre liste et à rien d'autre, et un composant qu'il protège est quand même créé dans une org qui ne l'a pas encore
Le deploy-on-change, si manifest/packageDeployOnChange.xml existe : ces composants, et eux seuls, sont récupérés depuis l'org et comparés, et ceux qui n'ont pas changé sont écartés

Les étapes 2 et 4 sont désactivées dans ce projet. L'étape 3 s'exécute, et ses lignes [NoOverwrite] sont dans le log, mais rien de ce que déploie Helios n'est encore dans sa liste : ce que Salesforce reçoit est donc l'étape 1.

Le nettoyage n'est pas dans cette liste, et c'est ce qu'il faut retenir. Les règles autoCleanTypes tournent à l'intérieur de sf hardis:work:save, sur la machine d'un contributeur, avant le commit. Elles réécrivent les fichiers sur le disque et commitent le résultat, c'est pourquoi le Lab 1.5 a pu vous montrer le diff qu'elles ont produit. Au moment où un déploiement tourne, il n'y a plus rien à nettoyer : le repository est déjà la version nettoyée.

Deux modes de défaillance à savoir reconnaître :

L'org a dérivé. Quelqu'un a modifié quelque chose dans l'org à la main et le déploiement l'écrase sans un mot, parce que rien n'a comparé. Le Lab 3.7 parle de cela
Le delta a perdu une dépendance. Votre modification a besoin d'un composant qui n'a pas changé, le delta ne l'emporte donc pas, et le déploiement échoue sur une référence. La correction n'est pas de désactiver le delta : c'est d'inclure la dépendance, ce à quoi sert manifest/package.xml

Documentation des commandes : hardis:project:deploy:smart, hardis:work:save

Partie 3 : quand une action de post-déploiement échoue¶

9. Merger une Pull Request dont les actions échouent après le merge¶

Mariia a une story faite d'actions de déploiement, sans métadonnées. Training: Level 3 > Simulate my teammates, et choisissez US-062 Put the delivery managers in a Crew Leads group. Cela ouvre sa Pull Request vers integration, avec trois actions de post-déploiement dans son fichier d'actions :

Put the delivery managers in the Crew Leads group, un script Apex
Recalculate the crew capacity once, une action Run Batch
Add the deployment user to the Crew Leads group, un script Apex

Son contrôle passe au vert. Cela prouve moins qu'il n'y paraît : les trois actions ne tournent que pendant le job de déploiement, après le merge, donc le contrôle les a sautées. Mergez-la.

Le job de déploiement passe au rouge. Les métadonnées sont déployées, puis la première action a échoué, et sfdx-hardis s'est arrêté là : les deux autres n'ont jamais tourné.

10. Lire ce qui a échoué, et ce qui n'a pas tourné¶

Le log du job nomme l'échec. Le script Apex a demandé à l'org un groupe public nommé Helios_Crew_Leads, et l'org n'en a pas :

System.QueryException: List has no rows for assignment to SObject

Mariia a créé le groupe à la main dans sa propre org, dans Setup, comme on en crée un le plus souvent : rien dans sa Pull Request ne le crée.

Le commentaire de déploiement de sa Pull Request s'ouvre sur ❌ Deployed to integration, but an action failed after the deployment : l'org a les nouvelles métadonnées. Sous ❌ Failed action, il montre la fin de la sortie du script, et sous ⏸️ Not run, waiting for the failed action les deux autres.

Le commentaire Deployment Actions de sa Pull Request résume tout dans son verdict, In integration: ❌ 1 failed · ⏸️ 2 waiting, et liste les trois actions sous Needs you (1) : ❌ pour celle qui a échoué, ⏸️ pour les deux qu'elle a arrêtées, chacune avec une case à cocher. Le tableau Status by org (2) dit la même chose dans la colonne integration.

La DevOps Pipeline vous demande d'abord deux choses. Récupérez integration et faites un pull, depuis le nom de branche de la barre d'état et le panneau Source Control : le panneau lit les actions dans la branche que vous avez récupérée, et le fichier d'actions de Mariia est arrivé sur integration avec son merge. Cliquez ensuite sur Refresh dans la barre du haut du panneau, pour qu'il lise le déploiement qui vient d'échouer.

Cliquez maintenant sur integration, puis sur l'onglet Deployment Actions. Les actions sont regroupées par Pull Request, numérotées dans l'ordre où elles tournent. La colonne Status (1) donne l'état de chaque action dans l'org d'integration, et celle en échec porte les boutons Retry et Mark as done in integration (2). Le menu au bout de chaque ligne contient le reste, Move to my Pull Request compris.

Aucune ne relance le job de déploiement : les métadonnées sont déjà dans l'org, et un second déploiement ne ferait que refaire ce qui a marché. La bonne façon d'en sortir dépend de la raison de chaque échec :

Pourquoi elle a échoué	Comment en sortir
Il manquait quelque chose à l'org, et elle l'a désormais	Retry
L'action elle-même est fausse	La déplacer dans une Pull Request de correction
Quelqu'un l'a déjà faite à la main	Mark as done

11. Corriger l'org, puis relancer¶

La première action est juste : c'est l'org à qui il manque son groupe. Créez-le dans helios-integration :

Ouvrez helios-integration depuis Orgs Manager, puis Setup, tapez Public Groups dans la boîte Quick Find, et cliquez sur New
Label Crew Leads, Group Name Helios_Crew_Leads, puis Save

La définition de l'action est lue dans la branche que vous avez récupérée, et c'est pourquoi l'étape 10 vous a fait récupérer integration et faire un pull. Si vous avez changé de branche depuis, revenez-y.

De retour dans l'onglet Deployment Actions, cliquez sur Retry sur la ligne de Put the delivery managers in the Crew Leads group. La commande tourne dans VS Code, sur helios-integration :

l'action tourne et passe au vert, et la commande demande quoi faire des deux actions que son échec a arrêtées (1)
répondez Run the next action only (2)
l'action de capacité des équipes tourne, et échoue (3) : la classe CrewCapacityBach n'existe pas

Le commentaire de la Pull Request indique maintenant ✅ pour la première action, avec une note disant que vous l'avez lancée depuis votre poste, ❌ pour l'action de capacité des équipes, et ⏸️ pour la dernière.

Sous le capot : ce que Retry a lancé

Le bouton a lancé :

sf hardis:project:action:run --pr <numéro de US-062> --action-id <id> --org-branch integration

Pas de déploiement. Elle lance la seule action, avec le code qu'un job de déploiement utilise pour chaque action : filtres de branches cibles, références aux sorties d'autres actions, contrôles de validité
L'org vient de la branche. integration désigne helios-integration par le targetUsername de config/branches/.sfdx-hardis.integration.yml, et la commande utilise cette org telle que vous l'avez connectée dans Orgs Manager. Les commandes sf que l'action démarre la ciblent pour cette exécution seulement : votre org par défaut ne change pas
Le résultat va dans le commentaire de la Pull Request, avec votre nom d'utilisateur git et votre nom d'utilisateur Salesforce dans la note, grâce au jeton du fournisseur git que VS Code détient. Sans lui, la commande refuse de tourner, parce que le déploiement suivant ne saurait pas que l'action a été faite
Les actions arrêtées sont mémorisées. Quand le job de déploiement s'est arrêté, il a enregistré les deux autres comme not-run, liées à celle en échec : c'est ainsi que la commande savait quoi proposer ensuite
Une action avec un customUsername tourne sous cet utilisateur. Quand votre poste n'y est pas connecté, la commande vous demande de vous connecter avec lui, et vérifie que vous l'avez fait

Documentation de la commande : hardis:project:action:run

12. Une définition fausse retourne à son auteur¶

Relancer l'action de capacité des équipes échouera à chaque fois : le nom de sa classe a une coquille, dans un fichier d'une Pull Request déjà mergée. Modifier ce fichier sur integration n'aiderait pas non plus : un déploiement ne lit que les actions des Pull Requests qu'il déploie.

Renvoyez-la. Commentez la Pull Request mergée de Mariia :

The crew capacity action names CrewCapacityBach, which does not exist: it should be CrewCapacityBatch. Can you move it to a fix Pull Request?

Elle la corrige comme le produit le propose : depuis sa nouvelle branche, Move to my Pull Request dans le menu de la ligne en échec déplace l'action dans le fichier d'actions de sa propre Pull Request, avec le même id, et elle y corrige le nom de la classe.

Simulate my teammates > US-062 Mariia fixes the crew capacity action. Relisez sa Pull Request :

Files changed : l'action a quitté le fichier d'actions de US-062 et est arrivée dans le fichier de la nouvelle Pull Request, avec className: CrewCapacityBatch et movedFrom qui vaut le numéro de US-062
toujours dans Files changed : un nouveau fichier, groups/Helios_Crew_Leads.group-meta.xml, et un bloc de plus dans manifest/package.xml. Un groupe public est une métadonnée comme une autre, et Mariia a mis le sien dans les sources. Dans integration, le déploiement trouve le groupe que vous avez créé à l'étape 11 et le garde, sous le libellé Crew Leads. Dans uat, preprod et la production, où personne n'a rien créé, le déploiement le crée avant que les actions ne s'exécutent. Sans ce fichier, la première action échouerait dans chacune d'elles comme elle a échoué ici
l'onglet Deployment Actions de sa Pull Request : ouvrez l'action, et l'éditeur montre d'où elle vient, sous Moved from (1)

Mergez-la. Son job de déploiement lance l'action, depuis la nouvelle Pull Request, et passe au vert. Rouvrez le commentaire Deployment Actions de US-062 : l'action de capacité des équipes indique ↪️ moved to la Pull Request de correction (1), avec un lien, au lieu d'une case rouge que personne ne pouvait effacer.

Quand les deux Pull Requests partiront ensemble vers uat, au Lab 3.5, US-062 ne portera plus l'action, et elle tournera une seule fois, depuis la correction.

13. Marquer comme fait ce qui a été fait à la main¶

La dernière action ajoute l'utilisateur de déploiement à Crew Leads. La relancer marcherait, mais la faire prend vingt secondes : faites-la à la main, comme un release manager le fait quand une livraison ne peut pas attendre :

Dans helios-integration, Setup > Public Groups > Crew Leads > Edit
Regardez Selected Members. Votre utilisateur y est déjà : la première action, que vous avez relancée à l'étape 11, a mis chaque delivery manager dans le groupe, et vous en êtes un. Il n'y a rien à ajouter, cliquez donc sur Cancel. Sur un vrai projet l'utilisateur de déploiement est un utilisateur technique qu'aucune autre action n'ajoute : vous le passeriez ici dans Selected Members, puis Save

Ensuite, dans l'onglet Deployment Actions, ouvrez le menu de Add the deployment user to the Crew Leads group et cliquez sur Mark as done in integration. Rien ne s'ouvre : sfdx-hardis l'enregistre en arrière-plan comme faite dans integration, avec une note qui vous nomme, et coche sa case dans les commentaires de la Pull Request. Le bouton affiche Marking as done... jusqu'à ce que l'action affiche Done dans l'onglet.

Le prochain déploiement vers integration la saute. Dans uat et au-delà, elle tourne toujours, parce que personne ne l'y a faite.

Cocher sa case dans la liste Needs you du commentaire Deployment Actions fait la même chose, enregistrée par le prochain job sfdx-hardis : utilisez-la quand vous êtes sur GitHub plutôt que dans VS Code.

Sous le capot : ce que laissent les trois façons d'en sortir

Retry a lancé sf hardis:project:action:run, comme à l'étape 11
Move to my Pull Request a lancé, côté Mariia :
```
  sf hardis:project:action:update --scope pr --pr-id <US-062> --when post-deploy --action-id <id> --move-to-pr <sa Pull Request>
```
Elle retire l'action de scripts/actions/.sfdx-hardis.<US-062>.yml, l'ajoute au fichier de sa Pull Request avec movedFrom: <US-062>, et garde son id. Quand un déploiement porte les deux, la copie d'origine est écartée, et l'exécution de la copie écrit ↪️ dans le commentaire de US-062 - Mark as done a lancé :
```
  sf hardis:project:action:set-status --pr <US-062> --action-id <id> --org-branch integration --status success
```
Le statut devient success, ce qui fait que les déploiements suivants la sautent, et la note garde la vérité : Not run in CI, then closed by hand by vous (votre nom d'utilisateur) on la date

Tout vit dans le commentaire "Deployment Actions" de la Pull Request qui porte l'action : aucun objet Salesforce, rien à installer. Ce commentaire est aussi l'endroit où un release manager regarde avant une promotion, pour voir ce qui est encore rouge.

Documentation des commandes : hardis:project:action:run, hardis:project:action:update, hardis:project:action:set-status

Ce que vous devez voir¶

Une exécution Process Deployment (sfdx-hardis) verte sur integration
Un log où vous savez dire combien de composants sont partis, et pourquoi ce nombre n'est pas un
La modification présente dans helios-integration
La US-056 de Romain mergée, Crew_Workload__c dans helios-integration, et plus aucun joker dans .forceignore
La US-062 de Mariia et sa correction mergées, et dans son commentaire Deployment Actions : ✅ pour la première action avec une note disant que vous l'avez lancée, ↪️ pour l'action de capacité des équipes, ✅ pour la dernière avec une note disant que vous l'avez close à la main
Dans helios-integration, un groupe public Crew Leads qui contient les delivery managers et vous
force-app/main/default/groups/Helios_Crew_Leads.group-meta.xml sur integration, pour que les orgs suivantes reçoivent le groupe par le déploiement

En cas de problème

Le déploiement a échoué alors que le contrôle était passé. Quelque chose a changé entre les deux : l'org, ou un autre déploiement arrivé avant. Lisez l'erreur, et vérifiez si quelqu'un a déployé à la main.

Le log dit "nothing to deploy". Avec le delta désactivé, cela ne devrait pas arriver sur ce projet, parce que le package est déclaré et non calculé. Si cela arrive, vérifiez que manifest/package.xml est toujours dans la branche et liste toujours quelque chose.

Le job n'a jamais démarré. Le workflow ne se déclenche que sur les pushes vers des branches majeures. Vérifiez que le merge a bien atterri sur integration.

Le contrôle de Romain échoue encore après son deuxième commit. Le contrôle a tourné sur le merge de sa branche avec integration telle qu'elle était au moment de son push. Si vous avez modifié .forceignore sur integration entre-temps, cliquez sur Update branch sur sa Pull Request : GitHub y merge integration, et le contrôle retourne.

L'onglet Deployment Actions n'a pas de colonne Status, ou pas de Retry dans le menu. L'état vient de sfdx-hardis, qui demande une version récente et votre connexion GitHub : mettez-le à jour depuis le panneau Dependencies, et vérifiez que l'icône du fournisseur git de la DevOps Pipeline est connectée. Une ligne ne propose Retry que si son action a échoué ou a été arrêtée, après le déploiement.

Retry dit qu'aucune org de helios-integration n'est connectée. Connectez helios-integration dans Orgs Manager, puis cliquez à nouveau sur Retry.

Retry dit ne pas trouver l'action. La définition est lue dans la branche que vous avez récupérée : récupérez integration et faites un pull, pour que le fichier d'actions de Mariia soit là.

La première action échoue encore après la création du groupe. Vérifiez le Group Name : il doit être exactement Helios_Crew_Leads. Le libellé peut être n'importe lequel.

La correction de Mariia s'arrête sur "not merged in your fork". Sa correction retire une action du fichier d'actions de US-062, nommé d'après le numéro de sa Pull Request : mergez d'abord US-062.

Vérifiez votre travail¶

Welcome page > Training: Level 3 > Check my work, puis choisissez le Lab 3.3.

Pour aller plus loin¶

Suite : Lab 3.4 - Trois Pull Requests se percutent : choisir l'ordre de merge