« Quota de stockage d’artefacts dépassé » : ce message, apparu dans les journaux d’une chaîne d’intégration continue GitHub Actions après seulement trois semaines d’utilisation intensive, a révélé un problème que personne n’avait anticipé — chaque artefact de build, y compris ceux issus de branches de test abandonnées depuis longtemps, restait stocké indéfiniment par défaut selon la configuration héritée du modèle de pipeline initial.
Un artefact de build — l’archive compilée d’un thème, les rapports de tests, les captures d’écran d’un test visuel — sert principalement dans les minutes ou les heures qui suivent sa génération, le temps de déboguer un échec ou de récupérer un livrable. Passé ce délai utile, la plupart des artefacts n’ont plus de valeur immédiate, mais continuent d’occuper un espace de stockage facturé au-delà d’un quota gratuit.
Le comportement par défaut, coûteux sans qu’on s’en rende compte
L’action actions/upload-artifact, utilisée par la grande majorité des chaînes de construction GitHub Actions pour conserver un artefact entre deux étapes ou après la fin d’un déroulement, applique par défaut une durée de rétention fixée au niveau du dépôt ou de l’organisation, souvent réglée à quatre-vingt-dix jours faute de configuration explicite. Sur un projet avec plusieurs déroulements quotidiens, chacun produisant plusieurs artefacts, ce délai par défaut suffit à accumuler un volume considérable avant que le quota gratuit ne soit atteint.
Une politique de rétention différenciée par branche
La solution retenue ne consiste pas à réduire uniformément la durée de rétention pour tous les artefacts, ce qui risquerait de perdre des artefacts encore utiles issus de la branche principale. Elle différencie la durée selon l’origine du déroulement :
- name: Téléverser l'artefact de build
uses: actions/upload-artifact@v4
with:
name: build-theme
path: dist/
retention-days: ${{ github.ref == 'refs/heads/main' && 30 || 3 }}
Cette expression conditionnelle fixe une rétention de trente jours pour les artefacts issus de la branche principale, jugés plus susceptibles d’être consultés a posteriori lors d’un incident de production, et de seulement trois jours pour tous les autres déroulements, notamment ceux des branches de fonctionnalité en cours de développement dont l’intérêt disparaît rapidement une fois la branche fusionnée ou abandonnée.
Résultats mesurés après application
Un mois après la mise en place de cette politique, l’occupation totale du quota de stockage d’artefacts est passée d’un dépassement systématique à une occupation stable représentant environ un tiers du quota disponible, sans qu’aucun artefact utile n’ait manqué lors des interventions de débogage menées sur cette période. Le nombre d’artefacts conservés simultanément a diminué d’environ soixante-dix pour cent par rapport à la politique par défaut.
Ce qui mérite une rétention plus longue
Tous les artefacts ne suivent pas la même logique de valeur dans le temps. Un rapport de couverture de code ou un journal de test peut perdre son intérêt en quelques jours, tandis qu’une archive de build destinée à un déploiement en production mérite d’être conservée au moins jusqu’à la publication de la version suivante, pour permettre un retour arrière rapide sans reconstruction. La politique de rétention gagne donc à être définie artefact par artefact plutôt qu’uniformément pour l’ensemble d’une chaîne de construction.
- Artefacts de débogage (journaux, captures d’écran de tests) : rétention courte, trois à cinq jours
- Archive de build de la branche principale : rétention moyenne, correspondant au cycle de publication
- Artefact explicitement destiné à archivage long terme : téléversement vers un stockage externe dédié plutôt que le stockage d’artefacts de la chaîne d’intégration continue
Ce que cette politique ne remplace pas
Cette rétention sélective réduit la pression sur le quota de stockage d’artefacts ; elle ne remplace pas une réflexion sur le cache des dépendances installées pendant la construction, qui répond à un besoin différent — accélérer la construction elle-même plutôt que gérer le stockage de ses résultats — et mérite un traitement séparé et déjà documenté par ailleurs.
En résumé
Une politique de rétention différenciée, appliquée en une seule ligne conditionnelle par étape de téléversement d’artefact, suffit à transformer un quota de stockage systématiquement dépassé en une occupation stable et prévisible. La clé ne réside pas dans une réduction uniforme et aveugle, mais dans une distinction claire entre ce qui mérite d’être conservé longtemps et ce qui n’a de valeur que dans les heures suivant sa création.
