arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Update Article “2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build”

Browse source
This commit is contained in:
Quentin 2023-04-12 10:26:13 +00:00
parent 34d10e62e5
commit 3a86fda844
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md
View file

@ -12,6 +12,12 @@ Cet article est la suite de mon précédent article [Un registre statique avec G
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.