Wydawanie wersji

Zamień przetestowany build w wersję. Ta strona jest dla opiekunów.

Uwaga

Wersję rozpoczyna tylko opiekun. Nie taguj, nie publikuj i nie przesuwaj tagu image na własną rękę.

Zanim zaczniesz

• Każda kontrola ze strony Testy przechodzi, w tym pełne uruchomienie end-to-end oraz długie i awaryjne.
• CHANGELOG.md zawiera nową wersję.
• Python 3 jest zainstalowany do skryptów wydania.

Przygotuj wersję

1. Napisz releases/notes-<version>.toml, na przykład releases/notes-1.0.0.toml. Zobacz Plik notatek do wersji.

2. Sprawdź go:

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

   Nie powinno być żadnych błędów. Zakazane słowo, długi myślnik, data, zapowiedź premiery lub powtórzony problem w highlightach kończy się kodem 1.

3. Zbuduj teksty wersji:

   python deploy/release/notes.py 1.0.0

   W releases/out/1.0.0/ znajdziesz 7 plików.

4. Zbuduj image i uruchom go na świeżym folderze konfiguracji:

   docker build --file deploy/Dockerfile .

   Zobaczysz kreator pierwszego uruchomienia.

5. Uruchom na swoim komputerze każdą kontrolę ze strony Testy. Testy działają lokalnie, nie na GitHubie.

6. Przekaż wersję opiekunowi. Opiekun wypycha tag wersji na main i to uruchamia wydanie.

Opcje

Nazwy wersji i tagów

Co	Nazwa
Tag Gita (wypycha opiekun)	1.0.0 (same liczby, bez v)
Tag image i version w notatkach	1.0.0

Workflow startuje tylko dla tagu X.Y.Z i zatrzymuje się, gdy tag różni się od pliku VERSION.

Tagi image

Każda wersja wypycha swój tag wersji oraz :latest.

Wycofaj wersję

1. Wypchnij następną wersję z poprawką.
2. Oznacz złą wersję na liście aktualizacji, żeby instalacje jej nie proponowały.
3. Zostaw tag.

Jeśli to nie działa

Objaw. notes.py --check kończy się kodem 1. Przyczyna. Plik notatek łamie regułę. Komunikat podaje linię. Rozwiązanie. Edytuj plik notatek, nigdy pliki w releases/out, i uruchom ponownie.

Objaw. Workflow zatrzymuje się z komunikatem VERSION says. Przyczyna. Tag i plik VERSION różnią się. Rozwiązanie. Popraw VERSION na main i wypchnij tag następnej wersji.

Dla zaawansowanych

Plik notatek do wersji

Każdy tekst wersji powstaje z jednego pliku. Nigdy nie edytuj ręcznie tego, co zbuduje.

Pole	Zawartość
version	Samo X.Y.Z
theme	Jedna linia
images	Lista {registry, name}. Tylko Docker Hub holyarrs/holyarrs
docs_url	Opcjonalne. Puste oznacza brak linku do dokumentacji
[[highlights]]	Dokładnie 3, każdy z line, issues i shot. Ich zgłoszenia nie pojawiają się w żadnej linii grupy
[groups]	Linie dla każdego miejsca. Domyślnie jest New. Pozostałe zaczynają się od Changed: , Fixed: lub Docs: . Każda kończy się swoim zgłoszeniem, na przykład (#46). Miejsce z mniej niż 3 liniami trafia pod Also new
Opcjonalne	[before_you_update] (breaking, manual_steps, backup, rollback), security, known_issues, credits, [stats]. Puste części są ukryte

Login z GitHuba wpisuj tylko wtedy, gdy jest znany, w pliku notatek lub w releases/credits-map.json.

Kolejność treści: theme, Highlights, miejsca (Requests, Library, Downloads, Indexers, Accounts, Health, Setup, Install), Also new, Security, Known issues, Before you update, Image, Thanks, linia ze statystykami.

Wynik w releases/out/<version>/	Do czego służy
changelog.md	Wpis do changeloga
github.md	Treść wydania na GitHubie
update-notes.json	Notatki pokazywane w aplikacji
reddit.txt	Post na Reddicie
discord-dm.txt, discord-announce.md	Discord. Każdy ma poniżej 1000 znaków
roadmap-card.json	Karta planu rozwoju

notes.py przyjmuje --file (inny plik notatek), --map (inną mapę podziękowań), --out (inny folder wyjściowy) i --date. --check ostrzega o długich liniach i prawie powtórzeniach.

Workflow image

Workflow HolyArrs - Release startuje, gdy zostanie wypchnięty tag wersji. Ma trzy kroki:

1. Zbuduj i wypchnij image dla linux/amd64, linux/arm64 i linux/arm/v7, z tagiem wersji i latest.
2. Zaktualizuj opis na Docker Hub z README.md.
3. Opublikuj wydanie na GitHubie z sekcją CHANGELOG.md dla tej wersji.

Lista aktualizacji

Aplikacja czyta podpisaną listę aktualizacji. Każda wersja dodaje swój wpis i go podpisuje. Klucz podpisu nigdy nie trafia do repo. HolyArrs odrzuca listę, której nie może zweryfikować.

Po wydaniu sprawdź, czy etykieta wersji w image zgadza się z tagiem, i przez pierwszy dzień obserwuj nowe zgłoszenia:

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

Testowy szablon dla Unraida

deploy/release/nas-template.py zapisuje szablon użytkownika Unraida dla jednego konkretnego image. Niczego nie pobiera, nie instaluje ani nie publikuje.

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

Zamień <digest> i <pool>.

Flaga	Uwagi
--image	Digest manifestu z rejestru, nie ID image Dockera
--config	Ścieżka puli. Narzędzie odrzuca /mnt/user i /mnt/user0
--movies, --tv, --music, --downloads	Opcjonalne. Osobne ścieżki to osobne montowania, więc import kopiuje
--port	Domyślnie 6262
--allowed-hosts	Opcjonalne, nazwy hostów oddzielone przecinkami
--output	Plik XML do zapisania

Szablon ustawia PUID=99, PGID=100 i UMASK=022. Daj temu kontu dostęp do zapisu w testowych multimediach. Wrzuć plik do /boot/config/plugins/dockerMan/templates-user/ i wybierz go w Docker > Add Container > Template (Docker > dodaj kontener > szablon).

Powiązane strony

• Testy
• Współtworzenie
• Aktualizacje