---
layout: post
title: Gérer ses artefacts de build sans daemon
date: 2023-04-12T12:06:46.134+02:00
status: draft
sitemap: true
category: developpement
description: Comme vous pouvez le voir, on aime rester léger, et s'embarasser le
  moins possible de daemons.
---
Cet article est la suite de mon précédent article [Un registre statique avec Garage.](https://quentin.dufour.io/blog/2023-04-06/un-registre-statique-docker-avec-garage/)

Le premier point que j'ai regardé à la suite de la lecture de cet article était de savoir si on pouvait utiliser le module `ociTools` de NixOS pour générer des images directement comme je voulais via `nix build`. Il apparait que cet outil ne génère pas des images mais des conteneurs, deux représentations différentes, que je ne sais pas comment convertir en plus. Bref, ça ne nous avance pas, et si on veut faire mieux, je crains qu'il va simplement falloir écrire notre propre module NixOS, ce qui est trop couteux en temps pour le moment : on se contentera de cette innéficacité pour le moment…

Ensuite, il est bon de noter qu'on a déjà une logique pour lister les builds statics en place écrite en nixlang pour Garage dans un fichier nommé [build_index.nix](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/a2a35ac7a87fce2e38b8406f083e2350d4181b69/nix/build_index.nix). En gros elle va reprendre le concept de “tags” de Docker, et à l'aide d'une regex sur le tag, elle va classer les builds en 3 catégories : les builds de release, qui correspondent à un tag semver sans libellé (eg. 0.8.2), les builds extra, qui correspondent à un semver avec libellé (eg. 0.8.2+feat), et enfin tous les autres sont des builds de développement.

On peut alors imaginer un affichage différencié de ces buils : les builds release sont affichés par défaut, les autres sont cachés derrière un bouton. On peut aussi imaginer une gestion des cycles de vie différents : les builds release sont gardés pour toujours, les autres sont supprimés après un certain temps.

L'API S3 a un concept de Lifecycle Management et peut expirer des objets après un temps donné, c'est à dire les supprimer. Par exemple, on peut définir que les objets ayant leur préfix commençant par `logs/` seront supprimés après un an. Il serait tentant d'utiliser ce système pour notre système de gestion d'artefacts mais ça pose plusieurs problèmes : à ce jour, Garage n'implémente pas les Lifecycle Management, aussi le fonctionnement des images Docker fait qu'il est possible que plusieurs version d'une même image partagent un même blob, et enfin on est amené à générer un index qui liste toutes nos images, et qui se retrouvera donc à être invalide.