From 4ac5cfd5e811218a5b5381437ff6366365dcb544 Mon Sep 17 00:00:00 2001 From: Quentin Date: Wed, 12 Apr 2023 14:11:08 +0000 Subject: [PATCH] =?UTF-8?q?Update=20Article=20=E2=80=9C2023-04-12-un-outil?= =?UTF-8?q?-sans-daemon-pour-g=C3=A9rer-ses-artefacts-de-build=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...aemon-pour-gérer-ses-artefacts-de-build.md | 32 +++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md b/_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md index 95022d3..d9ed4ca 100644 --- a/_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md +++ b/_posts/2023-04-12-un-outil-sans-daemon-pour-gérer-ses-artefacts-de-build.md @@ -20,6 +20,34 @@ L'API S3 a un concept de Lifecycle Management et peut expirer des objets après Docker, et donc l'Open Container Initiative, a une spécification pour définir un index de tags pour une image donnée. Tout ça est décrit dans la spec “distribution” dans la section [Content Discovery](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-discovery). Implémenter cette spécification pour lister nos tags améliorerait l'intéropérabilité de notre registre avec les autres clients OCI. _Même si on ne pourra pas tout implémenter, par exemple le paging définit par la spec ne pourra pas être codé._ -La spécification OCI pourrait nous servir d'inspiration pour notre dépôt de fichiers statiques. Tout ça dans l'espoir de faciliter l'écriture du code et de limiter le nombre de conceps à manipuler. Mais cela veut aussi dire qu'on extrait de l'index la charge de catégoriser les tags (release, extra, development). Ça deviendrait alors une convention pour celles et ceux qui intéragissent avec notre futur outil. +La spécification OCI pourrait nous servir d'inspiration pour notre dépôt de fichiers statiques. Tout ça dans l'espoir de faciliter l'écriture du code et de limiter le nombre de conceps à manipuler. Mais cela veut aussi dire qu'on extrait de l'index la charge de catégoriser les tags (release, extra, development). Ça deviendrait alors une convention pour celles et ceux qui intéragissent avec notre futur outil. Et ça veut dire que si on ne garbage collect pas les nightly builds, cet index peut devenir bien grand… + +À travers ce panorama, je pense qu'on arrive au noeud du problème à traiter aujourd'hui : la spécification de notre index pour les fichiers statiques, la spécification de la convention à suivre pour les tags, et comment créer un outil qui facilite au maximum cette gestion. + +## Créer un index pour un registre OCI + +On peut regarder un peu ce que donne le registre Docker pour Garage : + +```json +{ + "name": "dxflrs/garage", + "tags": [ + "02e8eb167efa1f08d69fe7f8e6192cde726c45aa", + "", + "fcc5033466e58e3beec05ee7748d33522b6b32b0", + "v0.7.3", + "v0.8-rc2", + "v0.8.0", + "v0.8.0-beta1", + "v0.8.0-beta2", + "v0.8.0-rc1", + "v0.8.0-rc2", + "v0.8.1", + "v0.8.2" + ] +} +``` + + + -À travers ce panorama, je pense qu'on arrive au noeud du problème à traiter aujourd'hui : la spécification de notre index pour les fichiers statiques, la spécification de la convention à suivre pour les tags,