Aller au contenu

Créer un modèle de pipeline

Les modèles de pipeline se rédigent dans les paramètres de l’espace de travail. L’entrée Pipelines de la barre latérale de l’espace de travail est la file d’exécution, et non la liste des modèles — elle n’offre aucune action « créer un modèle ».

Pour la signification de chaque type d’étape, de chaque clé de corps et de chaque champ de configuration, voir la référence des étapes de pipeline.

  1. Rendez-vous dans Paramètres → Espace de travail → Modèles de pipeline (/workspaces/<workspace-id>/settings/pipelines).
  2. Appuyez sur Nouveau modèle.

Aucune boîte de dialogue ne demande d’identifiant. L’éditeur s’ouvre immédiatement sur un squelette prérempli nommé Nouveau pipeline, doté d’un identifiant attribué automatiquement (pipeline_1, puis pipeline_2, …). Cliquez sur le titre dans l’en-tête pour le renommer.

Le canevas n’est pas vide : un nœud d’entrée Trigger, un nœud d’agent à prompt étiqueté Step et une sentinelle terminale qui met fin à l’exécution. La sentinelle n’est pas dessinée. L’éditeur recâble ce terminal masqué vers chaque puits atteignable, si bien que le travail que vous rattachez après Step s’exécute quand même.

La barre latérale Bibliothèque de nœuds reste en permanence à gauche de l’éditeur. Filtrez-la avec le champ Rechercher des nœuds et glissez une entrée sur le canevas — le nœud se pose là où vous le déposez, sans connexion entrante.

Nœud de la palette Type d’étape Ce qu’il fait
Bash script listen Exécute un script shell avec substitution de {{state}} ; aucun agent n’est lancé
Open conversation listen Ouvre l’unique espace visible de l’exécution et son checkout ; les nœuds d’agent rejoignent ce salon
Clone PR branch listen Découvre la branche de tête de la PR via gh pr view et la clone dans le répertoire de l’exécution
Post PR comment listen Publie les constats consolidés sur la PR sous forme de commentaire de revue GitHub
Reviewer (prompt) listen Lance un agent relecteur spécialisé ; suspend l’étape jusqu’à ce que l’agent soumette son résultat
Consolidate (join) join Attend plusieurs branches amont, puis demande à un agent de consolider leurs sorties
Custom prompt listen Nœud générique piloté par un prompt, routé via le corps promptAgent
Post to space listen Envoie un message dans un espace de messagerie
Condition / switch (router) router Fait bifurquer le flux selon une valeur d’état
If file exists (router) router Route "true" lorsqu’un chemin existe sous le clone, sinon "false"
Any file exists (OR router) router Route "true" dès que l’un des chemins listés existe
All conditions (AND router) router Route "true" uniquement lorsque tous les chemins listés existent
Team dispatch listen Lance une équipe entière et suspend l’étape jusqu’à sa fin
Approval gate listen Suspend le flux dans l’attente d’une décision d’approbation
For each (map) forEach Rend un prompt par élément, puis lance l’agent une seule fois avec ces prompts concaténés
Call sub-pipeline listen Exécute un autre modèle sous forme d’étape imbriquée
Clean up worktrees listen Supprime les arbres de travail isolés obsolètes ; déterministe, aucun agent n’est lancé

La bibliothèque les regroupe sous Flux et logique, Revue de PR, Agents, Messagerie et Code. Aucun groupe Demo n’existe.

Chaque nœud de travail possède un port de sortie circulaire sur son bord droit. Faites glisser depuis ce port vers un autre nœud pour les relier. Les déclencheurs de départ fonctionnent de la même façon : chacun possède son propre port, si bien qu’un câble partant de Calendrier ne quitte pas aussi Exécution manuelle. Appuyez sur Ajouter une étape (+) juste après un nœud pour insérer un type derrière lui. Survolez le milieu d’une arête existante et appuyez sur × pour la déconnecter.

Les connexions se modifient aussi depuis le nœud qui les reçoit :

  1. Sélectionnez le nœud en aval. Son panneau de configuration s’ouvre à droite.
  2. Faites défiler jusqu’à Triggers from et touchez la puce de chaque nœud amont que celui-ci doit écouter. Toucher une puce sélectionnée supprime la connexion.
  3. Si un nœud amont est un routeur, un bloc Clés de route apparaît sous les puces, avec un champ Clé de route depuis <nœud> par arête de routeur. Saisissez la clé sur laquelle cette arête se déclenche — true ou false pour les routeurs « fichier existe », ou le nom de cas pour un aiguillage.

