GitHub Actions : conserver les preuves au-delà du voyant vert

Dev
Vues 2

Le jour du déploiement, un voyant vert et un lien semblent suffisants. Des mois après, le lien peut manquer. Se souvenir du succès ne permet pas d’expliquer ce qui a été vérifié.

GitHub a annoncé le 1er octobre 2026 l’extension de la rétention Actions aux vérifications, exécutions et statuts. La méthode ci-dessous est une proposition d’exploitation, pas une obligation supplémentaire de GitHub.

Flux proposé : examiner l’exécution, garder un résumé, tester la lecture indépendante, vérifier la rétention. Schéma explicatif, pas une capture produit.
Flux proposé : examiner l’exécution, garder un résumé, tester la lecture indépendante, vérifier la rétention. Schéma explicatif, pas une capture produit.

Vérifier le périmètre

Les enregistrements expirés sont nettoyés automatiquement, y compris ceux des applications tierces. Les plafonds d’organisation et d’entreprise restent applicables ; le maximum public est 90 jours. Modifier le réglage ne restaure pas les données supprimées.

Repérez les releases dont la seule preuve est un lien de workflow. Résultats, approbations et empreintes peuvent être dispersés. Peut-on encore les relier si un lien disparaît ?

Un dossier par release

Gardez commit SHA, nom, ID et URL d’exécution, heure du résultat, résumé des tests et empreinte de l’artefact. Notez qui a approuvé quoi, sans copier de logs secrets. Définissez le but et les droits de lecture.

Un succès ne décrit pas le périmètre des tests. Précisez les tests partiels, le runtime et les fichiers de verrouillage. Référencez les fichiers au commit publié, pas leurs versions actuelles.

Tester l’export avant de l’automatiser

Choisissez un dépôt et une release. Lisez réglage et plafond, conservez le résumé utile et demandez à quelqu’un d’expliquer la release sans le lien initial.

L’export crée une autre frontière de sécurité. Fixez responsable, durée, droits de modification et retrait des secrets. Séparez preuves durables du déploiement et données temporaires de dépannage.

Une absence n’est pas forcément un échec

Contrôlez rétention, permissions et filtres avant de lire une réponse API vide comme un test jamais exécuté. Comparez ID et preuves indépendantes. C’est une hypothèse de diagnostic, pas un sentiment communautaire mesuré.

Ajoutez emplacement et échéance au modèle de release et relisez un dossier cette semaine. Une rétention plus longue ne garantit pas toute exigence d’audit. Visez une explication défendable, avec un périmètre clair.

Sources officielles