Attendre une approbation
Suspendez un workflow jusqu’à ce qu’une personne autorisée accepte ou refuse l’étape suivante.
Ajouter une étape d’approbation
Section intitulée « Ajouter une étape d’approbation »Ajoutez une tâche d’approbation avant une étape qui demande l’accord d’une personne, par exemple une fusion ou un déploiement. Le workflow se met en pause à cette tâche ; les tâches qui en dépendent attendent l’accord d’un acteur autorisé.
Le script affiche paused Deploy release 1.4 to production?, puis done Deployed, approved by maintainer.
Une étape d’approbation exige un checkpoint, l’état sauvegardé de l’exécution, ici sous .outpost/storage. Le second start() peut tourner dans un autre processus, des jours plus tard.
Soumettre une décision
Section intitulée « Soumettre une décision »Référence API : WorkflowDecision.
start() lève une erreur, sans appliquer aucune décision, si l’une d’elles ne correspond pas à la demande en attente.
Suspendre sans approbation
Section intitulée « Suspendre sans approbation »definePauseTask() prend les mêmes options et retient l’exécution jusqu’à ce que quelqu’un la laisse continuer, par exemple après une fenêtre de maintenance. Poursuivez avec action: "resume" ou arrêtez avec "reject".
Authentifier l’acteur
Section intitulée « Authentifier l’acteur »Outpost vérifie que actor figure dans actors, pas l’identité de la personne. Connectez la personne et vérifiez son droit de décider avant d’appeler start().
Demander à un agent, dans son brief, d’attendre une approbation n’est pas une étape d’approbation : seule une tâche d’étape d’approbation arrête l’exécution.
Exiger une décision signée
Section intitulée « Exiger une décision signée »Avec authentication: "signed" sur l’étape d’approbation, une décision doit porter une signature Ed25519 d’une clé liée à son acteur. Seul votre service de signature détient les clés privées ; gardez-les hors des sandboxes des workers.
La signature couvre tous les champs de la décision, plus keyId et expiresAt. Chaque WorkflowApproverKey lie un keyId à un seul actor et à sa publicKey.
L’expiration est vérifiée avec l’horloge du worker : gardez le service de signature et les workers synchronisés. Les décisions altérées ou expirées, et les clés inconnues, dupliquées ou liées à un autre acteur, sont refusées. Le checkpoint conserve le keyId vérifié, et une reprise qui retire authentication est refusée.
Renouveler les clés des approbateurs
Section intitulée « Renouveler les clés des approbateurs »keys s’exécute pour chaque décision signée : les changements s’appliquent sans redémarrage.
Approuver une exécution lancée par un job
Section intitulée « Approuver une exécution lancée par un job »Une planification cron ou un webhook exécute son workflow dans un worker de file. La valeur du job indique le runId, les pauses en attente et la version effective du checkpoint, qui ajoute un condensé de l’entrée du job.
Soumettez les décisions avec checkpoint: { store, runId, version } issus de cette valeur : voir Files de jobs et workers.
- Une étape d’approbation ne prend ni condition, ni retry, ni timeout, ni cache.
- Un job de workflow en file ne reçoit pas de décisions : appelez
start()hors du worker. - Modifier le
prompt, lesactorsou l’authenticationd’une étape d’approbation rend incompatible le checkpoint d’une exécution en pause : reprenez-la avec l’étape d’approbation inchangée. - Les signatures ne protègent pas le checkpoint : quiconque peut écrire dans son stockage est de confiance.
- Un
decisionVerifierpersonnalisé doit vérifier lui-même la signature, l’acteur et l’expiration. - Pour les questions que l’agent pose en travaillant, utilisez les tâches interactives.
API : defineApprovalTask · definePauseTask · WorkflowDecision · signWorkflowDecision · createEd25519DecisionVerifier · WorkflowApproverKey.