Lançar uma versão

Transforme uma compilação testada em uma versão. Esta página é para mantenedores.

Cuidado

Só o mantenedor inicia uma versão. Não crie tags, não publique e não mova uma tag da imagem por conta própria.

Antes de começar

• Todas as verificações de Testes passam, incluindo uma execução completa de ponta a ponta e as execuções longas e de falha.
• O CHANGELOG.md tem a versão nova.
• O Python 3 está instalado para os scripts de lançamento.

Prepare uma versão

1. Escreva releases/notes-<version>.toml, por exemplo releases/notes-1.0.0.toml. Veja Arquivo de notas da versão.

2. Verifique o arquivo:

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

   Você não deve ver nenhum erro. Uma palavra proibida, um travessão, uma data, conversa de lançamento ou uma issue de destaque repetida faz o script sair com 1.

3. Gere os textos da versão:

   python deploy/release/notes.py 1.0.0

   Você deve encontrar 7 arquivos em releases/out/1.0.0/.

4. Compile a imagem e inicie a imagem com uma pasta de configuração nova:

   docker build --file deploy/Dockerfile .

   Você deve ver o assistente de primeira execução.

5. Execute todas as verificações de Testes no seu computador. Os testes são executados localmente, não no GitHub.

6. Entregue a versão ao mantenedor. O mantenedor envia a tag da versão na main, e isso inicia o lançamento.

Opções

Nomes de versão e de tag

Item	Nome
Tag do Git (enviada pelo mantenedor)	1.0.0 (só números, sem v)
Tag da imagem e version das notas	1.0.0

O workflow só inicia para uma tag X.Y.Z e para quando a tag é diferente do arquivo VERSION.

Tags da imagem

Cada versão envia sua tag de versão e :latest.

Retirar uma versão

1. Envie a próxima versão com a correção.
2. Marque a versão ruim na lista de atualizações para que as instalações não ofereçam essa versão.
3. Mantenha a tag.

Se não funcionar

Sintoma. notes.py --check sai com 1. Causa. O arquivo de notas quebra uma regra. A mensagem diz qual é a linha. Solução. Edite o arquivo de notas, nunca os arquivos em releases/out, e execute de novo.

Sintoma. O workflow para com VERSION says. Causa. A tag e o arquivo VERSION são diferentes. Solução. Corrija o VERSION na main e envie a tag da próxima versão.

Para especialistas

Arquivo de notas da versão

Todo texto de uma versão vem de um único arquivo. Nunca edite à mão o que ele gera.

Campo	Conteúdo
version	X.Y.Z simples
theme	Uma linha
images	Lista de {registry, name}. Só o holyarrs/holyarrs do Docker Hub
docs_url	Opcional. Vazio significa sem link para os Docs
[[highlights]]	Exatamente 3, cada um com line, issues e shot. As issues deles não aparecem em nenhuma linha de grupo
[groups]	Linhas por lugar. New é o padrão. As outras começam com Changed: , Fixed: ou Docs: . Cada uma termina com sua issue, como (#46). Um lugar com menos de 3 linhas vai para Also new
Opcional	[before_you_update] (breaking, manual_steps, backup, rollback), security, known_issues, credits, [stats]. As partes vazias ficam escondidas

Use um login do GitHub só quando ele é conhecido, no arquivo de notas ou em releases/credits-map.json.

Ordem do corpo: tema, Highlights, lugares (Requests, Library, Downloads, Indexers, Accounts, Health, Setup, Install), Also new, Security, Known issues, Before you update, Image, Thanks, linha de estatísticas.

Saída em releases/out/<version>/	Usada para
changelog.md	A entrada do changelog
github.md	O corpo da versão no GitHub
update-notes.json	As notas que o app mostra
reddit.txt	O post do Reddit
discord-dm.txt, discord-announce.md	Discord. Cada um fica abaixo de 1.000 caracteres
roadmap-card.json	O cartão do roadmap

O notes.py aceita --file (outro arquivo de notas), --map (outro mapa de créditos), --out (outra pasta de saída) e --date. O --check avisa sobre linhas longas e quase repetições.

O workflow da imagem

O workflow HolyArrs - Release inicia quando uma tag de versão é enviada. Ele tem três passos:

1. Compilar e enviar a imagem para linux/amd64, linux/arm64 e linux/arm/v7, com a tag da versão e latest.
2. Atualizar a descrição no Docker Hub a partir do README.md.
3. Publicar a versão no GitHub com a seção desta versão do CHANGELOG.md.

Lista de atualizações

O app lê uma lista de atualizações assinada. Cada versão adiciona sua entrada e assina a entrada. A chave de assinatura nunca entra no repositório. O HolyArrs recusa uma lista que ele não consegue verificar.

Depois de uma versão, confira se o rótulo de versão da imagem é igual à tag, e acompanhe as issues novas no primeiro dia:

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

Template de teste para Unraid

O deploy/release/nas-template.py escreve um template de usuário do Unraid para uma imagem exata. Ele não baixa, não instala e não publica nada.

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

Troque <digest> e <pool>.

Flag	Notas
--image	O digest do manifesto no registro, não um ID de imagem do Docker
--config	Um caminho de pool. A ferramenta recusa /mnt/user e /mnt/user0
--movies, --tv, --music, --downloads	Opcionais. Caminhos separados são montagens separadas, então as importações copiam
--port	O padrão é 6262
--allowed-hosts	Opcional, nomes de host separados por vírgula
--output	O arquivo XML a escrever

O template define PUID=99, PGID=100 e UMASK=022. Dê a essa conta permissão de escrita na mídia de teste. Coloque o arquivo em /boot/config/plugins/dockerMan/templates-user/ e escolha o arquivo em Docker > Add Container > Template (Docker > adicionar container > template).

Relacionados

• Testes
• Como contribuir
• Atualizações