Automatiser les releases GitHub avec des agents IA et une approbation

L'automatisation des releases doit supprimer le travail administratif, pas donner à un agent de programmation le pouvoir de distribuer un logiciel dès qu'il le juge terminé. Un agent peut rassembler les changements, calculer une version, construire une release candidate, rédiger les notes et réunir les artefacts. La publication et le rollback doivent rester soumis à l'examen d'une personne, qui approuve une demande de release précise.

Cette limite peut sembler prudente jusqu'au jour où il faut corriger une release contenant le mauvais binaire, un tag déplacé ou des notes promettant un correctif qui n'a jamais été livré. L'appel API est simple. Annuler ses conséquences ne l'est généralement pas.

Donnez à l'agent un atelier de release, pas la propriété du dépôt

Un agent de release doit disposer d'un petit ensemble explicite d'opérations correspondant au travail attendu. Un accès étendu en écriture au dépôt semble pratique, car il évite de concevoir une interface. Il permet aussi à une instruction erronée de transformer une tâche de release en suppression de tag, modification de branche, édition de workflow ou annonce publique.

Pour l'automatisation des releases GitHub, je sépare la préparation de la distribution. L'agent peut lire les métadonnées du dépôt, examiner les commits d'une plage approuvée, lancer le build, calculer les hachages des artefacts, créer ou mettre à jour une release brouillon et téléverser des artefacts dans ce brouillon. Il ne peut pas publier une release, en supprimer une, modifier un tag, changer les paramètres du dépôt, créer des jetons ou appeler un endpoint GitHub arbitraire.

Écrivez les actions autorisées sous forme de verbes avec des entrées fixes. C'est plus utile que de demander à un agent de « faire attention ».

• inspect_release_range(base_tag, head_sha) renvoie les commits et les pull requests
• build_candidate(head_sha) renvoie les artefacts et les condensés SHA-256
• create_draft(version, target_sha, notes) renvoie l'identifiant du brouillon
• upload_asset(draft_id, filename, digest) téléverse un fichier vérifié
• request_publish(draft_id) crée une demande d'approbation

Le dernier verbe compte. request_publish ne doit jamais publier discrètement si personne ne répond. Il doit renvoyer un état en attente que l'appelant peut afficher et interroger. Un workflow de release qui interprète un délai d'expiration comme un consentement a déjà détruit son propre contrôle.

Évitez une porte de sortie comme github_api(method, path, body). Les équipes l'ajoutent pour l'opération atypique qui ne rentrait pas dans leur première conception. L'agent finira par l'utiliser, car les modèles de langage préfèrent le chemin le plus court dans une interface. Chaque méthode de requête sans restriction transforme votre autorité limitée en jeton général sur le dépôt.

La même règle s'applique à l'accès au shell. N'exposez pas gh avec des arguments arbitraires en prétendant qu'il s'agit d'une interface de release. Encapsulez les opérations précises que vous acceptez, validez leurs arguments et refusez tout le reste. Si vous avez besoin d'une nouvelle action le mois prochain, ajoutez-la délibérément, testez-la et décidez où placer la confirmation.

Une release brouillon est un objet à examiner, pas une release publiée

Une release brouillon GitHub permet d'assembler le contenu public sans le rendre public. Le reviewer dispose ainsi de quelque chose de concret à examiner : version, commit cible, notes générées, fichiers joints, sommes de contrôle et statut de pré-release. Un message disant « v2.4.0 est prête à être publiée » ne constitue pas une preuve suffisante.

La documentation REST de GitHub distingue la création d'une release avec draft: true de sa publication, qui consiste à modifier l'état du brouillon. GitHub précise aussi que make_latest détermine quelle release est présentée comme la plus récente. Ces champs peuvent ressembler à de simples métadonnées, mais ils ont des conséquences pour les utilisateurs et les outils. Traitez-les comme des choix de publication, et non comme des valeurs par défaut qu'un agent devrait deviner.

