Pipelines
dans Singularity.

Fiche vérifiée le 31 octobre 2026 · Canal production · Meteor Factory

Pourquoi utiliser Pipelines ?

Pipelines réunit les exécutions Azure DevOps, GitHub Actions et GitLab CI dans votre espace de travail. Retrouvez le statut d’une exécution, sa branche et ses journaux sans quitter Singularity.

Pour qui

Pour les développeurs et les équipes qui suivent les validations de leurs dépôts ou recherchent la cause d’un échec.

Ce que vous pouvez faire

• Connecter un dépôt GitHub, un projet GitLab ou un projet Azure DevOps.
• Parcourir les exécutions existantes, leurs étapes, jobs et journaux disponibles.
• Filtrer les lignes du journal et consulter les paramètres et dépôts d’une exécution.
• Suivre un pipeline et configurer les notifications de changement d’état.
• Préparer un ticket de création de pipeline assistée par IA depuis le menu du projet. L’agent et les autorisations du fournisseur déterminent la suite.

Les captures montrent le vrai plugin exécuté avec une API GitHub simulée et des données fictives. Aucun pipeline distant n’a été lancé. Les actions de lancement, arrêt, approbation et relance existent mais ne font pas partie de ce parcours de consultation.

Prérequis et activation

1. Ouvrez un espace de travail dans Singularity 2.x compatible avec le plugin et disposant d’une licence autorisant ce module payant.
2. Ouvrez le Marketplace, recherchez Pipelines, installez-le et acceptez ses permissions requises. Activez-le pour l’espace de travail si nécessaire.
3. Préparez un dépôt de démonstration possédant déjà un workflow et une exécution terminée. Pour reproduire les captures hors ligne, utilisez la recette locale ci-dessous : le dépôt demo-lab/pipeline-demo est fictif.
4. Pour un vrai fournisseur, utilisez vos propres coordonnées et un jeton autorisé à lire le projet, les pipelines, les exécutions et les journaux. Saisissez-le uniquement dans le champ de jeton. Les captures et fichiers de démonstration ne contiennent aucun identifiant utilisable.

Premier résultat

1. Dans le panneau Pipelines de l’espace de travail, choisissez Ajouter une connexion (bouton +), ou ouvrez les connexions depuis le menu de l’espace de travail.
2. Choisissez GitHub Actions. Donnez un nom à la connexion, renseignez le propriétaire GitHub dans le champ organisation et le nom du dépôt dans le champ projet. Exemple fictif : demo-lab et pipeline-demo.
3. Saisissez le jeton, puis choisissez Tester et ajouter. La connexion n’est enregistrée qu’après réussite du test. Le test lit les workflows ; il ne lance pas d’exécution.
4. Dépliez la connexion dans le panneau et sélectionnez un workflow existant. Ouvrez une exécution terminée, puis dépliez un job ou une tâche avec sa flèche de journal.

Résultat attendu : la liste affiche le statut, la branche et la durée ; le document de l’exécution affiche les jobs et les lignes disponibles. N’utilisez ni lancement, ni relance, ni réessai pour ce parcours.

Exemples

Lire un échec existant

Le jeu de démonstration contient Demo CI, l’exécution identifiée par 101 dans le fournisseur, la branche demo et le message Demo: verify greeting. Ouvrez son détail, puis le journal de Verify greeting. Recherchez Greeting mismatch avec le filtre de lignes. Le journal montre la valeur attendue Hello Pipelines et la valeur reçue Hello pipeline. Une ligne masquée par le filtre reste présente dans le journal ; effacez le filtre pour tout revoir.

Pour reproduire uniquement l’erreur en local, depuis un checkout Particles avec Node.js installé :

node plugins/pipelines/docs/demo/demo.mjs
node plugins/pipelines/docs/demo/demo.mjs --fixed

La première commande échoue avec Greeting mismatch (demo) ; la seconde affiche Greeting verified. Ces commandes n’envoient rien au fournisseur et ne créent aucun workflow.

Une connexion refuse les identifiants

Si le test de connexion renvoie 401, vérifiez l’expiration du jeton et les coordonnées du dépôt. Un 403 peut signaler des droits insuffisants ou un quota : lisez le message avant de changer la configuration. Dans le formulaire d’ajout, corrigez les champs puis testez à nouveau ; une connexion dont le test initial échoue n’est pas ajoutée. Sur une connexion existante, le bouton Tester affiche l’erreur sans lancer de pipeline. La recette simule un 401 et vérifie que la connexion existante est conservée.

Configuration

Le formulaire utilise un jeton personnel adapté au fournisseur. Les connexions et préférences sont propres à l’espace de travail ; les secrets sont stockés séparément. Les permissions réseau, secrets, paramètres, cache SQLite et événements du panneau sont requises. Les accès fichiers et notifications sont optionnels et doivent être autorisés pour les fonctions correspondantes.

Dans les réglages Pipelines, ajustez l’actualisation automatique et l’affichage des horodatages. Pour cette recette, désactivez l’actualisation et la création automatique de tickets d’échec. Le menu du projet permet aussi de préparer une création assistée par IA ; ce guide ne lance aucun agent ni écriture distante.

Limites

• Azure expose des étapes, jobs et tâches ; GitHub fournit des jobs regroupés dans une structure normalisée ; GitLab expose les journaux des jobs, sans sous-étapes équivalentes.
• Un job ignoré, encore actif ou dont les logs ont expiré peut ne pas proposer de journal lisible. Les artefacts et approbations dépendent du fournisseur.
• Le cache peut afficher le dernier état connu. Respectez les délais de quota ; multiplier les rafraîchissements ne les contourne pas.
• La recette vérifie le service et l’interface réels avec une API GitHub simulée. Elle ne valide ni authentification réelle, ni réseau, ni installation signée, ni Azure/GitLab distants, ni exécution d’agent IA.

Dépannage

Rejouer la recette locale

Depuis un checkout Particles avec Node.js >=22.5, pnpm et Chromium Playwright installés :

pnpm install --frozen-lockfile
pnpm build:tooling
pnpm exec playwright install chromium
node test/pipelines-documentation.playwright.mjs

Le test lance Chromium headless, connecte le dépôt fictif via le service réel, ouvre les exécutions et logs, puis vérifie un refus 401. Le transport interdit toute requête autre que GET et ne contacte aucun service distant. UPDATE_PIPELINES_DOC_SHOTS=1 devant la dernière commande renouvelle les captures éditoriales. La recette de maintenance docs/qualification/plugin-documentation/pipelines.md détaille aussi la vérification du Marketplace.

Continuer avec Singularity

Ce plugin s’utilise dans un espace de travail Singularity. Consultez les permissions et les conditions de licence dans le Marketplace avant de l’activer.

À découvrir aussi

• Data Tools
• GitHub Issues
• Image Tools
• Notes