Pubblicare una versione

Trasforma una build testata in una versione. Questa pagina è per chi mantiene il progetto.

Attenzione

Solo chi mantiene il progetto avvia una versione. Non creare tag, non pubblicare e non spostare il tag di un’immagine di tua iniziativa.

Prima di iniziare

• Ogni controllo in Test passa, compresa un’esecuzione end-to-end completa e le prove lunghe e sui guasti.
• CHANGELOG.md contiene la nuova versione.
• Python 3 è installato per gli script di rilascio.

Prepara una versione

1. Scrivi releases/notes-<version>.toml, per esempio releases/notes-1.0.0.toml. Vedi File delle note di rilascio.

2. Controllalo:

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

   Non dovresti vedere errori. Una parola vietata, una lineetta em, una data, un tono da lancio o un’issue ripetuta tra gli highlight fa terminare lo script con codice 1.

3. Genera i testi della versione:

   python deploy/release/notes.py 1.0.0

   Dovresti trovare 7 file in releases/out/1.0.0/.

4. Compila l’immagine e avviala su una cartella di configurazione nuova:

   docker build --file deploy/Dockerfile .

   Dovresti vedere la procedura guidata del primo avvio.

5. Esegui sul tuo computer ogni controllo in Test. I test girano in locale, non su GitHub.

6. Passa la versione a chi mantiene il progetto. Chi mantiene il progetto invia il tag della versione su main, e questo avvia il rilascio.

Scelte

Nomi della versione e del tag

Cosa	Nome
Tag Git (inviato da chi mantiene il progetto)	1.0.0 (solo numeri, senza v)
Tag dell’immagine e version delle note	1.0.0

Il workflow parte solo per un tag X.Y.Z e si ferma quando il tag è diverso dal file VERSION.

Tag delle immagini

Ogni versione invia il tag della sua versione e :latest.

Ritira una versione

1. Invia la versione successiva con la correzione.
2. Segna la versione difettosa nell’elenco degli aggiornamenti, così le installazioni non la propongono.
3. Conserva il tag.

Se non funziona

Sintomo. notes.py --check termina con codice 1. Causa. Il file delle note infrange una regola. Il messaggio indica la riga. Soluzione. Modifica il file delle note, mai i file in releases/out, ed esegui di nuovo.

Sintomo. Il workflow si ferma con VERSION says. Causa. Il tag e il file VERSION sono diversi. Soluzione. Correggi VERSION su main e invia il tag della versione successiva.

Per esperti

File delle note di rilascio

Ogni testo della versione nasce da un solo file. Non modificare mai a mano ciò che genera.

Campo	Contenuto
version	X.Y.Z semplice
theme	Una riga
images	Elenco di {registry, name}. Solo Docker Hub holyarrs/holyarrs
docs_url	Facoltativo. Vuoto significa nessun link ai documenti
[[highlights]]	Esattamente 3, ciascuno con line, issues e shot. Le loro issue non compaiono in nessuna riga di gruppo
[groups]	Righe per sezione. New è il predefinito. Le altre iniziano con Changed: , Fixed: o Docs: . Ognuna termina con la sua issue, per esempio (#46). Una sezione con meno di 3 righe va sotto Also new
Facoltativi	[before_you_update] (breaking, manual_steps, backup, rollback), security, known_issues, credits, [stats]. Le parti vuote vengono nascoste

Usa un nome utente GitHub solo quando è noto, nel file delle note o in releases/credits-map.json.

Ordine del testo: tema, Highlights, sezioni (Requests, Library, Downloads, Indexers, Accounts, Health, Setup, Install), Also new, Security, Known issues, Before you update, Image, Thanks, riga delle statistiche.

Output in releases/out/<version>/	Serve per
changelog.md	La voce del changelog
github.md	Il testo della release su GitHub
update-notes.json	Le note che mostra l’app
reddit.txt	Il post su Reddit
discord-dm.txt, discord-announce.md	Discord. Ognuno resta sotto i 1.000 caratteri
roadmap-card.json	La scheda della roadmap

notes.py accetta --file (un altro file di note), --map (un’altra mappa dei crediti), --out (un’altra cartella di output) e --date. --check avvisa sulle righe lunghe e sulle quasi ripetizioni.

Il workflow dell'immagine

Il workflow HolyArrs - Release parte quando viene inviato un tag di versione. Ha tre passaggi:

1. Compila e invia l’immagine per linux/amd64, linux/arm64 e linux/arm/v7, con il tag della versione e latest.
2. Aggiorna la descrizione su Docker Hub da README.md.
3. Pubblica la release su GitHub con la sezione di CHANGELOG.md di questa versione.

Elenco degli aggiornamenti

L’app legge un elenco degli aggiornamenti firmato. Ogni versione aggiunge la sua voce e la firma. La chiave di firma non finisce mai nel repository. HolyArrs rifiuta un elenco che non riesce a verificare.

Dopo una versione, controlla che l’etichetta di versione dell’immagine corrisponda al tag e tieni d’occhio le nuove issue per il primo giorno:

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

Modello di prova per Unraid

deploy/release/nas-template.py scrive un modello utente di Unraid per una sola immagine precisa. Non scarica, non installa e non pubblica nulla.

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

Sostituisci <digest> e <pool>.

Opzione	Note
--image	Il digest del manifest del registro, non un ID immagine Docker
--config	Un percorso del pool. Lo strumento rifiuta /mnt/user e /mnt/user0
--movies, --tv, --music, --downloads	Facoltativi. Percorsi separati sono mount separati, quindi le importazioni copiano
--port	Per impostazione predefinita 6262
--allowed-hosts	Facoltativo, nomi host separati da virgole
--output	Il file XML da scrivere

Il modello imposta PUID=99, PGID=100 e UMASK=022. Dai a quell’account il permesso di scrittura sui media di prova. Metti il file in /boot/config/plugins/dockerMan/templates-user/ e sceglilo in Docker > Add Container > Template (aggiungi container > modello).

Correlati

• Test
• Contribuire
• Aggiornamenti