Atualizações

O HolyArrs avisa-te quando há uma versão nova e nunca a instala sozinho. Tu puxas a imagem nova quando te der jeito.

Ver se há uma versão nova

1. Abre a página Status (Estado) (http://your-server:6262/health).
2. Lê Updates (atualizações). Deves ver uma destas mensagens:

Mensagem	Significado
“HolyArrs 1.2.0 is out, newer than this one.”	Atualiza quando quiseres
“This is the newest version.”	Não há nada a fazer
“No HolyArrs release is published yet.”	O feed está vazio. Não há nenhum problema
“The last check did not work: …”	O feed não foi alcançado, muitas vezes por falta de internet
“The update check is off: …”	Desativada nas Definições

3. Para perguntar já, clica em Check now (verificar já) (ou Check again, verificar de novo). Precisa da permissão Change settings (mudar definições).

Uma versão mais recente aparece também como alerta de saúde. Uma verificação falhada só aparece em Updates.

Atualizar

1. Puxa a imagem nova e reinicia: docker compose pull e depois docker compose up -d.
2. O HolyArrs arranca. Se a versão nova muda a forma como os dados são guardados, faz primeiro uma cópia de segurança e só depois atualiza os dados. Deves ver a app abrir na versão nova.

Dica

Um passo de atualização que falhe é desfeito e o HolyArrs para numa página que diz o que aconteceu. Os teus dados de antes da atualização ficam como cópia de segurança.

Voltar à versão anterior

O HolyArrs não consegue mudar a sua própria imagem, por isso executas a imagem anterior e o HolyArrs repõe os dados anteriores.

Cuidado

Tudo o que mudou depois da atualização, como títulos novos, definições e histórico, não está na cópia de segurança de antes da atualização.

1. Muda a etiqueta da imagem no teu ficheiro compose (ou no docker run) para a anterior, por exemplo holyarrs/holyarrs:<older version>.
2. Executa docker compose up -d.
3. Se a atualização não mudou os dados, a versão anterior arranca. Está feito.
4. Caso contrário, a versão anterior mostra uma página em vez da app. Clica em Put back the data from before the update (repor os dados de antes da atualização).
5. Escreve o código de utilização única. Encontra-o com docker logs <container>; procura “one-time code”.
6. O HolyArrs verifica a cópia de segurança, coloca-a no lugar e para. Deves ver o contentor arrancar de novo com esses dados, através da sua política de reinício. Sem ela, arranca-o tu.

Sem a página: docker exec <container> /holyarrs restore --pre-update e depois docker restart <container>. Sem Docker: para o HolyArrs, executa holyarrs restore --pre-update e arranca-o.

Nada é apagado. Os dados mais recentes passam para backups/before-restore-<time>/, por isso podes desfazer. Se voltares mais do que uma versão, o HolyArrs escolhe a cópia de segurança de pré-atualização mais recente que essa versão consegue ler.

Opções

Tudo em Settings > Health checks (Definições > Verificações de saúde). As três últimas estão na parte avançada do cartão.

Definição	Predefinição	Muda quando
Check for a newer HolyArrs	Ativada	Não queres nenhum pedido externo
Check for updates every	dia	Queres menos verificações: 3, 7, 14 ou 30 dias
Release feed	Vazio (versões do HolyArrs)	Alojas o teu próprio feed
Feed may be on the local network	Desativada	O teu feed está na tua própria rede
Include test versions (like 1.2.0-rc1)	Desativada	Queres avisos de versões de teste

Se não funcionar

Sintoma: “The last check did not work.” Causa: o servidor não tem internet, ou o teu feed está na rede local. Solução: verifica o acesso à internet, ou ativa Feed may be on the local network.

Sintoma: o feed de versões não guarda. Causa: o endereço tem um nome, uma palavra-passe, ?query ou #fragment, ou não começa por http:// ou https://. Solução: retira essas partes.

Sintoma: a atualização parou por falta de espaço em disco. Causa: não há espaço para a cópia e para a atualização. Solução: liberta espaço onde está a pasta de configuração e arranca de novo.

Sintoma: a página de voltar atrás recusa o teu código. Causa: um código antigo, ou 10 códigos errados desde o último arranque. Solução: copia o código da linha de registo mais recente. Depois de 10 tentativas erradas, reinicia o contentor e usa o código novo.

Funcionalidades retidas

Algumas funcionalidades estão desativadas por predefinição nesta versão. Ativa-as por tua conta e risco. Enquanto estão retidas, as páginas e os itens de menu ficam escondidos, as rotas da API respondem “not found” e as tarefas não correm. Os dados que guardaste para elas mantêm-se.

Para ativar uma, junta o seu interruptor a HOLYARRS_FLAGS, separado por vírgulas, e reinicia o contentor:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Retira o nome e reinicia para a desativar. As definições escondidas voltam quando a ativares de novo.

Interruptor	Funcionalidade
row_title_stats	Estatísticas dos títulos nas linhas do Explore, em Appearance
trakt_lists	Chave do Trakt, listas do Trakt e críticas do Trakt. As listas do TMDB continuam ativas
alert_channels_more	Avisos por Telegram, ntfy, Gotify, Pushover e webhook. Discord e email continuam ativos
subtitle_sites	Sites de legendas e pesquisa de legendas. A tua língua de legendas continua ativa
emby_signin	Iniciar sessão com o Emby. A atualização da biblioteca do Emby continua a funcionar
go_back	O painel Go back na página Status. Os passos em Voltar atrás funcionam sem ele

Nada mudou depois de juntares um interruptor? Verifica a grafia (minúsculas, sublinhados) e reinicia o contentor, não só a página.

Para especialistas

O que a verificação envia

Um pedido a api.github.com pela versão mais recente, apenas com User-Agent: HolyArrs/<version>. Sem conta, chave nem lista dos teus conteúdos. Com a verificação desativada, não há pedido nenhum.

A última resposta fica guardada, por isso um reinício não verifica antes de ser a hora. Cada verificação espera no máximo 15 s, lê no máximo 512 KB e segue no máximo 3 redirecionamentos, sem nunca passar de http para https ou o contrário. Uma ligação para as notas da versão só aparece quando aponta para as páginas de versões do HolyArrs no GitHub; caso contrário a versão aparece como texto simples.

Release feed aceita uma resposta de versões ao estilo do GitHub, uma lista de versões, qualquer JSON com version, ou texto simples com a versão. Os endereços de metadados de cloud são sempre recusados. Uma versão de teste conta como mais antiga do que a versão normal.

A cópia de segurança antes de uma atualização

Antes de mudar os dados guardados, o HolyArrs:

1. Verifica se há espaço para uma cópia e para a atualização. Se não houver, nada muda. Salta este passo com HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Copia cada base de dados para backups, verifica a cópia e escreve um ficheiro sha256 ao lado. Depois de 3 cópias falhadas, nada muda.
3. Executa cada passo da atualização em separado e verifica-o. Um passo falhado é desfeito; os passos concluídos ficam. Arranca a mesma versão outra vez para continuar a partir do passo falhado com a mesma cópia.

Depois do primeiro arranque bem-sucedido, a cópia passa a holyarrs-backup-pre-update-<time>.zip, descrita como “before updating from 1.1.0 to 1.2.0”. Aparece em Settings > Backups e em holyarrs restore --list. As 3 mais recentes ficam guardadas; o agendamento de cópias de segurança nunca as remove. Uma instalação nova, ou uma atualização que deixa os dados como estão, não faz nenhuma.

Verificar a imagem

A partir da 1.0.3, cada imagem no Docker Hub é assinada pela execução de versões no GitHub. Não há nenhuma chave para transferir. Verifica uma imagem com o cosign. Põe a versão que executas, como 1.0.3, onde diz <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)$'

Deves ver The cosign claims were validated. Qualquer outra coisa quer dizer que a imagem não veio da execução de versões do HolyArrs: não a executes.

A imagem traz também um registo de como foi construída e uma lista do que tem lá dentro (um SBOM). Verifica-os com a CLI do GitHub:

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

Os mesmos ficheiros estão em cada versão no GitHub: .sigstore.json (assinatura), .intoto.jsonl (registo da construção) e .sbom.spdx.json (conteúdo).

Relacionado

• Cópias de segurança
• Verificações de saúde
• Partes e modo de segurança