Chaque nœud de déclenchement est un point d’entrée. Un nœud peut écouter plusieurs amonts (fan-in) et alimenter plusieurs avals (fan-out), et le graphe doit rester acyclique — rien dans l’éditeur ne vous empêche de câbler un cycle, vérifiez donc votre travail.

La sentinelle terminale est filtrée du canevas, elle ne peut donc pas être sélectionnée. L’éditeur la recâble vers chaque puits atteignable à chaque changement du graphe, si bien que le travail que vous rattachez après le Step prérempli s’exécute quand même. Un graphe vide (déclencheur sans successeur de travail) liste le déclencheur lui-même pour qu’une exécution se termine immédiatement.

Sélectionnez un nœud pour ouvrir son panneau de configuration. Les champs affichés dépendent du corps du nœud.

Chaque nœud possède un Libellé, des Clés d’entrée (clés d’état séparées par des virgules, lues au moment de l’exécution) et, sous Avancé, un Réducteur, un Délai d’expiration (ms), des Tentatives de réessai, Continuer si cette étape échoue et un Schéma de sortie. Les nœuds listen et join peuvent aussi basculer leur Type entre les deux.

Ajoute un sélecteur de périmètre de dépôts (quels dépôts de l’espace de travail extraire ; vide signifie aucun), un Nom de l’espace et une case à cocher Y ouvrir une conversation. Quand cette case est cochée, un champ Nom de la conversation nomme le fil avec lequel le salon s’ouvre. Les nœuds d’agent rejoignent ce salon — ils n’en ouvrent pas un à eux.

Ajoute Agent (l’agent à lancer), Prompt (utilisez {{key}} pour référencer des entrées ou des sorties amont) et Clé de sortie.

Le Délai d’expiration (ms) est exprimé en millisecondes, et non en secondes — 900000 correspond à 15 minutes. Saisir 900 donne 0,9 seconde à l’étape.

Le mode de conversation sous lequel s’exécute un nœud d’agent à prompt n’a pas de champ dans l’éditeur sur le nœud d’agent. Il voyage dans extras['mode'] (chat, plan ou review) sur le nœud Open conversation qui a créé le salon (review par défaut). Le définir sur une étape d’agent est ignoré. La clé est mise en correspondance exacte : toute autre orthographe est ignorée en silence.

Ajoute un champ Script bash. Il n’existe ni champ de répertoire de travail ni champ d’environnement, car ni l’un ni l’autre n’est configurable :

  • Chaque étape bash d’une exécution partage le répertoire courant <cc_root>/pipelines/<runId>/.
  • GITHUB_TOKEN est injecté depuis le magasin d’identifiants, si bien que gh et git clone https://x-access-token:$GITHUB_TOKEN@… fonctionnent sans configuration.
  • Le script est lancé comme l’exécutable littéral bash, donc bash doit figurer dans le PATH de l’hôte du serveur. C’est une considération Windows.

Un routeur évalue une condition et renvoie une clé de route ; le moteur ne déclenche que l’arête aval dont la clé de route correspond et marque les autres branches comme ignorées.

Sélectionner un routeur remplace le champ Clé de sortie par l’éditeur de condition. Choisissez l’un de ses quatre modes :

  • Fichier(s) présent(s) — au moins un — route "true" dès que l’un des chemins listés existe.
  • Fichiers présents — tous — route "true" uniquement lorsque tous les chemins listés existent.
  • Comparaison — compare une valeur d’état à un littéral.
  • Aiguillage — route selon la valeur d’une clé d’état, avec un cas par défaut.

Définissez ensuite les clés de route correspondantes sur les arêtes sortantes (voir Câbler les nœuds entre eux).

Les groupes booléens and / or / not sont pris en charge par le corps, mais ne peuvent pas être créés depuis ce formulaire — ils exigent un arbre de prédicats écrit à la main sous extras.predicate. Le vocabulaire complet des prédicats et des opérateurs figure dans la référence des étapes de pipeline.

Aucune configuration propre : elle attend toutes ses étapes amont.

