Artefacts de run

Les artefacts de run gardent ce qu’un run a produit et que vous voulez retrouver : un binaire, un paquet, un rapport de tests, une documentation. Ils ont leur propre accès et leur propre durée de conservation, une adresse stable pour les scripts, et une place dans la page du run. Les étapes se passent les données sous forme de flux entre moteurs ; les artefacts servent à ce qui survit au run.

Un artefact est un fichier, ou une arborescence de 1 000 fichiers au plus, nommé au sein de son run. Un artefact qui a un point d’entrée est un rendu, affiché dans la page du run.

Envoyer des artefacts

Les programmes envoient des artefacts avec la partie work/artifact de Mélodium, et les étapes du package cicd prennent des artefacts à envoyer une fois que leurs commandes réussissent. Un artefact est un répertoire, dont les fichiers gardent leur chemin, ou un seul fichier, pris dans n’importe quel système de fichiers que le programme atteint : celui du moteur, ou le volume d’un exécuteur. Le programme donne à l’artefact son nom, son accès, sa conservation et son verrou, et son point d’entrée quand c’est un rendu.

Chaque fichier est lu, vérifié et envoyé vers le stockage en même temps, en plusieurs parties pour les gros fichiers, avec son SHA-256 : un artefact n’a besoin d’aucune place sur le disque en plus de ses propres fichiers, et des fichiers de taille inconnue conviennent. Un fichier qui contient une valeur révélée d’un secret par le moteur, dans son contenu ou son chemin, est refusé, et l’artefact avec lui. L’artefact apparaît une fois que tous ses fichiers sont dans le stockage ; jusque-là, personne ne le voit.

Les programmes récupèrent aussi les artefacts d’autres runs de l’organisation, chaque fichier étant vérifié par son SHA-256 avant d’être écrit, et un fichier qui diffère étant supprimé.

Les noms sont faits de lettres, chiffres, _, . et -, et sont uniques dans un run. Un run envoie des artefacts quand il appartient à un groupe d’exécution, comme tout run lancé avec --api-report et chaque étape qu’il distribue.

Accès, conservation et verrou

• L’accès est propre à l’artefact, quel que soit l’accès de son run. organization le réserve aux membres de l’organisation et à ses runs ; public l’ouvre à tout le monde. Un run privé peut partager un artefact public, et un run public peut réserver un artefact à l’organisation.
• La conservation est, par défaut, celle de votre plan, avec trois mois au moins : 120 jours sans plan, cinq ans en Basic et sur le plan open source, dix ans en Pro. Un programme peut demander n’importe quel nombre de jours, ou aucune date de fin. Une longue conservation compte dans le stockage géré de votre plan, où que l’artefact soit gardé.
• Le verrou garde un artefact définitivement : personne ne le supprime, administrateurs compris, et son expiration ne peut qu’être repoussée. Un artefact verrouillé expire quand même à sa date, s’il en a une, et son accès peut toujours changer. Un verrou ne se retire jamais.

L’historique d’un artefact liste son envoi et chaque changement d’accès, d’expiration ou de verrou, sa suppression ou son expiration, avec le membre ou le run à l’origine de chaque changement. Il reste après la disparition de l’artefact.

Adresses stables

Chaque artefact a une adresse qui reste la même tant qu’il est conservé, public ou non :

• https://api.melodium.tech/0.1/artifacts/<run>/<nom> mène au fichier lui-même pour un artefact d’un seul fichier. Pour plusieurs fichiers, elle répond en JSON avec l’artefact et un lien de téléchargement par fichier, valable une heure.
• https://api.melodium.tech/0.1/artifacts/<run>/<nom>/<chemin> mène à un fichier.

# Un artefact public
curl -L -o app https://api.melodium.tech/0.1/artifacts/<run>/app
 
# N'importe quel artefact, avec un jeton d'artefacts
curl -L -o app -H "Authorization: Bearer $ARTIFACT_TOKEN" https://api.melodium.tech/0.1/artifacts/<run>/app

L’adresse redirige vers le stockage, qui sert les octets, plages comprises ; l’ETag est le SHA-256 du fichier. Un artefact que vous n’avez pas le droit de lire répond 404, comme un artefact qui n’existe pas, pour qu’un artefact privé ne soit jamais confirmé. Une fois expiré ou supprimé, il répond 410.

Tout le monde lit un artefact public. Les autres sont lus par les membres de l’organisation, par les runs de l’organisation avec le jeton de leur machine, et par les jetons d’artefacts. Dans un navigateur, les images, les fichiers PDF, le texte brut, le JSON, l’audio et la vidéo s’ouvrent sur place ; tous les autres fichiers se téléchargent, HTML, SVG et scripts compris. Les rendus tournent plutôt sur un domaine à part.

Jetons d’artefacts

Un script de déploiement ou un index de paquets télécharge les artefacts avec un jeton d’artefacts, cad_a_... (voir Clés), plutôt qu’avec la session d’un membre. Les administrateurs les créent sur la page Clés, sous Ressources, où ils sont listés ; le bouton Obtenir un Jeton d’Artefacts de la page Stockage y mène. Un jeton lit tous les artefacts de l’organisation, ou seulement ceux d’un run, ou ceux dont le nom commence par un préfixe, jusqu’à une date ou jusqu’à leur révocation. Le jeton est affiché une fois. Il lit les adresses stables et les listes d’artefacts de ce qu’il couvre, et rien d’autre. Sa dernière utilisation est notée, et un jeton trouvé dans un lieu public est révoqué aussitôt.

Dans le tableau de bord

La page d’un run liste ses artefacts, avec leurs fichiers, leur taille, leur accès et leur expiration ; la page d’un groupe liste ceux de tous ses runs ; les pages publiques des runs listent les artefacts publics. La page Stockage liste tous les artefacts de l’organisation, du plus récent au plus ancien, avec leur nombre et leur taille totale ; elle les filtre par le début de leur nom, par accès, par verrouillage, et montre les artefacts supprimés et expirés sur demande. Chacun se télécharge en un clic : un fichier seul directement, plusieurs fichiers dans un zip que votre navigateur construit depuis le stockage, écrit directement sur le disque quand le navigateur le permet. Ouvrir un artefact montre ses fichiers, son adresse et celle de chaque fichier, les réglages de son accès et de son expiration, son historique, et l’emplacement de ses copies quand vous avez votre propre stockage.

Le manifeste

Un artefact est gardé à côté des rapports de son run, dans son propre dossier : reporting-<groupe>/<run>/artifacts/<nom>/<id de l'artefact>/, ses fichiers sous files/ à leur chemin, et un manifest.json. Le manifeste est écrit quand l’artefact est complet, et réécrit quand son accès, son expiration ou son verrou changent. Il décrit l’artefact (nom, point d’entrée, accès, expiration, verrou, ainsi que les dates, les tags, la version de Mélodium et le point d’entrée de son run) et chaque fichier, avec son chemin, sa clé dans le bucket, sa taille, son SHA-256 et son type de média. Un bucket qui vous appartient décrit ainsi lui-même ce qu’il contient, aussi longtemps que vous le gardez.

Pour aller plus loin

• Rendus : afficher un artefact dans la page du run.
• Stockage : où sont gardés les artefacts, et les copies entre buckets.
• Caches.
• La partie work/artifact de la référence Mélodium.