Voir les résultats

Cette page explique où trouver les runs de vos pipelines dans le tableau de bord, et ce que montre chaque partie de la page d’un run. Voir Fonctionnement pour le modèle sous-jacent.

Les captures proviennent d’un vrai run d’un petit pipeline : une étape build compile et teste un programme Go, puis envoie le binaire à une étape smoke-test qui l’exécute.

Trouver un run

1. Ouvrez Exécutions, dans la section Exécution du tableau de bord. Elle liste chaque run de l’organisation, du plus récent au plus ancien, avec son statut, son mode, son point d’entrée, ses ressources, son instance, son heure de début et sa durée. Le run direct est celui que vous avez lancé ; chaque run distribution est une étape que le pipeline a envoyée sur sa propre machine.

2. Cliquez sur un run pour voir un résumé, ou ouvrez-le pour atteindre sa page.

3. Ouvrez Groupes, également dans Exécution, pour voir ensemble les runs d’une exécution : le run direct et chaque run de distribution qu’il a démarré. La page d’un groupe trace les ressources demandées dans le temps, dessine la hiérarchie de distribution et liste les runs. Depuis la page d’un run, Aller au Groupe y mène aussi.

Lire la page d’un run

En-tête

Le haut de la page montre le statut du run, son mode, le point d’entrée lancé, quand il a été demandé, démarré et terminé, et les tags et paramètres avec lesquels il a été lancé. Un paramètre de type Secret n’apparaît que par son nom.

Graphe du pipeline

Sous l’en-tête, le pipeline est dessiné sous forme de graphe de traitements et de connexions, reconstruit à partir du programme réellement exécuté. Si le run a produit des événements de debug, une timeline court sous le graphe : chaque marque colorée est un groupe d’événements. Cliquez dessus pour zoomer, ou déplacez le curseur pour parcourir le run.

Le graphe met en surbrillance le traitement ou la connexion de l’événement sous le curseur, parmi ceux qu’il affiche. Une étape est composée de traitements internes : ouvrez-la avec la flèche de son nœud pour suivre ses propres événements.

Ressources

La page du run d’une étape liste ses parties : le moteur Mélodium, le conteneur de l’étape avec son image, et le volume qu’ils partagent, chacun avec le CPU, la mémoire et le stockage demandés. Ressources requises en fait le total.

Logs

Le panneau Logs diffuse les logs du run en quasi temps réel : il vérifie l’arrivée de nouveaux blocs toutes les quelques secondes tant que le run est en cours, et s’arrête une fois le run terminé. Les logs peuvent être téléchargés en un seul fichier à tout moment, y compris pendant le run.

Données de débogage

Sous les logs, le panneau Évènements de Débogage liste les événements capturés pendant l’exécution, un par ligne avec son heure et son type. Il est masqué par défaut : cliquez sur Afficher pour l’ouvrir, et filtrez par type, piste ou n’importe quel champ. Les événements se téléchargent de la même façon que les logs. Les runs rapportés avec --api-report les capturent au niveau basic par défaut ; voir Événements de debug.

Filtrés sur recvData.data, les événements ci-dessus montrent le binaire du build qui arrive au smoke test en quatre blocs de 4096, 1048576, 1048576 et 34046 octets, soit 2135294 octets, la taille affichée par l’étape build ; puis la sortie se ferme.

Les événements relayés depuis les machines qui ont exécuté les étapes apparaissent comme distant, avec le run d’où ils viennent et l’événement lui-même. L’audit des secrets apparaît aussi, en notant quel élément a utilisé quel secret, par son nom seulement : voir Ce qui passe par Cadence.CI.

Pour aller plus loin

• Connecter un cloud, comment l’instance exécutant une étape donnée a été choisie.
• Fonctionnement, ce qui est capturé aujourd’hui par rapport à ce qui figure sur la feuille de route.