L'agent annonce désormais ce que sa machine peut encaisser

v0.32.0-beta

L'agent annonce désormais ce que sa machine peut encaisser. À la connexion, il mesure son nombre de cœurs, sa mémoire, l'espace disque total, son architecture (amd64 ou arm64) et la présence de Docker et de buildx, puis transmet ces informations au hub. C'est ce qui permet à Pier de confier un build à cette machine plutôt qu'à une autre, en connaissance de cause. Les rôles du nœud, eux, ne remontent jamais depuis l'agent : ils restent décidés côté hub.
Des plafonds de ressources, calculés pour votre machine. L'agent en déduit des limites recommandées : un cœur laissé libre pour le système, 60 % de la mémoire au maximum, et une réserve d'espace disque d'au moins 10 Go (ou 10 % du disque si c'est plus). Il les annonce sans se les appliquer de lui-même : tant que personne ne lui a demandé de plafond, il conserve exactement le comportement de build des versions précédentes. Dès qu'un plafond est en vigueur, un build qui passerait sous la réserve disque est refusé proprement, avec un message qui indique l'espace restant et la réserve atteinte, plutôt que de remplir le disque et d'emporter avec lui ce qui tourne à côté. C'est ce qui rend raisonnable d'installer l'agent sur un PC ou un NAS partagé avec d'autres usages.
Le hub peut ajuster ces plafonds à distance. Un administrateur plateforme modifie les limites d'un nœud depuis la topologie ; l'agent les reçoit, les applique aux builds et les conserve pour ses redémarrages suivants. Une réinitialisation redonne la main aux valeurs calculées par la machine. Un changement de plafond qui arrive pendant un build attend la fin de celui-ci : le build en cours n'est jamais interrompu.
L'identifiant de registre ne reste plus sur la machine après un build. L'authentification auprès du registre d'images est désormais confinée à un dossier temporaire propre à chaque build, effacé à la fin. Auparavant le jeton restait inscrit dans la configuration Docker de l'hôte, sans expiration, y compris après le retrait du nœud. Deux builds simultanés ne se marchent plus dessus non plus.
Nouvelles options d'installation pour fixer ces plafonds dès la mise en place, sans passer par le hub : --max-cpus, --max-mem (en Mo), --reserve-disk-gb et --max-concurrent-jobs. Omises, l'agent n'applique aucun plafond de lui-même et attend ceux du hub.