PlugArr 0.6.0
Une installation ancienne se rattrape en une commande.
plugarr upgradePlugArr savait mettre a jour UN service. Il ne savait pas mettre a jour sa propre installation quand c'est lui qui change : quelqu'un qui a installe il y a six mois et telecharge le binaire du jour n'avait aucune commande a lancer.
Quatre etapes, dans cet ordre parce qu'il compte : migrer stack.yml, aligner les images sur le catalogue, regenerer docker-compose.yml et .env, rejouer le cablage. Le cablage passe en dernier — une etape ajoutee depuis peut dependre d'une image plus recente, l'inverse jamais.
On ne redescend jamais une version
Le tag deploye vit dans stack.yml et non dans le code, precisement pour qu'on puisse mettre Sonarr a jour sans attendre PlugArr, ou rester delibrement sur une version ancienne. Un upgrade qui ramenerait tout au catalogue annulerait ce choix sans le dire.
Il ne propose donc que ce qui avance, compare des nombres et non des chaines — 4.9.5 vient avant 4.16.1, ce que l'ordre alphabetique inverse — et affiche ce qu'il ecarte, avec sa raison :
Images a aligner sur le catalogue
+---------+-----------+-----------+
| Service | Installee | Catalogue |
+---------+-----------+-----------+
| Sonarr | 3.0.10 | 4.0.19 |
+---------+-----------+-----------+
ignore : radarr : 9.9.9 est deja plus recent que 6.3.0
ignore : prowlarr : maison et 2.5.2 ne se comparent pas
Un service saute en silence donne l'impression d'avoir tout aligne. --dry-run montre le plan sans rien ecrire.
stack.yml portait une version, et rien ne la lisait
Ce n'etait pas un detail d'hygiene. Pydantic ignore les champs qu'il ne connait pas : une version ancienne lisant un stack.yml recent en jetait une partie, et la premiere ecriture la detruisait — install, generate et la rotation d'un mot de passe reecrivent tous ce fichier.
Le cas arrive des qu'on revient en arriere : on essaie une nouvelle version, quelque chose deplait, on relance l'ancien binaire. Rien ne le signalait.
La perte a ete reproduite avant d'etre corrigee :
version lue : 2
champ futur garde ? : False
champ futur reecrit ?: False
PlugArr refuse desormais de lire un fichier plus recent que lui :
stack.yml is at version 2, this version of PlugArr reads up to 1.
Update PlugArr: going on would erase the settings it cannot read.
Les migrations tournent sur le dictionnaire brut, avant validation : apres pydantic, « absent » et « valeur par defaut » sont indistinguables, et une migration qui a besoin de cette difference ne peut plus la voir. Un test le verrouille en posant une migration qui ne peut reussir que dans le bon ordre.
Un point de la feuille de route qui ne demandait pas ce qu'il annoncait
« Rejouer les etapes de cablage qui ont change depuis la version installee » supposait de versionner chaque etape et de maintenir cette table a chaque modification — pour ne gagner que du temps d'execution, puisque wire est idempotent par construction. upgrade rejoue tout, et le dit.
plugarr.exe est attache a cette release. 860 tests, dont 23 nouveaux.