Oppdateringer

HolyArrs sier fra når en ny versjon er ute, men installerer den aldri selv. Du henter det nye imaget når det passer deg.

Se om en ny versjon er ute

1. Åpne siden Status (http://your-server:6262/health).
2. Les Updates (oppdateringer). Du skal se en av disse:

Melding	Betydning
“HolyArrs 1.2.0 is out, newer than this one.”	Oppdater når du er klar
“This is the newest version.”	Ingenting å gjøre
“No HolyArrs release is published yet.”	Feeden er tom. Ingenting er galt
“The last check did not work: …”	Feeden ble ikke nådd, ofte uten internett
“The update check is off: …”	Slått av i innstillingene

3. For å spørre med en gang, trykk på Check now (sjekk nå) eller Check again (sjekk igjen). Du trenger tillatelsen Change settings (endre innstillinger).

En nyere versjon vises også som en helseadvarsel. En mislykket sjekk vises bare under Updates.

Oppdater

1. Hent det nye imaget og start på nytt: docker compose pull, deretter docker compose up -d.
2. HolyArrs starter. Hvis den nye versjonen endrer hvordan data lagres, tar den først en backup og oppdaterer så dataene. Du skal se at appen åpner på den nye versjonen.

Tips

Et oppdateringstrinn som mislykkes, blir angret, og HolyArrs stopper på en side som forteller hva som skjedde. Dataene dine fra før oppdateringen ligger igjen som backup.

Gå tilbake til forrige versjon

HolyArrs kan ikke bytte sitt eget image, så du kjører det eldre imaget, og HolyArrs legger de eldre dataene tilbake.

Advarsel

Alt som er endret etter oppdateringen, som nye titler, innstillinger og historikk, er ikke med i backupen fra før oppdateringen.

1. Endre image-taggen i compose-filen din (eller i docker run) til den eldre, for eksempel holyarrs/holyarrs:<older version>.
2. Kjør docker compose up -d.
3. Hvis oppdateringen ikke endret dataene, starter den eldre versjonen. Da er du ferdig.
4. Ellers viser den eldre versjonen en side i stedet for appen. Velg Put back the data from before the update (legg tilbake dataene fra før oppdateringen).
5. Skriv inn engangskoden. Finn den med docker logs <container>; se etter “one-time code”.
6. HolyArrs sjekker backupen, legger den på plass og stopper. Du skal se at containeren starter igjen på disse dataene via omstartspolicyen. Uten en slik policy må du starte den selv.

Uten siden: docker exec <container> /holyarrs restore --pre-update, deretter docker restart <container>. Uten Docker: stopp HolyArrs, kjør holyarrs restore --pre-update, start den.

Ingenting slettes. De nyere dataene flyttes til backups/before-restore-<time>/, så du kan angre. Går du tilbake mer enn én versjon, velges den nyeste backupen fra før en oppdatering som den versjonen kan lese.

Valg

Alt ligger under Settings > Health checks (innstillinger > helsesjekker). De tre siste ligger i den avanserte delen av kortet.

Innstilling	Standard	Endre den når
Check for a newer HolyArrs	On	Du vil ikke ha noen forespørsler utenfra i det hele tatt
Check for updates every	day	Du vil ha færre sjekker: 3, 7, 14 eller 30 dager
Release feed	Empty (HolyArrs releases)	Du har din egen feed
Feed may be on the local network	Off	Feeden din ligger på ditt eget nettverk
Include test versions (like 1.2.0-rc1)	Off	Du vil ha varsler om testversjoner

Hvis det ikke fungerer

Symptom: “The last check did not work.” Årsak: serveren har ikke internett, eller din egen feed ligger på det lokale nettverket. Løsning: sjekk internettilgangen, eller slå på Feed may be on the local network.

Symptom: release-feeden lar seg ikke lagre. Årsak: adressen inneholder et navn, passord, ?query eller #fragment, eller starter ikke med http:// eller https://. Løsning: fjern de delene.

Symptom: oppdateringen stoppet på grunn av for lite diskplass. Årsak: det er ikke plass til kopien og oppdateringen. Løsning: frigjør plass der konfigurasjonsmappen ligger, og start på nytt.

Symptom: siden for å gå tilbake avviser koden din. Årsak: en gammel kode, eller 10 gale koder siden siste oppstart. Løsning: kopier koden fra den nyeste loggelinjen. Etter 10 gale forsøk starter du containeren på nytt og bruker den nye koden.

Funksjoner som holdes tilbake

Noen funksjoner er slått av som standard i denne versjonen. Slå dem på bare på egen risiko. Mens de holdes tilbake, er sidene og menyvalgene deres skjult, API-rutene svarer “not found”, og oppgavene deres kjører ikke. Data du har lagret for dem, blir liggende.

For å slå en på legger du bryteren til i HOLYARRS_FLAGS, kommaseparert, og starter containeren på nytt:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Fjern navnet og start på nytt for å slå den av. Skjulte innstillinger kommer tilbake når du slår den på igjen.

Bryter	Funksjon
row_title_stats	Statistikk for titler i Explore-rader under Appearance
trakt_lists	Trakt-nøkkel, Trakt-lister og Trakt-anmeldelser. TMDB-lister forblir på
alert_channels_more	Varsler til Telegram, ntfy, Gotify, Pushover og webhook. Discord og e-post forblir på
subtitle_sites	Undertekstsider og søk etter undertekster. Undertekstspråket ditt forblir på
emby_signin	Logg inn med Emby. Oppdatering av Emby-biblioteket fungerer fortsatt
go_back	Panelet Go back på Status-siden. Trinnene i Gå tilbake fungerer uten det

Ble ingenting endret etter at du la til en bryter? Sjekk stavemåten (små bokstaver, understrek) og start containeren på nytt, ikke bare siden.

For viderekomne

Hva sjekken sender

Én forespørsel til api.github.com om den nyeste versjonen, med bare User-Agent: HolyArrs/<version>. Ingen konto, nøkkel eller medieliste. Med sjekken slått av sendes ingen forespørsel i det hele tatt.

Det siste svaret lagres, så en omstart sjekker ikke før det er på tide. Én sjekk venter maksimalt 15 s, leser maksimalt 512 KB og følger maksimalt 3 omdirigeringer, uten å bytte mellom http og https. En lenke til versjonsnotater vises bare når den peker til HolyArrs sine versjonssider på GitHub. Ellers vises versjonen som ren tekst.

Release feed godtar et svar i GitHub-stil, en liste med versjoner, en hvilken som helst JSON med version, eller ren tekst med versjonen. Adresser til metadata i skyen avvises alltid. En testversjon regnes som eldre enn den vanlige versjonen.

Backupen før en oppdatering

Før lagrede data endres, gjør HolyArrs dette:

1. Sjekker at det er plass til en kopi og oppdateringen. Hvis ikke, endres ingenting. Hopp over med HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Kopierer hver database til backups, sjekker kopien og skriver en sha256-fil ved siden av. Etter 3 mislykkede kopier endres ingenting.
3. Kjører hvert oppdateringstrinn for seg og sjekker det. Et trinn som mislykkes, angres. Ferdige trinn blir stående. Start den samme versjonen igjen for å fortsette fra trinnet som mislyktes, med den samme kopien.

Etter den første vellykkede oppstarten blir 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 3 nyeste beholdes. Backup-tidsplanen fjerner dem aldri. En ny installasjon, eller en oppdatering som ikke rører dataene, lager ingen.

Verifiser imaget

Fra 1.0.3 er hvert image på Docker Hub signert av versjonskjøringen på GitHub. Det er ingen nøkkel å laste ned. Sjekk et image med cosign. Sett inn versjonen du kjører, for eksempel 1.0.3, der det 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 skal se The cosign claims were validated. Alt annet betyr at imaget ikke kom fra HolyArrs sin versjonskjøring: ikke kjør det.

Imaget har også en oversikt over hvordan det ble bygget og en liste over innholdet (en SBOM). Sjekk dem med GitHub CLI:

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

De samme filene ligger på hver GitHub-versjon: .sigstore.json (signatur), .intoto.jsonl (byggoversikt) og .sbom.spdx.json (innhold).

Relatert

• Backuper
• Helsesjekker
• Deler og sikkermodus