Le portail lance l’agent approbateur dans une conversation masquée avec le prompt du portail, puis suspend l’étape. L’approbateur sollicite votre décision dans la conversation et la soumet avec submit_output sous la forme { "decision": "approved" | "rejected", "reason": "..." }. La décision est rangée sous la clé de sortie (approval_decision par défaut), de sorte qu’un routeur aiguillage en aval peut bifurquer dessus.

Définissez Agent sur l’approbateur et Prompt sur la question du portail. Le portail se résout via submit_output sous la forme { "decision": "approved" | "rejected", "reason": "..." }. Les nœuds Reviewer (prompt) soumettent de la même façon.

Ajoute ID d’équipe et Mode de répartition. Le sélecteur propose exactement deux modes :

  • allParallel — une tâche par membre, suspend l’étape jusqu’à ce que toutes soient terminées.
  • manager — lance le chef de file, qui délègue.

Toute autre valeur stockée se comporte comme allParallel. Réglez le Réducteur sur append pour rassembler le résultat de chaque membre dans une liste sous la clé de sortie.

For each parcourt par défaut la clé d’état items (extras.iterableKey / extras.itemKey sur le nœud). Il rend son prompt une fois par élément ({{item}} par défaut) et lance l’agent une seule fois avec ces prompts concaténés. Une collection vide se termine immédiatement avec une liste vide. Il ne s’agit pas d’un lancement parallèle par élément.

Call sub-pipeline suspend l’étape jusqu’à ce que l’exécution enfant atteigne un état terminal, puis fusionne l’état final de l’enfant sous la clé de sortie (subflow_result par défaut). Pointez-le vers un enfant avec extras.templateId. Un modèle ne peut pas s’appeler lui-même ; un enfant en échec ou annulé fait échouer l’étape parente, qui alimente alors la politique de nouvelle tentative et de continue-on-fail de cette étape.

Déclarer des entrées et autoriser les exécutions manuelles

Section intitulée « Déclarer des entrées et autoriser les exécutions manuelles »

Les deux se trouvent derrière Exécution manuelle, dans l’en-tête de l’éditeur.

  1. Appuyez sur Exécution manuelle.
  2. Activez Autoriser l’exécution manuelle. Cet interrupteur est enregistré immédiatement — il crée (ou supprime) la ligne de déclencheur manual qui fait apparaître le modèle dans le sélecteur d’exécution.
  3. Définissez Exécutions parallèles max si vous voulez un plafond (laissez vide pour illimité). Les lancements supplémentaires attendent dans l’état queued jusqu’à ce qu’une place se libère.
  4. Appuyez sur Ajouter une entrée pour chaque champ de formulaire qu’une exécution manuelle doit recueillir :
Champ Description
Clé Clé d’état sous laquelle la valeur est stockée ; référencez-la sous la forme {{key}}
Libellé Libellé affiché (par défaut, la clé)
Type Texte, Texte multiligne, Nombre, Bascule, Liste déroulante, Dépôt
Options Choix séparés par des virgules, pour la Liste déroulante uniquement
Valeur par défaut Valeur préremplie
Texte indicatif Texte d’indice à l’intérieur du champ vide
Texte d’aide Texte auxiliaire sous le champ
Obligatoire Indique si le formulaire d’exécution bloque sur une valeur vide

Une entrée Dépôt affiche un sélecteur sur les dépôts de l’espace de travail et renseigne repo_id, repo_local_path, repo_full_name et — lorsque le dépôt a un remote GitHub — repo_owner et repo_name dans la charge utile de l’exécution.

  1. Appuyez sur Enregistrer dans la boîte de dialogue. Les modifications d’entrées sont repliées dans le brouillon ; elles sont conservées lorsque vous enregistrez le modèle.
  1. Appuyez sur Enregistrer dans l’en-tête de l’éditeur. L’en-tête affiche « Modifications non enregistrées » tant que vous ne l’avez pas fait.
  2. Revenez dans Paramètres → Espace de travail → Modèles de pipeline et vérifiez que l’interrupteur de la ligne du modèle est activé. Le moteur refuse de démarrer un modèle désactivé, et un modèle désactivé n’apparaît jamais dans le sélecteur d’exécution.
  3. Pour le démarrer automatiquement, glissez un déclencheur depuis la bibliothèque de nœuds sur le canevas — voir Configurer des déclencheurs de pipeline.