Une demande solide contient des identifiants immuables. La chaîne de version est utile aux personnes, mais le SHA du commit identifie le code réellement examiné. Le condensé de l'artefact identifie le fichier réellement construit. Si la demande dit seulement « publier v2.4.0 », le reviewer doit reconstituer la release pendant qu'un agent impatient attend.

Utilisez une fiche d'approbation structurée comme celle-ci :

{
  "operation": "publish_release",
  "repository": "acme/widgets",
  "draft_id": "123456",
  "version": "v2.4.0",
  "target_sha": "8b0c5f7c2d6c4e1a9f1a3b0e5e92d7a4c6f80c11",
  "prerelease": false,
  "make_latest": "true",
  "assets": [
    {"name": "widgets-v2.4.0.tar.gz", "sha256": "b3e1..."},
    {"name": "widgets-v2.4.0.tar.gz.sha256", "sha256": "f18a..."}
  ],
  "notes_digest": "c921..."
}

L'approbateur doit ouvrir le brouillon et comparer cette fiche avec l'état du dépôt. Le condensé des notes peut sembler excessif jusqu'à ce que quelqu'un modifie un brouillon après sa revue. Il n'est pas nécessaire de considérer chaque virgule comme immuable, mais il faut savoir si la liste des artefacts, la cible ou la classification de la release a changé.

Un brouillon n'est pas inoffensif par défaut. Il peut être visible par les utilisateurs ayant accès au dépôt et déclencher des outils internes. Ne classez la création d'un brouillon parmi les actions à faible risque que si votre environnement le traite réellement comme un support de revue. Si ses artefacts alimentent un registre de paquets ou un miroir d'artefacts, demandez également une approbation avant le téléversement.

Lier la version à un commit et les artefacts à la version

L'échec le plus courant d'une release ne vient pas d'un agent malveillant. Il s'agit d'une release dont la version, le tag, le commit source et le binaire proviennent de moments différents dans un dépôt qui évolue.

Un processus propre commence par choisir un SHA de commit immuable. Le build s'exécute à partir de ce SHA, pas d'un nom de branche. L'agent enregistre les condensés une fois le build terminé. C'est seulement ensuite qu'il crée un tag et un brouillon pointant tous deux vers le même SHA. Si votre processus exige un tag signé, l'identité de signature doit fonctionner en dehors du processus de l'agent, comme l'identifiant de publication.

Ne laissez pas l'agent utiliser une référence mutable comme main pour cibler une release publique. Un build peut commencer sur une révision, puis une autre fusion peut faire avancer la branche avant la création de la release. GitHub associera sans difficulté la release à la cible plus récente si votre code lui demande alors de résoudre main. Les notes peuvent ainsi décrire une révision et l'artefact en représenter une autre.

Vérifiez la relation avant la demande d'approbation. Une vérification locale simple peut arrêter le processus assez tôt :

git fetch --tags origin
git rev-parse "v2.4.0^{}"
git rev-parse HEAD
shasum -a 256 dist/widgets-v2.4.0.tar.gz

Les deux premiers identifiants d'objet doivent correspondre une fois le tag créé, et HEAD doit être le SHA examiné si le build a été réalisé dans cette copie de travail. La commande de somme de contrôle produit une ligne de cette forme :

b3e1f2...  dist/widgets-v2.4.0.tar.gz

Insérez ce condensé exact dans la fiche d'approbation. Ne demandez pas au reviewer de faire confiance à un nom de fichier. Un fichier nommé widgets-v2.4.0.tar.gz peut contenir un build de débogage, un ancien build ou un binaire destiné à une autre architecture.

La documentation GitHub Actions avertit que pull_request_target s'exécute dans le contexte du dépôt de base et peut exposer des permissions d'écriture ou des secrets au code non fiable d'une pull request s'il est utilisé sans précaution. La même leçon s'applique à un agent de release : ne construisez pas un artefact distribuable à partir de code non fiable dans une tâche capable de publier. Séparez la validation de code non fiable du build contrôlé qui reçoit l'autorité de release.

