Les artefacts GitHub Issues donnent une place durable aux plans
Le code figure dans la pull request, mais son explication se perd parfois dans une ancienne discussion. Une enquête menée par un agent ailleurs peut alors être recommencée. Le 28 octobre, GitHub a présenté les artefacts d’issue en préversion publique pour rattacher ce contexte au travail concerné.
Une discussion et un document évolutif se complètent
Les artefacts accueillent Markdown, liens externes et HTML : analyse de cause, prototype ou discussion Slack et Teams. Sur github.com, leur création et leur modification conservent un historique. Ils se distinguent des artefacts GitHub Actions, qui sont des résultats d’exécution de workflows.
Prenons un paiement traité deux fois, un exemple fictif. Les commentaires gardent les observations nouvelles ; le plan décrit la clé utilisée lors des tentatives et les expériences restantes. La première image est une création pour cet article, pas une capture de GitHub. Séparer faits et hypothèses évite de transformer une intuition en exigence.
Joindre un fichier et maintenir le même contexte
gh issue artifact create reçoit un numéro ou une URL d’issue puis des fichiers ou liens. gh issue artifact create 42 retry-plan.md -R OWNER/REPO joindrait le fichier à l’issue 42. Ce sont des valeurs de démonstration ; l’exécution écrit dans l’issue. Nous ne l’avons pas exécutée.
Le nom peut venir du fichier ou de --name. --body-file lit le contenu d’un document, tandis que --attach permet des images et vidéos. gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO remplace le contenu. La seconde image montre la syntaxe, pas le résultat d’un envoi.
Garder le plan actuel et son évolution
edit modifie le nom ou le contenu, jamais le type. --restore-version enregistre un ancien nom et contenu comme nouvelle version ; view présente l’historique. Le plan courant peut ainsi rester lisible sans effacer son cheminement.
Dans notre exemple, le soupçon pourrait passer d’un délai dépassé au traitement de clés dupliquées. Actualiser le plan et relier un commentaire expliquant ce changement est une proposition éditoriale, pas un automatisme garanti. Un document joint ne remplace pas les preuves sur le code.
Le support HTML dépend de la surface
L’annonce décrit le passage entre aperçu HTML et source. Mais la création et la consultation de HTML dans GitHub App sont annoncées pour plus tard. Le rattachement automatique des résultats d’une session ne signifie donc pas un support HTML complet partout. La CLI reste également en préversion.
Le bénéfice tient à l’emplacement du contexte, pas au nombre de documents. Un plan existant et sa prochaine révision suffisent pour explorer ce fonctionnement. Les sources officielles précisent les possibilités actuelles.