SOP Fan-In : Git

Les événements des forges Git peuvent lancer des exécutions SOP. Lorsqu’un type d’événement est routé vers sop dans la table des événements du canal, le canal Git convertit l’événement forge normalisé en un événement SOP (le sujet est git.<alias>:<event_type>, la charge utile JSON structurée contient les champs repo/issue/PR) et le transmet au moteur. Seule la condition de mention est assouplie pour les événements de cycle de vie sop-routés : un pull_request.opened routé vers une SOP de tri se déclenche que l’auteur ait mentionné l’application ou non. Les contrôles de l’auteur s’appliquent toujours à toute transmission, SOP ou conversationnelle : les événements provenant du compte de l’application ou d’autres bots sont rejetés (sauf si listen_to_bots est défini), et la liste d’autorisation des pairs est appliquée au nom d’utilisateur de l’acteur. En d’autres termes, les routages sop contournent mention_only mais pas le filtrage des comptes internes et des bots, ni la liste d’autorisation des auteurs.

Le côté transport (fournisseur, authentification forge, polling, portée des dépôts, routes d’événements) est configuré sur le canal Git. Cette page couvre le déclencheur. Les types d’événements qui atteignent l’ingress SOP sont décidés par la table de routes events par événement du canal.

Déclencheur

Message entrant ou événement forge/platform sur un canal configuré (telegram, discord, slack, git, …). Live : diffusé par l’orchestrateur de canal lorsque le dispatch SOP du canal est activé. Le producteur forge Git définit un sujet d’événement sous la forme <channel>.<alias>:<event_type> et place event_type dans la charge utile, afin qu’une condition définie filtre les événements forge par type sans nécessiter de seconde forme de déclencheur.

Charger et vérifier le SOP :

zeroclaw sop validate

zeroclaw sop list
zeroclaw sop show <name>

Correspondance

Un déclencheur channel correspond à channel (le type de canal, git) et à un alias facultatif (l’instance configurée, par ex. default) ; le déclencheur lui-même ne comporte aucun champ topic. Les types d’événements qui atteignent l’entrée de SOP sont entièrement déterminés par la table de routage events par événement du canal ; le déclencheur sélectionne donc la source et la table de routage sélectionne l’événement. La chaîne git.<alias>:<event_type> visible dans les journaux est le topic d’événement généré par le canal ; pour limiter un déclencheur à un seul type d’événement, testez la charge utile avec une condition telle que $.event_type == "pull_request.opened". La charge utile JSON structurée de l’événement est transmise à l’événement SOP et est disponible pour une condition facultative du déclencheur ; le contexte de l’étape reçoit la forme plafonnée, assainie et encadrée. Une condition de chemin JSON telle que $.repo == "octo/repo" limite un SOP à un seul dépôt. Les types d’événements connus sont issue_comment.created, issues.opened, pull_request.opened, pull_request.closed, pull_request.merged, pull_request_review_comment.created, workflow_run.completed, workflow_run.failed et release.published.

Exécutez-le

Acheminez un type d’événement vers un SOP sur le canal (une entrée events avec sop = "<name>"), chargez un SOP dont le déclencheur channel désigne le canal (channel = "git", alias facultatif), puis déclenchez l’événement de la forge : ouvrez une issue/PR, ajoutez-y un commentaire, publiez une release ou laissez une exécution de workflow se terminer. Le canal normalise l’événement, analyse la charge utile pour en vérifier la sécurité et le distribue à chaque SOP chargé dont le déclencheur channel correspond et dont la condition (le cas échéant) est satisfaite. Le routage d’un type d’événement abonne également le canal à ce point de terminaison de la forge, de sorte que seuls les types d’événements routés sont interrogés.

Si rien ne démarre, vérifiez que le type d’événement est routé vers sop (et non laissé sur la valeur par défaut conversationnelle), que le déclencheur channel du SOP indique channel = "git" (ainsi que le bon alias) et que la condition est satisfaite par rapport à la charge utile. Consultez le tableau de dépannage de la vue d’ensemble du fan-in.

Balayage de réconciliation sans exécutions en double

Un balayage périodique de réconciliation peut être conservé comme filet de sécurité pour les événements de la forge arrivant pendant que le canal d’interrogation est hors ligne. Envoyez l’ID stable de l’élément de travail de l’événement Git comme dedup_key lorsque le balayage démarre la même SOP via la passerelle ou la RPC sops/run. Pour une pull request, la clé du canal Git est ghpr_<owner>/<repo>#<number> :

{
  charge utile: "{\"pr\":42}",
  "dedup_key": ghpr_octocat/example#42
}

La clé est limitée au nom de la SOP. Un événement de canal et une soumission de balayage (sweep) récente avec la même clé fusionnent dans la même exécution tant qu’elle est active ; une fois que l’exécution atteint un état terminal, la même clé peut lancer une nouvelle tentative. Omettre dedup_key conserve le comportement normal des exécutions manuelles. Les clés de plus de 512 octets sont rejetées.

Approuver et observer

Les exécutions qui atteignent un point de contrôle se mettent en pause en tant que WaitingApproval. Effacez-les ou inspectez-les avec le CLI (zeroclaw sop list, zeroclaw sop approve) ou hors bande via les endpoints d’approbation de la gateway API (GET /admin/sop/pending, POST /admin/sop/approve, POST /admin/sop/deny).

Voir aussi

• Canal Git: fournisseur, auth forge, polling, routes d’événements
• Vue d’ensemble du fan-in
• Syntaxe : le format de fichier SOP