Pipelines : suivre la CI et préparer une correction

Installez et activez Pipelines depuis le Marketplace. Ce plugin payant prend en charge GitHub Actions, GitLab CI et Azure DevOps. Ajoutez une connexion dans ses réglages : nom, fournisseur, URL de l’organisation, projet et jeton, puis Tester et ajouter.

Les connexions sont rattachées au workspace et les jetons sont rangés à part, dans le trousseau isolé du plugin : ils ne sont jamais renvoyés à l’interface. Si aucune définition n’apparaît, vérifiez le workspace actif, le fournisseur, le dépôt choisi et les permissions du compte ; une connexion aux accès expirés est signalée comme telle.

Le dock Pipelines, en bas de la barre latérale, liste les pipelines de toutes vos connexions, groupés par dépôt, avec l’état de leur dernier run. La cloche d’une ligne active ou coupe les notifications de ce pipeline. Cliquez sur un pipeline pour l’ouvrir dans un onglet.

Les statuts se rafraîchissent automatiquement pendant que vous travaillez. Pour ménager les quotas, un rafraîchissement coûte deux appels par connexion, quel que soit le nombre de pipelines ; si le fournisseur limite les appels, les dernières données enregistrées restent affichées avec un avertissement.

L’onglet d’un pipeline affiche ses runs par jour, en direct : statut (Réussie, Échouée, Annulée, en cours…), commit, étape en échec, barre de progression des étapes, date et durée. Le champ Filtrer les exécutions… accepte plusieurs filtres séparés par des points-virgules : date, paramètre, auteur, run, branche ou statut. Lancer le pipeline déclenche un run sur la branche et avec les paramètres de votre choix.

Ouvrez un run pour voir ses jobs et leurs étapes avec leur durée, ses paramètres, ses dépôts et ses artefacts téléchargeables. Distinguez le résultat du run distant de celui d’un ticket : un ticket terminé ne prouve pas qu’une nouvelle CI a réussi.

Sur un run échoué, l’action Ouvrir les logs à la première erreur déplie directement l’étape fautive. Le champ Filtrer tous les logs… cherche dans l’ensemble des journaux, Copier copie le log affiché et l’horodatage des lignes s’active dans les réglages du plugin.

Chaque carte de run propose aussi : relancer les jobs en échec, relancer le run sur la même branche, annuler un run en cours et approuver ou rejeter un déploiement en attente. Ces actions agissent sur votre service CI : vérifiez la cible avant de les utiliser.

Le bouton Corriger automatiquement ce pipeline en échec (Autofix) ouvre le dialogue de création de ticket, prérempli : pipeline, définition, run, lien et extrait du premier journal en échec, expurgé et limité à 16 000 caractères. Choisissez l’agent, le modèle et le niveau de réflexion, précisez au besoin les vérifications locales, puis créez le ticket.

Un run ne produit qu’un ticket de réparation : relancer l’action retrouve le même ticket. Dans les réglages du plugin, Créer un ticket de réparation automatise la création pour chaque nouvel échec d’un pipeline surveillé, et Exiger la validation du ticket les garde en attente de votre accord. Lorsque ses outils MCP sont disponibles, l’agent consulte le contexte CI sans que vous recopiiez les journaux : voir les MCP internes.

En bas de l’onglet d’un pipeline, la zone Créer avec l’IA accepte une description en langage naturel, par exemple « Pipeline nocturne : tests e2e Playwright sur macOS et Windows, rapport HTML publié en artefact ». Créer le ticket de pipeline ouvre le dialogue de création : l’agent écrira la définition YAML dans le dépôt, dans son worktree, et vous la relirez comme tout autre changement.

Les tickets de réparation et de création rejoignent le board comme les autres : vous suivez leur avancement dans Mission Control, lisez le compte rendu et relisez le diff avant intégration. Le compte rendu doit distinguer les contrôles locaux des résultats distants effectivement consultés.

Pour une mission IA, indiquez explicitement les actions distantes autorisées : déclencher un run, relancer, approuver un déploiement. Une correction peut être validée avec les tests et builds locaux, puis une personne lance la CI distante.

Les commandes depuis l’app iPhone Horizon s’autorisent connexion par connexion, avec Autoriser les commandes depuis Horizon. Une connexion indisponible, un quota fournisseur ou des accès expirés peuvent retarder l’actualisation : vérifiez la date et l’état avant de conclure.