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-13 08:28:13 +00:00
parent dec2168b6b
commit 30ca120b19
1 changed files with 32 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -207,3 +207,35 @@ _Note 1 : on voit qu'une prerelease dont le tag a été raté est passé dans
_Note 2 : se pose la question de comment ont trie à l'intérieur d'une catégorie, aujourd'hui on reprend l'ordre de la liste initiale. Dans le cadre de Docker, il apparait que c'est l'ordre alphabétique qui est choisi. Ce qui marche à peu près pour le semver mais pas du tout pour les commits. Nous on voudrait simplement trier par date mais on a pas accès à cette information dans la liste des tags. Par contre, on peut simplement dire que dans notre implémentation, le générateur qui se charge de construire la liste, ordonne du plus récent au moins récent les tags, tout simplement !_
## Spécifier notre registre statique
Aujourd'hui une URL de téléchargement de Garage ressemble à ça :
```
https://garagehq.deuxfleurs.fr/_releases/v0.8.2/x86_64-unknown-linux-musl/garage
```
Si on décompose ça veut dire :
```
<host>/_releases/<tag>/<llvm target triple>/<binary>
```
_On peut en apprendre plus sur les target triple de LLVM dans ce billet de blog :_ [What’s an LLVM target triple?](https://www.flother.is/til/llvm-target-triple/)
Déjà le préfix de chemin `_releases` ne fait plus sens dans notre cas : il était là pour ne pas rentrer en conflit avec le géérateur de site statique (d'où le underscore), et parce que les releases étaient partagées avec le site web. Dans `download.deuxfleurs.org` on ne va stocker que des releases, donc ça n'a plus grand sens.
Pour autant, garder un préfixe, ça a du sens, parce qu'il va décrire comment la hiérarchie sous-jacente va se constituer, ainsi que de permettre de migrer plus tard vers de nouvelles hiérarchies.
Se pose aussi la question du triple LLVM, c'est ce qui est utilisé par Rust, mais ce n'est jamais ce qu'on affiche, à la place on utilise la notation du projet Go, notation aussi utilisée par le projet Docker. Au passage, je la trouve plus simple à comprendre car elle ne contient qu'une combinaison d'un OS et d'une architecture. Mais se pose aussi la question de ce qui se passe si on prévoit de supporter une combinaison qui n'existe pas pour Go. Et en même temps, la notation LLVM est complexe à lire et contient des informations que je considère comme des détails internes : ainsi notre choix d'utiliser musl est lié à notre choix de compiler en interne, qui est lié à l'idée qu'une fois l'OS et l'architecture identifiée, on veut que Garage tourne. Bref, tout ça me fait penser qu'on devrait adopter la notation de Go dans une démarche de penser à l'utilisateur final.
Donc on pourrait avoir ces URL :
```
<host>/df-dist-v1/<name>/<tag>/<go_os>/<go_arch>/<binary>
<host>/df-dist-v1/<name>/<tag>/manifest
<host>/df-dist-v1/<name>/list
```