Actualitzacions

HolyArrs t’avisa quan hi ha una versió nova i mai no la instal·la. Tu baixes la imatge nova quan et va bé.

Mira si hi ha una versió nova

1. Obre la pàgina Status (Estat) (http://your-server:6262/health).
2. Llegeix Updates (actualitzacions). Hauries de veure un d’aquests missatges:

Missatge	Significat
“HolyArrs 1.2.0 is out, newer than this one.”	Actualitza quan vulguis
“This is the newest version.”	No cal fer res
“No HolyArrs release is published yet.”	El feed és buit. No hi ha cap problema
“The last check did not work: …”	No s’ha arribat al feed, sovint perquè no hi ha internet
“The update check is off: …”	Desactivada a Paràmetres

3. Per consultar-ho ara, clica a Check now (comprova ara) (o Check again, torna a comprovar). Cal el permís Change settings (canviar paràmetres).

Una versió més nova també es mostra com una advertència de salut. Una comprovació fallida només es mostra a Updates.

Actualitza

1. Baixa la imatge nova i reinicia: docker compose pull, i després docker compose up -d.
2. HolyArrs s’inicia. Si la versió nova canvia com es desen les dades, primer fa una còpia de seguretat i després actualitza les dades. Hauries de veure que l’app s’obre a la versió nova.

Consell

Un pas d’actualització que falla es desfà i HolyArrs s’atura en una pàgina que diu què ha passat. Les teves dades d’abans de l’actualització es queden com a còpia de seguretat.

Torna a la versió anterior

HolyArrs no pot canviar la seva pròpia imatge, així que executes la imatge anterior i HolyArrs torna a posar les dades anteriors.

Precaució

Tot el que ha canviat després de l’actualització, com els títols nous, els paràmetres i l’historial, no és a la còpia de seguretat d’abans de l’actualització.

1. Canvia l’etiqueta de la imatge al teu fitxer compose (o a docker run) per la de l’anterior, per exemple holyarrs/holyarrs:<older version>.
2. Executa docker compose up -d.
3. Si l’actualització no va canviar les dades, s’inicia la versió anterior. Ja has acabat.
4. Si no, la versió anterior mostra una pàgina en lloc de l’app. Clica a Put back the data from before the update (torna a posar les dades d’abans de l’actualització).
5. Escriu el codi d’un sol ús. Trobes el codi amb docker logs <container>; cerca “one-time code”.
6. HolyArrs comprova la còpia de seguretat, la posa al seu lloc i s’atura. Hauries de veure que el contenidor torna a iniciar-se amb aquestes dades gràcies a la seva política de reinici. Si no en té, inicia’l tu.

Sense la pàgina: docker exec <container> /holyarrs restore --pre-update, i després docker restart <container>. Sense Docker: atura HolyArrs, executa holyarrs restore --pre-update i inicia’l.

No se suprimeix res. Les dades més noves es mouen a backups/before-restore-<time>/, de manera que ho pots desfer. Si tornes enrere més d’una versió, es tria la còpia de seguretat d’abans d’una actualització més recent que aquella versió pugui llegir.

Opcions

Tot és a Settings > Health checks (Paràmetres > Comprovacions de salut). Els tres darrers són a la part avançada de la targeta.

Paràmetre	Per defecte	Canvia’l quan
Check for a newer HolyArrs	On	No vols cap petició a l’exterior
Check for updates every	dia	Vols menys comprovacions: 3, 7, 14 o 30 dies
Release feed	Buit (versions d’HolyArrs)	Tens el teu propi feed
Feed may be on the local network	Off	El teu feed és a la teva pròpia xarxa
Include test versions (like 1.2.0-rc1)	Off	Vols avisos de versions de prova

Si no funciona

Símptoma: “The last check did not work.” Causa: el servidor no té internet, o el teu propi feed és a la xarxa local. Solució: comprova l’accés a internet, o activa Feed may be on the local network.

Símptoma: el feed de versions no es desa. Causa: l’adreça conté un nom, una contrasenya, ?query o #fragment, o no comença per http:// ni https://. Solució: treu aquestes parts.

Símptoma: l’actualització s’ha aturat per falta d’espai al disc. Causa: no hi ha lloc per a la còpia i l’actualització. Solució: allibera espai on és la carpeta de configuració i torna a començar.

Símptoma: la pàgina per tornar enrere rebutja el teu codi. Causa: un codi antic, o 10 codis incorrectes des de l’últim inici. Solució: copia el codi de la línia més recent del registre. Després de 10 intents incorrectes, reinicia el contenidor i fes servir el codi nou.

Funcions retingudes

Algunes funcions estan desactivades per defecte en aquesta versió. Activa-les sota la teva responsabilitat. Mentre estan retingudes, les seves pàgines i elements de menú s’amaguen, les seves rutes d’API responen “not found” i les seves tasques no s’executen. Les dades que has desat per a elles es conserven.

Per activar-ne una, afegeix el seu interruptor a HOLYARRS_FLAGS, separats per comes, i reinicia el contenidor:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Treu el nom i reinicia per desactivar-la. Els paràmetres amagats tornen quan la tornes a activar.

Interruptor	Funció
row_title_stats	Estadístiques dels títols de les files d’Explore a Appearance
trakt_lists	Clau de Trakt, llistes de Trakt i ressenyes de Trakt. Les llistes de TMDB segueixen activades
alert_channels_more	Avisos de Telegram, ntfy, Gotify, Pushover i webhook. Discord i email segueixen activats
subtitle_sites	Llocs de subtítols i cerca de subtítols. El teu idioma de subtítols segueix activat
emby_signin	Inici de sessió amb Emby. L’actualització de la Biblioteca d’Emby segueix funcionant
go_back	El panell Go back (tornar enrere) de la pàgina Estat. Els passos de Torna enrere funcionen sense ell

No ha canviat res després d’afegir un interruptor? Comprova l’ortografia (minúscules, guions baixos) i reinicia el contenidor, no només la pàgina.

Per a experts

Què envia la comprovació

Una petició a api.github.com per a la versió més nova, només amb User-Agent: HolyArrs/<version>. Sense compte, clau ni llista de multimèdia. Amb la comprovació desactivada, cap petició.

La darrera resposta es desa, de manera que un reinici no comprova abans d’hora. Una comprovació espera 15 s com a màxim, llegeix 512 KB com a màxim i segueix 3 redireccions com a màxim, sense canviar mai entre http i https. Un enllaç a les notes de la versió només es mostra quan apunta a les pàgines de versions d’HolyArrs a GitHub; si no, la versió es mostra com a text simple.

Release feed accepta una resposta de versions a l’estil de GitHub, una llista de versions, qualsevol JSON amb version, o text simple que contingui la versió. Les adreces de metadades del núvol sempre es rebutgen. Una versió de prova compta com a anterior a la versió simple.

La còpia de seguretat abans d'una actualització

Abans de canviar les dades desades, HolyArrs:

1. Comprova que hi ha lloc per a una còpia i l’actualització. Si no, no canvia res. Omets-ho amb HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Copia cada base de dades a backups, comprova la còpia i escriu un fitxer sha256 al costat. Després de 3 còpies fallides, no canvia res.
3. Executa cada pas d’actualització per separat i el comprova. Un pas fallit es desfà; els passos acabats es queden. Inicia la mateixa versió un altre cop per continuar des del pas fallit amb la mateixa còpia.

Després del primer inici correcte, la còpia passa a ser holyarrs-backup-pre-update-<time>.zip, descrita com “before updating from 1.1.0 to 1.2.0”. Es mostra a Settings > Backups i a holyarrs restore --list. Es conserven les 3 més noves; la programació de còpies de seguretat mai no les suprimeix. Una instal·lació nova o una actualització que no toca les dades no en fa cap.

Verifica la imatge

Des de la 1.0.3, cada imatge a Docker Hub està signada per l’execució de la versió a GitHub. No cal baixar cap clau. Comprova una imatge amb cosign. Posa la versió que executes, com 1.0.3, on diu <version>:

cosign verify holyarrs/holyarrs:<version> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/HolyArrs/HolyArrs/\.github/workflows/sign\.yml@refs/(tags/[0-9.]+|heads/main)$'

Hauries de veure The cosign claims were validated. Qualsevol altra cosa vol dir que la imatge no ve de l’execució de versions d’HolyArrs: no l’executis.

La imatge també porta un registre de com es va construir i una llista del que conté (un SBOM). Comprova’ls amb la CLI de GitHub:

gh attestation verify oci://docker.io/holyarrs/holyarrs:<version> --repo HolyArrs/HolyArrs

Els mateixos fitxers són a cada versió de GitHub: .sigstore.json (signatura), .intoto.jsonl (registre de construcció) i .sbom.spdx.json (contingut).

Relacionat

• Còpies de seguretat
• Comprovacions de salut
• Parts i mode segur