Opdateringer

HolyArrs fortæller dig, når en ny version er ude, og installerer den aldrig selv. Du henter det nye image, når det passer dig.

Se, om en ny version er ude

1. Åbn siden Status (http://your-server:6262/health).
2. Læs Updates (opdateringer). Du bør kunne se en af disse:

Besked	Betydning
“HolyArrs 1.2.0 is out, newer than this one.”	Opdater, når du er klar
“This is the newest version.”	Der er ikke noget at gøre
“No HolyArrs release is published yet.”	Feedet er tomt. Der er ikke noget galt
“The last check did not work: …”	Feedet kunne ikke nås, ofte fordi der ikke er internet
“The update check is off: …”	Slået fra i Indstillinger

3. Hvis du vil spørge nu, så klik på Check now (tjek nu) eller Check again (tjek igen). Det kræver rettigheden Change settings (ændre indstillinger).

En nyere version vises også som en advarsel i tilstandstjekket. Et tjek, der fejlede, vises kun under Updates.

Opdatering

1. Hent det nye image, og genstart: docker compose pull, derefter docker compose up -d.
2. HolyArrs starter. Hvis den nye version ændrer, hvordan data gemmes, tager den først en backup og opdaterer så dataene. Du bør kunne se appen åbne på den nye version.

Tip

Et opdateringstrin, der fejler, bliver gjort om, og HolyArrs stopper på en side, der fortæller, hvad der skete. Dine data fra før opdateringen bliver liggende som backup.

Gå tilbage til den ældre version

HolyArrs kan ikke ændre sit eget image, så du kører det ældre image, og HolyArrs lægger de ældre data tilbage.

Bemærk

Alt, der er ændret efter opdateringen, som nye titler, indstillinger og historik, er ikke med i backuppen fra før opdateringen.

1. Ændr image-taggen i din compose-fil (eller docker run) til den ældre, for eksempel holyarrs/holyarrs:<older version>.
2. Kør docker compose up -d.
3. Hvis opdateringen ikke ændrede dataene, starter den ældre version. Så er du færdig.
4. Ellers viser den ældre version en side i stedet for appen. Klik på Put back the data from before the update (læg dataene fra før opdateringen tilbage).
5. Skriv engangskoden. Du finder den med docker logs <container>. Led efter “one-time code”.
6. HolyArrs tjekker backuppen, lægger den på plads og stopper. Du bør kunne se containeren starte igen på de data gennem sin genstartspolitik. Uden en genstartspolitik starter du den selv.

Uden siden: docker exec <container> /holyarrs restore --pre-update, derefter docker restart <container>. Uden Docker: stop HolyArrs, kør holyarrs restore --pre-update, og start den.

Intet bliver slettet. De nyere data flyttes til backups/before-restore-<time>/, så du kan fortryde. Hvis du går mere end én version tilbage, vælges den nyeste backup fra før en opdatering, som den version kan læse.

Valg

Alt sammen under Settings > Health checks (indstillinger > tilstandstjek). De sidste tre ligger under kortets avancerede del.

Indstilling	Standard	Ændr den, når
Check for a newer HolyArrs (tjek efter en nyere HolyArrs)	Til	Du slet ikke vil have, at HolyArrs sender nogen forespørgsel ud
Check for updates every (tjek efter opdateringer hver)	dag	Du vil have færre tjek: 3, 7, 14 eller 30 dage
Release feed	Tomt (HolyArrs-versioner)	Du hoster dit eget feed
Feed may be on the local network (feedet må ligge på det lokale netværk)	Fra	Dit feed ligger på dit eget netværk
Include test versions (like 1.2.0-rc1) (medtag testversioner)	Fra	Du vil have besked om testversioner

Hvis det ikke virker

Symptom: “The last check did not work.” Årsag: serveren har ikke internet, eller dit eget feed ligger på det lokale netværk. Løsning: tjek internetadgangen, eller slå Feed may be on the local network til.

Symptom: release-feedet kan ikke gemmes. Årsag: adressen indeholder et navn, en adgangskode, en ?query eller et #fragment, eller den starter ikke med http:// eller https://. Løsning: fjern de dele.

Symptom: opdateringen stoppede, fordi der ikke var nok plads på disken. Årsag: der er ikke plads til kopien og opdateringen. Løsning: frigør plads der, hvor konfigurationsmappen ligger, og start igen.

Symptom: siden til at gå tilbage afviser din kode. Årsag: en gammel kode, eller 10 forkerte koder siden sidste start. Løsning: kopier koden fra den nyeste logline. Efter 10 forkerte forsøg skal du genstarte containeren og bruge den nye kode.

Tilbageholdte funktioner

Nogle funktioner er slået fra som standard i denne version. Slå dem til på eget ansvar. Så længe de er holdt tilbage, er deres sider og menupunkter skjult, deres API-routes svarer “not found”, og deres opgaver kører ikke. Data, du har gemt til dem, bliver liggende.

Du slår en til ved at tilføje dens kontakt til HOLYARRS_FLAGS, adskilt med komma, og genstarte containeren:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Fjern navnet, og genstart for at slå den fra igen. Skjulte indstillinger kommer tilbage, når du slår den til igen.

Kontakt	Funktion
row_title_stats	Titelstatistik i Explore-rækker under Appearance
trakt_lists	Trakt-nøgle, Trakt-lister og Trakt-anmeldelser. TMDB-lister forbliver slået til
alert_channels_more	Beskeder via Telegram, ntfy, Gotify, Pushover og webhook. Discord og e-mail forbliver slået til
subtitle_sites	Undertekstsider og undertekstsøgning. Dit undertekstsprog forbliver slået til
emby_signin	Log ind med Emby. Opdatering af Emby-biblioteket virker stadig
go_back	Panelet Go back (gå tilbage) på siden Status. Trinnene i Gå tilbage virker uden det

Er der ikke sket noget, efter du tilføjede en kontakt? Tjek stavemåden (små bogstaver, understregninger), og genstart containeren, ikke kun siden.

For erfarne

Hvad tjekket sender

Én forespørgsel til api.github.com efter den nyeste version, kun med User-Agent: HolyArrs/<version>. Ingen konto, nøgle eller medieliste. Når tjekket er slået fra, sendes der slet ingen forespørgsel.

Det sidste svar bliver gemt, så en genstart ikke tjekker, før det er tid. Et tjek venter højst 15 s, læser højst 512 KB og følger højst 3 omdirigeringer, og skifter aldrig mellem http og https. Et link til versionsnoter vises kun, når det peger på HolyArrs’ release-sider på GitHub. Ellers vises versionen som almindelig tekst.

Release feed accepterer et svar i GitHub-stil, en liste af releases, al JSON med version eller ren tekst med versionen. Adresser til cloud-metadata afvises altid. En testversion tæller som ældre end den almindelige version.

Backuppen før en opdatering

Før HolyArrs ændrer gemte data:

1. Tjekker den, at der er plads til en kopi og opdateringen. Hvis ikke, ændres der ingenting. Spring over med HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Kopierer den hver database til backups, tjekker kopien og skriver en sha256-fil ved siden af. Efter 3 mislykkede kopieringer ændres der ingenting.
3. Kører den hvert opdateringstrin for sig og tjekker det. Et trin, der fejler, bliver gjort om, og færdige trin bliver stående. Start den samme version igen for at fortsætte fra det trin, der fejlede, med den samme kopi.

Efter den første gode start bliver kopien til holyarrs-backup-pre-update-<time>.zip, beskrevet som “before updating from 1.1.0 to 1.2.0”. Den vises under Settings > Backups og i holyarrs restore --list. De nyeste 3 bliver gemt, og backuptidsplanen fjerner dem aldrig. En ny installation eller en opdatering, der lader dataene være, laver ingen.

Bekræft imaget

Fra 1.0.3 og frem er hvert image på Docker Hub signeret af release-kørslen på GitHub. Der er ingen nøgle at downloade. Tjek et image med cosign. Sæt den version, du kører, for eksempel 1.0.3, der hvor der står <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)$'

Du bør kunne se The cosign claims were validated. Alt andet betyder, at imaget ikke kom fra HolyArrs’ release-kørsel: kør det ikke.

Imaget har også en optegnelse over, hvordan det blev bygget, og en liste over, hvad der er i det (en SBOM). Tjek dem med GitHub CLI:

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

De samme filer ligger på hver GitHub-release: .sigstore.json (signatur), .intoto.jsonl (byggeoptegnelse) og .sbom.spdx.json (indhold).

Se også

• Backups
• Tilstandstjek
• Dele og fejlsikret tilstand