Le calcul de version a lui aussi besoin d'une règle fixe. Un agent peut proposer une version à partir de commits conventionnels ou de labels fusionnés, mais une proposition ne constitue pas une preuve. Un mainteneur doit décider comment les changements incompatibles, les changements annulés et les branches de release influencent la version. La gestion sémantique automatisée des versions échoue silencieusement lorsque les pratiques de commit du dépôt sont incohérentes.

Les notes de release générées ont besoin d'un éditeur humain

Un agent peut transformer les pull requests fusionnées en une première version crédible. Il ne peut pas savoir si une migration mérite un avertissement, si un contributeur souhaite être cité ou si un changement de comportement casse un cas d'utilisation qui n'apparaissait jamais dans le titre d'un commit.

Demandez-lui de produire des notes en sections qui rendent visibles les incertitudes. Placez d'abord les changements destinés aux utilisateurs, puis les corrections et enfin le travail interne. Ajoutez les références aux pull requests et la plage de commits utilisée. Signalez les affirmations provenant d'une inspection du code plutôt que de la description d'un mainteneur. Cela empêche un paragraphe fluide de masquer une supposition.

Je rejette l'instruction populaire « rédige des notes de release soignées à partir du journal Git ». Elle est populaire parce qu'elle produit immédiatement un document. Elle est incorrecte, car les messages de commit décrivent une intention d'implémentation, pas nécessairement le comportement livré. Un commit intitulé « corriger l'auth » peut réparer un élément de test, modifier un message d'erreur ou résoudre un défaut grave. La note de release doit décrire l'effet réel pour l'utilisateur.

Avant la publication, demandez au reviewer de répondre à quelques questions simples :

• Le commit cible contient-il tous les changements mentionnés ici ?
• Une pull request supprimée ou annulée est-elle restée dans la plage ?
• Les utilisateurs doivent-ils modifier leur configuration, leurs données, leurs permissions ou leurs clients ?
• Les formulations de sécurité doivent-elles être revues par les personnes qui ont enquêté sur le problème ?
• S'agit-il d'une pré-release, et GitHub doit-il la présenter comme la plus récente ?

Ne donnez pas à l'agent un avis de sécurité en lui demandant de le reformuler pour une release publique. Le reviewer doit décider du calendrier de divulgation, des versions concernées, des solutions de contournement et des remerciements. Un agent peut mettre en forme un texte approuvé, mais ne doit pas décider de ce qui devient public.

Gardez les notes et les artefacts de release liés au moment de la revue. Lorsqu'un reviewer lit « ajoute la prise en charge d'ARM », il doit voir l'artefact ARM dans le brouillon et son condensé dans la demande d'approbation. Cela permet de détecter un type de problème embarrassant que des revues séparées de la documentation et du build peuvent laisser passer.

La confirmation doit avoir lieu à la frontière irréversible

Une boîte de dialogue de confirmation qui apparaît après la publication ne fait que documenter le regret. Affichez la demande juste avant l'opération qui modifie l'état de distribution, et montrez exactement ce qui est autorisé.

L'approbateur doit disposer de suffisamment de contexte pour repérer une incohérence en quelques secondes : dépôt, titre du brouillon, SHA cible, noms et condensés des artefacts, statut de pré-release, choix de la release la plus récente et processus demandant l'approbation. Ne cachez pas le dépôt dans un panneau de détails replié. Une release publiée sur le mauvais dépôt peut être plus dommageable que des notes mal formulées.

Utilisez une confirmation distincte pour ces opérations :

• publier une release brouillon
• supprimer ou dépublier une release
• supprimer le tag d'une release
• remplacer un artefact de release existant
• faire passer une release de pré-release à stable ou la marquer comme la plus récente

Cette liste est volontairement courte. Demander une permission pour chaque lecture et chaque condensé d'artefact habitue les gens à approuver sans regarder. Exiger une décision à une frontière publique ou destructive préserve l'attention là où elle peut vraiment compter.

La confirmation doit être liée au condensé de la demande. Si l'agent modifie le brouillon, ajoute un artefact ou change make_latest après l'approbation, invalidez celle-ci et recommencez. Ne réutilisez pas un clic précédent sous prétexte que la chaîne de version correspond toujours.

