Déboguer une opération Pulumi échouée

Une opération Pulumi a échoué. Trouvez ce qui l'a causé et corrigez-le. L'utilisateur vous la signale généralement, donc commencez par déterminer quelle opération déboguer et confirmez-la avec l'utilisateur avant de faire quoi que ce soit d'autre. Pulumi a enregistré l'erreur lorsque l'opération a échoué, donc une fois que vous savez quelle opération c'est, vous pouvez lire l'erreur de cet enregistrement sans rien relancer.

Les commandes ci-dessous accèdent à Pulumi Cloud via pulumi api, une sous-commande de la CLI Pulumi que vous exécutez dans votre shell. Chacune cible une stack par le chemin explicite {orgName}/{projectName}/{stackName} que vous passez, donc vous n'avez pas besoin que cette stack soit sélectionnée localement pour lire son enregistrement. La sélection de la stack importe plus tard, quand vous appliquez un correctif.

Commencez par l'opération que l'utilisateur vous a donnée

L'utilisateur fournit généralement l'opération comme un ensemble de champs : l'org, le project, la stack et la version de mise à jour (ou l'id de preview) — le plus souvent exprimés en prose, par exemple « déboguer la mise à jour 161 de vvm-dev ». Vous avez besoin de ces éléments pour adresser l'API : {orgName}, {projectName}, {stackName} et la version ou l'id de preview.

Complétez tout champ manquant à partir du contexte. Prenez l'org, le project ou la stack depuis la stack actuellement sélectionnée (pulumi stack --show-name, pulumi stack ls) ou Pulumi.yaml. Une version manquante signifie la mise à jour la plus récente sur cette stack.

Confirmez brièvement quelle opération vous avez trouvée, sa version ou son id de preview et la stack, avant de lire la suite. Gardez-le léger ; ils vous l'ont déjà indiqué.

Lisez ce qui a échoué

Une mise à jour échouée et un preview échoué enregistrent tous deux des événements du moteur, et l'erreur se trouve dans les messages de diagnostic à l'intérieur de ces événements. En utilisant les champs que vous avez fixés ci-dessus, récupérez les événements et extrayez les messages.

Pour une mise à jour échouée, utilisez le chemin update avec le numéro de version :

pulumi api /api/stacks/{orgName}/{projectName}/{stackName}/update/<version>/events \
  | jq -r '.events[].diagnosticEvent | select(. != null) | "[\(.severity)] \(.message)"' \
  | sed 's/<{%reset%}>//g'

Pour un preview échoué, utilisez le chemin preview avec l'id de preview :

pulumi api /api/stacks/{orgName}/{projectName}/{stackName}/preview/<preview-id>/events \
  | jq -r '.events[].diagnosticEvent | select(. != null) | "[\(.severity)] \(.message)"' \
  | sed 's/<{%reset%}>//g'

Lisez chaque message, pas seulement ceux marqués severity == "error". Une erreur de provider porte cette étiquette error, mais une erreur de programme, qui est le cas courant quand un preview échoue, arrive comme un diagnostic stderr étiqueté info#err. Le sed final supprime les codes de couleur de terminal que Pulumi intègre dans le texte, qui autrement s'affichent comme <{%reset%}>.

Trouvez la cause et où le correctif appartient

Une opération peut échouer avec des erreurs de plusieurs ressources, donc lisez d'abord tous les diagnostics, puis travaillez sur chaque erreur. Tracez chaque erreur jusqu'à la ressource qui l'a levée (son URN et type), jusqu'où cette ressource est déclarée dans le programme, et jusqu'aux entrées qui l'alimentent.

Le texte d'erreur vous indique quel type de problème c'est, et cela pointe vers où le correctif appartient. Un correctif Pulumi se fait dans l'un de trois endroits, et nommer le bon vous évite d'éditer du code qui n'a jamais été le problème.

Le programme. Le code est incorrect : une mauvaise référence, un mauvais type, une entrée que le provider a rejetée, ou une valeur utilisée avant qu'elle ait résolu. C'est ce qu'un preview échoué rapporte généralement, parce que le plan n'a pas pu être construit. Corrigez-le en éditant le code.
L'état. Le code est correct, mais l'état stocké et les vraies ressources cloud ne concordent pas. Réconciliez la dérive avec pulumi refresh et mettez une ressource qui existe déjà en dehors de l'état sous gestion avec pulumi import plutôt que de la recréer. Notez qu'une opération qui a échoué à mi-chemin de l'application peut avoir déjà changé certaines ressources, donc vérifiez l'état actuel avant de décider.
L'environnement. Le problème est en dehors de Pulumi : identifiants, permissions, OIDC ou quota. Corrigez le rôle, l'environnement ESC ou la capacité que le provider a rejetée, plutôt que le code de la ressource.

Corrigez la cause

Apportez le plus petit changement qui répond à la cause racine. Comment vous confirmez le correctif et comment vous le livrez, que ce soit sous forme d'édition locale ou de pull request, suivent le workflow de votre mode, pas cette skill.

Si l'utilisateur n'a pas dit quelle opération

Quand l'utilisateur ne vous donne rien sur quoi travailler, déboguez leur opération la plus récente sur la stack. La liste des mises à jour n'enregistre pas qui a exécuté chaque mise à jour, donc trouvez-la via l'API :

Exécutez pulumi whoami pour obtenir la connexion de l'utilisateur actuel.
Lisez la dernière mise à jour et qui l'a demandée avec pulumi api /api/stacks/{orgName}/{projectName}/{stackName}/updates/latest et comparez son requestedBy.githubLogin à la connexion de l'étape 1.
S'ils concordent, cette mise à jour est celle à déboguer. Si non, remontez une version à la fois avec pulumi api /api/stacks/{orgName}/{projectName}/{stackName}/updates/<n> jusqu'à ce que requestedBy.githubLogin correspond à l'utilisateur.

Dites à l'utilisateur quelle opération vous avez trouvée, sa version, son type et son résultat, et confirmez que c'est celle qu'il entend avant d'aller plus loin.

pulumi-debug-failed-operation