Version veröffentlichen

Mach aus einem getesteten Build eine Version. Diese Seite ist für Maintainer.

Achtung

Nur der Maintainer startet eine Veröffentlichung. Setze von dir aus keinen Tag, veröffentliche nichts und verschiebe keinen Image-Tag.

Bevor du beginnst

• Jede Prüfung unter Testen läuft durch, auch ein vollständiger End-to-End-Lauf und die langen Läufe und Fehlerläufe.
• CHANGELOG.md enthält die neue Version.
• Python 3 ist für die Release-Skripte installiert.

Eine Version vorbereiten

1. Schreibe releases/notes-<version>.toml, zum Beispiel releases/notes-1.0.0.toml. Siehe Datei mit den Versionshinweisen.

2. Prüfe sie:

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

   Du solltest keine Fehler sehen. Ein verbotenes Wort, ein Geviertstrich, ein Datum, Gerede über den Start oder ein wiederholtes Issue bei den Highlights beendet das Skript mit 1.

3. Erzeuge die Texte zur Version:

   python deploy/release/notes.py 1.0.0

   Du solltest 7 Dateien in releases/out/1.0.0/ finden.

4. Baue das Image und starte es mit einem frischen Konfigurationsordner:

   docker build --file deploy/Dockerfile .

   Du solltest den Assistenten für den ersten Start sehen.

5. Führe jede Prüfung unter Testen auf deinem Rechner aus. Tests laufen lokal, nicht auf GitHub.

6. Übergib die Version dem Maintainer. Der Maintainer pusht den Versions-Tag auf main, und das startet die Veröffentlichung.

Optionen

Namen für Version und Tag

Sache	Name
Git-Tag (vom Maintainer gepusht)	1.0.0 (reine Zahlen, kein v)
Image-Tag und version in den Hinweisen	1.0.0

Der Workflow startet nur bei einem Tag der Form X.Y.Z und bricht ab, wenn der Tag von der Datei VERSION abweicht.

Image-Tags

Jede Version pusht ihren Versions-Tag und :latest.

Eine Version zurückziehen

1. Pushe die nächste Version mit der Korrektur.
2. Markiere die fehlerhafte Version in der Update-Liste, damit Installationen sie nicht anbieten.
3. Behalte den Tag.

Wenn es nicht funktioniert

Symptom. notes.py --check endet mit 1. Ursache. Die Hinweisdatei verletzt eine Regel. Die Meldung nennt die Zeile. Lösung. Bearbeite die Hinweisdatei, nie die Dateien in releases/out, und führe das Skript noch einmal aus.

Symptom. Der Workflow bricht mit VERSION says ab. Ursache. Der Tag und die Datei VERSION weichen voneinander ab. Lösung. Korrigiere VERSION auf main und pushe den nächsten Versions-Tag.

Für Fortgeschrittene

Datei mit den Versionshinweisen

Jeder Text zu einer Version entsteht aus einer einzigen Datei. Bearbeite nie von Hand, was sie erzeugt.

Feld	Inhalt
version	Reines X.Y.Z
theme	Eine Zeile
images	Liste aus {registry, name}. Nur Docker Hub holyarrs/holyarrs
docs_url	Optional. Leer heißt: kein Link zur Doku
[[highlights]]	Genau 3, jedes mit line, issues und shot. Ihre Issues tauchen in keiner Gruppenzeile auf
[groups]	Zeilen je Ort. Neu ist der Standard. Andere beginnen mit Changed: , Fixed: oder Docs: . Jede endet mit ihrem Issue, etwa (#46). Ein Ort mit weniger als 3 Zeilen kommt unter Also new
Optional	[before_you_update] (breaking, manual_steps, backup, rollback), security, known_issues, credits, [stats]. Leere Teile werden ausgeblendet

Verwende einen GitHub-Login nur, wenn er bekannt ist: aus der Hinweisdatei oder aus releases/credits-map.json.

Reihenfolge im Text: theme, Highlights, Orte (Requests, Library, Downloads, Indexers, Accounts, Health, Setup, Install), Also new, Security, Known issues, Before you update, Image, Thanks, Statistikzeile.

Ausgabe in releases/out/<version>/	Verwendet für
changelog.md	Den Changelog-Eintrag
github.md	Den Text des GitHub-Release
update-notes.json	Die Hinweise, die die App anzeigt
reddit.txt	Den Reddit-Beitrag
discord-dm.txt, discord-announce.md	Discord. Jede bleibt unter 1.000 Zeichen
roadmap-card.json	Die Roadmap-Karte

notes.py kennt --file (eine andere Hinweisdatei), --map (eine andere Credits-Zuordnung), --out (einen anderen Ausgabeordner) und --date. --check warnt bei langen Zeilen und Beinahe-Wiederholungen.

Der Image-Workflow

Der Workflow HolyArrs - Release startet, wenn ein Versions-Tag gepusht wird. Er hat drei Schritte:

1. Das Image für linux/amd64, linux/arm64 und linux/arm/v7 bauen und pushen, mit dem Versions-Tag und latest.
2. Die Beschreibung auf Docker Hub aus README.md aktualisieren.
3. Das GitHub-Release mit dem Abschnitt dieser Version aus CHANGELOG.md veröffentlichen.

Update-Liste

Die App liest eine signierte Update-Liste. Jede Version fügt ihren Eintrag hinzu und signiert ihn. Der Signaturschlüssel kommt nie ins Repo. HolyArrs lehnt eine Liste ab, die es nicht prüfen kann.

Prüfe nach einer Veröffentlichung, ob das Versions-Label des Images zum Tag passt, und behalte am ersten Tag neue Issues im Auge:

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

Unraid-Testvorlage

deploy/release/nas-template.py schreibt eine Unraid-Benutzervorlage für genau ein Image. Das Skript lädt nichts herunter, installiert nichts und veröffentlicht nichts.

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

Ersetze <digest> und <pool>.

Option	Hinweise
--image	Der Manifest-Digest der Registry, keine Docker-Image-ID
--config	Ein Pool-Pfad. Das Werkzeug lehnt /mnt/user und /mnt/user0 ab
--movies, --tv, --music, --downloads	Optional. Getrennte Pfade sind getrennte Mounts, Importe kopieren dann
--port	Standard ist 6262
--allowed-hosts	Optional, Hostnamen durch Kommas getrennt
--output	Die XML-Datei, die geschrieben wird

Die Vorlage setzt PUID=99, PGID=100 und UMASK=022. Gib diesem Konto Schreibzugriff auf die Testmedien. Lege die Datei in /boot/config/plugins/dockerMan/templates-user/ ab und wähle sie unter Docker > Add Container > Template (Docker > Container hinzufügen > Vorlage).

Verwandte Seiten

• Testen
• Mitwirken
• Updates