L'autorisation par session de Sallyport peut identifier un nouveau processus d'agent avant toute action, et ses contrôles par appel peuvent exiger une approbation distincte pour l'utilisation d'un identifiant choisi. Cela correspond bien au travail de release : autoriser un processus d'agent examiné à préparer un brouillon, puis exiger une décision par appel lorsqu'il utilise l'identifiant de publication.

Ne confondez pas approbation et authentification. Une identité de signature de code ou une identité de workload CI indique quel processus a effectué la demande. La confirmation indique qu'une personne a accepté cette action sortante précise. Vous avez besoin des deux traces lorsqu'une release tourne mal.

Garder les identifiants hors du prompt et de l'environnement de l'agent

Un agent qui détient directement un jeton GitHub peut contourner votre interface d'approbation soigneusement conçue avec une commande curl, un fichier de workflow modifié ou un appel d'outil que vous avez oublié de restreindre. Les instructions du prompt ne peuvent pas combler cette faille.

Stockez l'identifiant dans un composant qui n'exécute que l'opération autorisée. L'agent envoie une demande structurée. Le composant valide le dépôt, le verbe, la référence cible et les contraintes d'artefact, obtient l'approbation nécessaire, injecte l'identifiant dans la requête sortante et renvoie le résultat. L'agent ne reçoit jamais le secret, même sous forme d'espace réservé masqué.

Sallyport conserve les secrets API et SSH dans son coffre-fort chiffré et exécute lui-même l'action HTTP ou SSH. Un agent compatible avec MCP n'a donc pas besoin de détenir l'identifiant. La barrière du coffre-fort refuse les actions lorsqu'il est verrouillé, ce qui est le comportement souhaitable sur une machine sans surveillance, plutôt qu'un jeton laissé dans l'environnement du shell.

Utilisez un identifiant distinct pour les releases. Limitez-le aux dépôts où il a une fonction, et retirez-lui les permissions d'administration des organisations, de gestion des webhooks, de modification des paramètres Actions ou d'écriture dans des dépôts sans rapport. Les GitHub Apps conviennent souvent mieux qu'un jeton personnel, car leur installation et leurs permissions ont un objectif plus étroit. Le choix exact dépend de la configuration de votre dépôt, mais un jeton partagé de mainteneur est une mauvaise identité de release.

Ne collez pas de jeton dans une instruction destinée à l'agent, un fichier .env ou un artefact CI. Le masquage ne résout pas le problème. Dès qu'un processus peut lire un secret, il peut souvent l'encoder dans un champ de sortie, un corps de release, un nom de fichier ou une demande adressée à un autre service. La prévention commence par ne jamais remettre le secret à ce processus.

Le rollback est une décision corrective, pas un bouton de suppression

Supprimer une release GitHub peut retirer une page, mais ne rappelle pas les archives téléchargées, les métadonnées mises en cache, les tags clonés, le code source miroir ni un déploiement automatisé déjà déclenché en aval. Un agent qui traite la suppression comme une annulation propre rendra un incident plus difficile à analyser.

Commencez une demande de rollback en classant le problème. Si l'artefact est défectueux mais sans danger, publiez une release corrigée avec une note claire et décidez s'il faut faire passer l'ancienne release en pré-release ou la retirer de la position la plus récente. Si l'artefact contient un secret, du code malveillant ou une vulnérabilité grave, arrêtez d'abord la distribution, révoquez les identifiants concernés, contactez les utilisateurs par les canaux que vous contrôlez et conservez les preuves nécessaires à l'enquête.

Une personne doit approuver les actions de rollback séparément de la publication, car leurs conséquences diffèrent. L'invite doit indiquer ce qui changera et ce qui restera visible. « Supprimer la release v2.4.0 » est trop vague. « Supprimer la fiche et les artefacts publics de la release v2.4.0 ; le tag v2.4.0 reste sur le SHA X ; les téléchargements existants ne peuvent pas être rappelés » explique à l'approbateur ce qu'il autorise réellement.

