Passer au contenu principal
Référence complète du périmètre fonctionnel d’Outposts : la CLI du worker, la fleet API, la distribution du binaire devin-remote et le contrat de spawn pour les orchestrateurs personnalisés.

Authentification

Les workers et les orchestrateurs s’authentifient à l’aide d’un jeton d’API v3 appartenant à un utilisateur de service. Le rôle attribué à l’utilisateur de service confère au jeton ses périmètres Outposts : Les Outposts sont associés à votre compte et partagés entre toutes les organisations de ce compte.

CLI

devin worker start

Interroge périodiquement la file d’attente d’un outpost, prend en charge les sessions, télécharge le bon binaire devin-remote et exécute les sessions. Lancez-la depuis le répertoire contenant les dépôts extraits pour la session.
L’environnement du worker peut également inclure DEVIN_CHROME_PATH pour faire pointer les sessions vers un binaire Chrome/Chromium pour les fonctionnalités de navigateur.

devin worker outpost create

Crée un outpost — une file d’attente de sessions nommée, gérée par votre infrastructure. Nécessite le périmètre orchestrator.
Affiche l’ID du nouvel outpost (outpost_env-...). Vous pouvez également créer des outposts dans l’application web, sous Settings → Environment → Outposts.

devin worker outpost delete

Supprime un outpost. Nécessite le périmètre « orchestrator ».

Fleet API

Tous les endpoints se trouvent sous https://api.devin.ai/opbeta/outposts/ et utilisent un jeton Bearer :
Les ressources suivent une structure de type Kubernetes metadata / spec / status, et la file d’attente suit la sémantique Kubernetes « list-then-watch » avec une garantie de livraison au moins une fois.

Objets

Entrée de file d’attente (devins)

Chaque session en file d’attente est représentée par une entrée de file d’attente : spec.network_policy indique si l’accès réseau de la session est restreint (enabled) ainsi que les destinations autorisées (allow) : motifs de nom d’hôte ({"hostname": ...}), adresses IPv4/plages CIDR ({"ipv4": ...}) ou adresses IPv6/plages CIDR ({"ipv6": ...}).

Outpost

Lister les sessions en attente

Exemple de réponse :
Pagination et sémantique de livraison :
  • Passez le cursor de chaque réponse dans la requête suivante tant que has_next_page vaut true.
  • La livraison suit une sémantique « at-least-once » : une session à la jonction de deux pages peut apparaître dans les deux. Effectuez donc un upsert des entrées à partir de metadata.session_id plutôt que de traiter chaque élément comme nouveau (le CAS de prise en charge rend les doublons inoffensifs).
  • Lorsque has_next_page passe à false, enregistrez le curseur renvoyé comme position de départ pour une opération de surveillance.

Surveiller les modifications

Diffuse des Server-Sent Events. Les événements MODIFIED sont déclenchés lorsque l’entrée de file d’attente d’une session est modifiée (les sessions nouvellement placées en file d’attente arrivent également comme MODIFIED) ; les événements DELETED sont déclenchés lorsqu’elle est supprimée. Chaque champ SSE data contient :
Sémantique de surveillance :
  • Conservez le cursor de premier niveau de chaque événement après l’avoir traité ; reconnectez-vous avec le dernier curseur enregistré pour rejouer les modifications survenues pendant la déconnexion.
  • La livraison s’effectue au moins une fois — prévoyez donc la possibilité d’événements en double.
  • Les flux se terminent au bout de cinq minutes maximum ; une boucle de surveillance avec reconnexion est donc attendue.
  • Les filtres phase et acceptor_id sont ignorés lorsque watch=true ; filtrez les événements surveillés à l’aide des champs de l’object de chaque événement.
  • Si vous omettez le curseur, le flux démarre depuis le début ; utilisez donc list-then-watch pour une réconciliation normale.

Récupérer une entrée de file d’attente

Renvoie l’entrée de file d’attente d’une session.

S’attribuer une session

Prend en charge de manière atomique la session pour l’identité du worker spécifiée. Si un autre worker l’a prise en charge en premier, la requête échoue avec 409. Une réponse de prise en charge réussie inclut status.connect_token et status.gateway_url — les identifiants dont devin-remote a besoin pour se connecter (voir le contrat de spawn). La prise en charge implique qu’un worker sera prêt avant l’échéance de prise en charge attribuée par le serveur (status.claim_deadline) ; les prises en charge expirées sont automatiquement remises dans la file d’attente.

Libérer une prise en charge

Libère la prise en charge par le worker afin que la session retourne immédiatement dans la file d’attente (par ex. en cas d’échec du provisionnement).

Outposts

Corps de la requête de création :
La création, la récupération et la suppression nécessitent le périmètre orchestrator ; chaque réponse d’outpost indique en temps réel status.queue_depth et status.active_claims.

Distribution du binaire distant

La commande devin worker start télécharge automatiquement le binaire devin-remote approprié. Les orchestrateurs personnalisés qui n’utilisent pas le Devin CLI peuvent le récupérer directement ici :
Déterminez la version la plus récente :
Télécharger et vérifier :
Plateformes disponibles : Si l’élément de file d’attente de la session contient un spec.remote_binary_sha, utilisez ce SHA au lieu de latest — cela verrouille la session sur une version spécifique testée.

Contrat de spawn

Si votre orchestrateur lance lui-même devin-remote au lieu d’utiliser devin worker start, démarrez-le comme suit :
avec les variables d’environnement suivantes : Fournissez au remote un environnement propre contenant uniquement les variables ci-dessus, ainsi que les variables système de base (PATH, HOME, USER, LOGNAME, TMPDIR, LANG, TZ et — pour la capture d’écran du flux du bureau sous Linux/X11 — DISPLAY, WAYLAND_DISPLAY, XAUTHORITY). Ne laissez rien fuiter dans le remote que l’agent ne devrait pas pouvoir voir : il est hérité par le shell de l’agent. Attentes supplémentaires concernant le cycle de vie :
  • Répertoire de travail : lancez le remote depuis le répertoire contenant les dépôts de la session (même règle que pour devin worker start).
  • Fin de session : lorsque la session se termine (se met en veille ou s’arrête), Devin notifie le remote et celui-ci s’arrête de lui-même avec le code de sortie 0. Traitez un arrêt propre comme la fin de la session : confirmez que le status.session_status de l’entrée de file d’attente est suspended ou terminated (la mise à jour du statut peut avoir quelques secondes de retard, donc revérifiez plusieurs fois), puis libérez la prise en charge. En solution de repli, interrogez aussi périodiquement status.session_status pendant l’exécution du remote et tuez vous-même le processus dès qu’il atteint terminated (ou que l’entrée de file d’attente disparaît).