Publier une version

Transformez un build testé en version publiée. Cette page s’adresse aux mainteneurs.

Attention

Seul le mainteneur lance une publication. Ne créez pas de tag, ne publiez rien et ne déplacez pas un tag d’image de votre propre initiative.

Avant de commencer

• Tous les contrôles de Tests passent, y compris une exécution complète de bout en bout et les tests longs et de panne.
• CHANGELOG.md contient la nouvelle version.
• Python 3 est installé pour les scripts de publication.

Préparer une version

1. Rédigez releases/notes-<version>.toml, par exemple releases/notes-1.0.0.toml. Voir Fichier des notes de version.

2. Vérifiez-le :

   python deploy/release/notes.py 1.0.0 --check

   Vous ne devriez voir aucune erreur. Un mot interdit, un tiret cadratin, une date, une annonce de lancement ou une issue répétée dans les points forts donne un code de sortie 1.

3. Générez les textes de la version :

   python deploy/release/notes.py 1.0.0

   Vous devriez trouver 7 fichiers dans releases/out/1.0.0/.

4. Construisez l’image et démarrez-la sur un dossier de configuration neuf :

   docker build --file deploy/Dockerfile .

   Vous devriez voir l’assistant de premier lancement.

5. Lancez tous les contrôles de Tests sur votre machine. Les tests tournent en local, pas sur GitHub.

6. Transmettez la version au mainteneur. Le mainteneur pousse le tag de version sur main, et cela lance la publication.

Options

Noms de version et de tag

Élément	Nom
Tag Git (poussé par le mainteneur)	1.0.0 (des chiffres seuls, sans v)
Tag d’image et version des notes	1.0.0

Le workflow démarre seulement pour un tag X.Y.Z et s’arrête quand le tag diffère du fichier VERSION.

Tags d’image

Chaque version pousse son tag de version et :latest.

Retirer une version

1. Poussez la version suivante avec la correction.
2. Marquez la mauvaise version dans la liste des mises à jour pour que les installations ne la proposent pas.
3. Gardez le tag.

Si ça ne fonctionne pas

Symptôme. notes.py --check se termine avec le code 1. Cause. Le fichier des notes enfreint une règle. Le message indique la ligne. Solution. Modifiez le fichier des notes, jamais les fichiers dans releases/out, et relancez.

Symptôme. Le workflow s’arrête avec VERSION says. Cause. Le tag et le fichier VERSION diffèrent. Solution. Corrigez VERSION sur main et poussez le tag de la version suivante.

Pour les experts

Fichier des notes de version

Tous les textes d’une version viennent d’un seul fichier. Ne modifiez jamais à la main ce qu’il génère.

Champ	Contenu
version	X.Y.Z seul
theme	Une ligne
images	Liste de {registry, name}. Seulement holyarrs/holyarrs sur Docker Hub
docs_url	Facultatif. Vide veut dire pas de lien Docs
[[highlights]]	Exactement 3, chacun avec line, issues et shot. Leurs issues n’apparaissent dans aucune ligne de groupe
[groups]	Des lignes par rubrique. New est la valeur par défaut. Les autres commencent par Changed: , Fixed: ou Docs: . Chacune se termine par son issue, comme (#46). Une rubrique de moins de 3 lignes passe sous Also new
Facultatif	[before_you_update] (breaking, manual_steps, backup, rollback), security, known_issues, credits, [stats]. Les parties vides sont masquées

Utilisez un identifiant GitHub seulement quand il est connu, dans le fichier des notes ou dans releases/credits-map.json.

Ordre du corps : theme, Highlights, les rubriques (Requests, Library, Downloads, Indexers, Accounts, Health, Setup, Install), Also new, Security, Known issues, Before you update, Image, Thanks, la ligne de statistiques.

Sortie dans releases/out/<version>/	Sert à
changelog.md	L’entrée du changelog
github.md	Le corps de la release GitHub
update-notes.json	Les notes que l’application affiche
reddit.txt	La publication Reddit
discord-dm.txt, discord-announce.md	Discord. Chacun reste sous 1 000 caractères
roadmap-card.json	La carte de la feuille de route

notes.py accepte --file (un autre fichier de notes), --map (une autre table des crédits), --out (un autre dossier de sortie) et --date. --check avertit en cas de lignes longues et de quasi-répétitions.

Le workflow de l'image

Le workflow HolyArrs - Release démarre quand un tag de version est poussé. Il comporte trois étapes :

1. Construire et pousser l’image pour linux/amd64, linux/arm64 et linux/arm/v7, avec le tag de version et latest.
2. Mettre à jour la description Docker Hub à partir de README.md.
3. Publier la release GitHub avec la section de CHANGELOG.md de cette version.

Liste des mises à jour

L’application lit une liste de mises à jour signée. Chaque version y ajoute son entrée et la signe. La clé de signature ne va jamais dans le dépôt. HolyArrs refuse une liste qu’il ne peut pas vérifier.

Après une publication, vérifiez que le label de version de l’image correspond au tag, et surveillez les nouvelles issues pendant le premier jour :

docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.version" }}' holyarrs

Modèle de test Unraid

deploy/release/nas-template.py écrit un modèle utilisateur Unraid pour une image précise. Il ne récupère, n’installe et ne publie rien.

python deploy/release/nas-template.py --image 'holyarrs/holyarrs@sha256:<digest>' --config '/mnt/<pool>/appdata/holyarrs-test' --movies /mnt/user/holyarrs-test-data/movies --downloads /mnt/user/holyarrs-test-data/downloads --port 6262 --output holyarrs-test.xml

Remplacez <digest> et <pool>.

Option	Remarques
--image	Le digest du manifeste dans le registre, pas un ID d’image Docker
--config	Un chemin de pool. L’outil refuse /mnt/user et /mnt/user0
--movies, --tv, --music, --downloads	Facultatif. Des chemins séparés sont des montages séparés, donc les imports copient
--port	6262 par défaut
--allowed-hosts	Facultatif, noms d’hôte séparés par des virgules
--output	Le fichier XML à écrire

Le modèle définit PUID=99, PGID=100 et UMASK=022. Donnez à ce compte l’accès en écriture aux médias de test. Placez le fichier dans /boot/config/plugins/dockerMan/templates-user/ et choisissez-le sous Docker > Add Container > Template (Docker > Ajouter un conteneur > Modèle).

Voir aussi

• Tests
• Contribuer
• Mises à jour