Coordonner une modification entre dépôts
Modifiez une API et ses clients, examinez chaque branche et approuvez leur intégration.
Ce que montre l’exemple
Section intitulée « Ce que montre l’exemple »- Plusieurs dépôtsUne tâche par checkout, chacune avec sa sandbox et sa branche.
- Réponses typéesL’agent de l’API renvoie une description validée de sa modification.
- Tâches et dépendancesLes clients démarrent après l’API et lisent son résultat.
- Concurrence, relances et délaisLes deux clients s’exécutent en même temps.
- ApprobationsUn mainteneur décide avant toute fusion.
- Exécutions durablesLe checkpoint conserve le travail terminé d’une exécution à l’autre.
Écrire le script
Section intitulée « Écrire le script »Enregistrez le script à côté de la configuration de la page Installation, puis remplacez les trois chemins par ceux de vos dépôts. Chaque dépôt dispose d’une branche séparée ; une approbation contrôle les étapes d’intégration.
Définissez la modification de l’API et le résultat que recevront les clients.
Mettez à jour les clients, attendez l’approbation, puis intégrez explicitement chaque branche.
Enregistrez l’exécution dans un checkpoint et utilisez rename-field.ts pour la démarrer ou la reprendre.
Exécuter le script
Section intitulée « Exécuter le script »Lancez le script principal pour créer les branches et attendre à l’étape d’approbation. Les modifications restent disponibles pour relecture dans chaque dépôt.
Le script affiche paused : les trois branches existent et attendent une relecture. Examinez outpost/rename-user-name dans chaque checkout, puis décidez.
Le script affiche done. Les branches sont fusionnées dans la branche courante de chaque checkout, l’API en premier. Rien n’est poussé.
Comprendre les étapes
Section intitulée « Comprendre les étapes »Chaque lien indique qui transmet quoi à qui, dans le sens de la flèche.
Un checkpoint ne contient que du JSON. Chaque tâche du workflow appelle donc le perform() de sa tâche isolée et garde repository, branch et commits, pas le résultat du dispatch.
Quand un dépôt échoue
Section intitulée « Quand un dépôt échoue »Chaque dépôt a sa branche et son historique : rien ne les relie. Par défaut, un échec annule les tâches en cours ; stopOnError: false laisse l’autre client terminer.
| Ce que vous voyez | Que faire |
|---|---|
api failed, clients skipped | Lisez task.error, corrigez la cause, lancez node rename-field.ts retry. |
Un client failed, l’autre done | retry relance seulement le client en échec, sur la même branche. Les autres viennent du checkpoint. |
approve rejected, merge skipped | Les branches restent. Reprenez-les, puis démarrez une nouvelle exécution avec un autre runId. |
merge failed après la fusion des premiers checkouts | Mettez à jour la branche bloquée, puis retry : les branches déjà fusionnées ne changent rien. |
Adapter l’exemple
Section intitulée « Adapter l’exemple »Ajouter des dépôts
Section intitulée « Ajouter des dépôts »Ajoutez une entrée à clients, par exemple client("cli", "/projects/cli"). L’approbation, la fusion et concurrency suivent la liste.
Utiliser des sandboxes cloud
Section intitulée « Utiliser des sandboxes cloud »Remplacez sandboxProvider par un fournisseur de Sandboxes cloud. Chaque tâche envoie son dépôt, et les commits de l’agent reviennent dans le checkout de l’hôte avant l’exécution de merge.
Relire avant l’approbation
Section intitulée « Relire avant l’approbation »Insérez une tâche de relecture en lecture seule par client, entre les clients et approve, et ajoutez les relectures au after de l’étape d’approbation.
L’exécution en pause contient alors chaque relecture : lisez-la avec result.value(task) avant de décider.
API : defineIsolatedTask · defineJsonResponse · defineApprovalTask · WorkflowOptions · WorkflowCheckpointOptions.