Le code est prêt. Le pipeline passe au rouge. Vous quittez l’éditeur, retrouvez le bon dépôt, ouvrez la bonne exécution, descendez dans les logs, puis revenez au code. Le plus fatigant n’est souvent pas la correction : c’est reconstituer le contexte.
Le plug-in Pipelines rapproche ces étapes dans Singularity. Il connecte votre CI/CD à l’espace où vous travaillez déjà : projets, Git, éditeur et kanban. Le fournisseur continue d’exécuter vos workflows ; Singularity vous aide à les suivre, à les comprendre et à préparer leur correction.
Trois fournisseurs, un espace de travail
Pipelines prend en charge GitHub Actions, GitLab CI et Azure DevOps. Les connexions sont rattachées au workspace : vous pouvez regrouper plusieurs dépôts ou projets distants dans le même environnement de travail, sans mélanger leurs accès.
Les définitions apparaissent dans la barre latérale. Vous sélectionnez un pipeline et retrouvez ses exécutions, leur branche, leur état et leur durée. Les indicateurs disponibles, comme le taux de réussite et la durée médiane, aident à repérer une série d’échecs ou un ralentissement.
Tout ce que vous pouvez faire avec Pipelines
| Besoin | Possibilité | Ce que cela évite |
|---|---|---|
| Surveiller | Consulter les définitions, l’historique et les états des exécutions. | Ouvrir plusieurs consoles CI pour retrouver le bon run. |
| Diagnostiquer | Explorer les étapes, les tâches et leurs logs ; accéder à la première erreur. | Parcourir tout le journal sans point de départ. |
| Récupérer un résultat | Consulter et télécharger les artefacts accessibles. | Rechercher le fichier produit dans le portail distant. |
| Piloter | Choisir la branche et les paramètres, lancer, annuler ou relancer selon les capacités du fournisseur. | Reconstruire les paramètres d’exécution ailleurs. |
| Valider une étape | Consulter et traiter les approbations proposées par le fournisseur. | Perdre de vue une exécution en attente d’intervention. |
| Rester informé | Activer le suivi d’un pipeline et recevoir les notifications de lancement et de fin, avec un signal sonore optionnel. | Revenir vérifier périodiquement si la CI a terminé. |
| Modifier la définition | Ouvrir le YAML local lié au projet lorsque la liaison est disponible. | Chercher à nouveau le fichier correspondant au workflow. |
| Créer ou réparer | Préparer un ticket IA de création ou de correction. | Recopier à la main le contexte CI dans une conversation. |
Les actions proposées dépendent du fournisseur, de l’état du run et des permissions de votre compte. Une relance des seuls jobs en échec ou une approbation n’est pas disponible partout. Vous pouvez toujours ouvrir le pipeline sur sa plateforme pour les opérations spécifiques.
Une erreur devient une tâche, avec Autofix
Depuis une exécution en échec, l’action de correction IA crée un ticket de réparation. Le run concerné devient le point de départ de l’enquête. Lorsque les outils MCP Pipelines sont disponibles dans la mission, l’agent peut lire les logs et la chronologie sans vous demander de les recopier.
- Comprendre l’échec. Lire la tâche en erreur et distinguer un problème de code, de configuration ou d’accès.
- Comparer. Examiner les exécutions précédentes et les changements Git pertinents.
- Corriger. Préparer une modification ciblée dans le projet, avec un test de régression lorsque le cas s’y prête.
- Vérifier localement. Exécuter les tests, validateurs et builds nécessaires, puis présenter le résultat dans le ticket.
- Relire et confirmer. Examiner le diff ; une personne ou votre automatisation autorisée lance ensuite la CI distante.
Un ticket terminé ne signifie pas qu’une nouvelle CI a réussi. La validation locale et le résultat distant sont deux preuves distinctes. L’IA prépare le travail ; les autorisations de votre équipe définissent les actions qu’elle peut effectuer.
Créer un pipeline à partir d’une intention
« Construire l’application et exécuter les tests sur les pull requests. » « Préparer un déploiement staging après validation. » Depuis le projet, la création de pipeline avec l’IA transforme cette intention en ticket. L’agent peut examiner la stack, les scripts existants et les connexions pour préparer une définition adaptée.
Le YAML reste le format natif de votre fournisseur, lisible et versionné dans votre dépôt. La préparation ne dispense pas de vérifier les branches, les environnements, les permissions et les secrets nécessaires. L’agent ne peut pas inventer un accès absent.
Le temps gagné : moins de manipulations, plus de concentration
Le gain ne vient pas d’un build qui s’exécuterait magiquement plus vite. Il vient du temps humain autour du build : navigation, surveillance, collecte des logs et remise en contexte. Pendant que la CI tourne ou que l’agent enquête, vous avancez sur une autre tâche.
Prenons un exemple illustratif, pas un benchmark : si retrouver l’erreur et préparer le contexte vous prend 15 minutes, et qu’ouvrir le ticket puis relire la proposition vous prend 5 minutes, vous récupérez 10 minutes d’attention par incident. Sur cinq incidents comparables, cela représente 50 minutes. Le résultat réel dépend de la complexité, de la qualité des logs et de la relecture nécessaire ; le temps d’exécution de la CI et de l’agent reste à compter séparément.
Pour mesurer votre propre gain, comparez le temps actif passé à collecter le contexte et à corriger manuellement avec celui passé à préparer et relire les tickets. Suivez aussi les corrections acceptées et les régressions : aller vite n’a de valeur que si la correction tient.
Commencer avec un pipeline utile
- Installez et activez le plug-in payant Pipelines depuis le Marketplace.
- Ajoutez une connexion GitHub Actions, GitLab CI ou Azure DevOps au workspace avec les droits requis.
- Ouvrez un pipeline fréquent, examinez son historique et activez son suivi.
- À la prochaine erreur, créez un ticket avec le résultat attendu et les vérifications locales à effectuer.
- Relisez la correction et vérifiez séparément le résultat de la prochaine exécution distante.
Les données sont actualisées en arrière-plan. Un quota fournisseur, une connexion indisponible ou des accès expirés peuvent retarder le rafraîchissement ; vérifiez la date du run avant de conclure à son état actuel.
Pipelines ferme la boucle entre code, CI et correction. Vous gardez vos fournisseurs et vos workflows, tout en ramenant le travail de diagnostic dans le même environnement que le développement. Pour les détails pratiques, consultez la documentation Pipelines et le workflow de développement par tickets.