Ne laissez pas un agent supprimer un tag pour rendre ses notes de release plus propres. D'autres builds et utilisateurs peuvent dépendre de ces références. Si vous devez remplacer un tag, conservez l'ancien SHA dans le dossier de l'incident et communiquez le changement. Déplacer le tag d'une version publiée complique fortement les vérifications ultérieures.

Le choix le plus sûr par défaut est une version corrective. Elle crée une piste d'audit claire, permet aux outils en aval de distinguer l'artefact corrigé et évite de faire comme si la première release n'avait jamais existé. La suppression peut se justifier pour une publication accidentelle que personne n'a raisonnablement pu consommer, mais il s'agit d'une décision opérationnelle, pas d'une tâche de nettoyage automatique.

Une piste d'audit doit reconstituer l'action, pas le récit qui l'entoure

Quand quelqu'un demande qui a publié une version, « c'est l'agent » n'est pas une réponse. Vous devez identifier le processus de l'agent, la personne qui a approuvé l'action, l'autorité d'identification qui l'a exécutée, les valeurs de la demande et la réponse de GitHub.

Enregistrez un événement pour la session de l'agent et un événement pour chaque opération de release. L'enregistrement de session indique qui a lancé l'exécution et quand l'autorité a été retirée. L'enregistrement d'action indique quelle opération équivalente à un endpoint a eu lieu et avec quelles valeurs résolues. Gardez les secrets hors des deux.

Pour un événement de publication, capturez au minimum le dépôt, l'identifiant du brouillon, l'identifiant de la release, la version, le SHA cible, la référence source fournie par l'agent, les noms et condensés des artefacts, les indicateurs de release, le condensé des notes, l'heure de la décision, l'identité de l'approbateur, l'identité du processus, le code de résultat et l'identifiant de la réponse. Incluez les échecs. Une demande refusée prouve qu'une limite a fonctionné.

Sallyport projette les journaux de session et d'activité depuis un journal d'audit chiffré, chaîné par hachage et aveugle à l'écriture. Sa commande sp audit verify vérifie la chaîne hors ligne sur le texte chiffré, sans avoir besoin d'un secret du coffre-fort. Cette propriété est utile pour les preuves de release, car un auditeur peut vérifier si les enregistrements ont été modifiés sans recevoir les éléments d'identification.

Les journaux ne remplacent pas les contrôles. Un journal parfait qui enregistre la publication du mauvais paquet par un agent vous donne une autopsie propre et une mauvaise release. Le journal justifie sa présence lorsqu'il est associé à des actions limitées, des identifiants fixes et une approbation qui ne survit pas à la modification de la demande.

Une barrière de release doit refuser par défaut lorsque les faits divergent

La barrière de release doit rejeter l'ambiguïté au lieu de demander à l'approbateur de la compenser. Si la cible du brouillon diffère du SHA examiné, si le condensé d'un artefact diffère du manifeste de build, si le brouillon n'existe plus ou si la demande de release a changé depuis l'approbation, arrêtez le processus et créez une nouvelle demande.

Ce comportement peut sembler tatillon dans l'urgence d'une release. Il coûte moins cher que de déterminer si un tag a changé entre le build et la publication, ou si un agent a téléversé un fichier reconstruit après la vérification de l'ancien par le reviewer. Le travail de release bénéficie d'un peu de friction précisément à ce moment-là.

Testez la barrière avec des cas d'échec délibérés avant de lui confier une release stable. Demandez à l'agent de publier un brouillon avec un SHA différent. Téléversez un artefact dont les octets changent après le calcul de la somme de contrôle. Modifiez le titre d'un brouillon après approbation. Tentez de supprimer une release via l'interface de préparation. Chaque tentative doit échouer avec un enregistrement précis indiquant la raison à l'opérateur.

Puis établissez une règle opérationnelle facile à retenir : l'agent prépare une release candidate nommée, et une personne approuve exactement le changement public. Si votre automatisation actuelle ne peut pas indiquer à ce moment-là le dépôt, le commit, les artefacts et les conséquences d'un rollback, elle n'est pas prête à publier un logiciel sans surveillance.