Conclusão principal: um pipeline de CI verde prova que as verificações automatizadas foram aprovadas; não significa que um pull request da App Store tenha sido aprovado. Se uma submissão de aplicação CasaOS/ZimaOS estiver aberta há meses, pare de voltar a verificar os mesmos indicadores e determine qual a camada que ainda está pendente: validação do repositório, feedback do revisor, requisitos de merge ou revisão do maintainer.
O exemplo do mundo real que esteve na origem desta página estava excecionalmente bem preparado: a aplicação tinha sido migrada para o formato v2, as verificações estavam verdes, as tags do Docker estavam fixadas, os metadados estavam preenchidos e o contribuidor estava a fazer uma pergunta simples — “Há algo a bloquear o merge ou alguma alteração necessária da minha parte?”
Primeiro, verifique as verificações que realmente importam para o repositório atual da App Store
O atual fluxo de contribuição para a App Store pede aos contribuidores que façam um fork do repositório, efetuem e testem as alterações e, em seguida, abram um pull request a explicar o que foi alterado e como foi validado.
Para validação local, o repositório pede especificamente aos contribuidores que executem:
./scripts/build_dist.shUm resultado positivo é mais específico do que “o meu ficheiro compose parece estar correto”. A compilação deve ser concluída sem erros, produzir dist/index.jsone gerar a aplicação alterada em dist/apps/<app-id>/.
As verificações de CI da App Store do repositório executam a validação do compose e uma verificação completa de compilação v2 nos pull requests. YAML inválido, metadados obrigatórios da aplicação em falta, recursos referenciados inexistentes ou incompatibilidades de arquitetura podem fazer a compilação falhar.
Um CI verde é necessário, mas não constitui a decisão de merge
Este é o ponto que muitos contribuidores não compreendem. Uma verificação automatizada bem-sucedida apenas indica que o commit cumpriu as condições testadas por essa verificação. As verificações de estado do GitHub são independentes das decisões de revisão e merge.
Um pull request pode continuar aberto porque precisa de:
- uma revisão do maintainer ou do responsável pelo código;
- as alterações solicitadas a implementar;
- a branch a atualizar;
- um conflito de merge a resolver;
- decisões de aceitação ou curadoria específicas do repositório que a CI não pode tomar.
Os requisitos de integração do GitHub tratam as revisões, as verificações de estado e as regras do branch como condições de integração separadas.
Utilize o próprio PR para identificar o bloqueio
Antes de publicar outro comentário «alguma novidade?», verifique quatro locais:
- Verificações: confirme que o commit mais recente — e não um SHA antigo — passou nos fluxos de trabalho obrigatórios.
- Conversa: procure comentários do responsável pela manutenção ou pedidos de alterações ainda não resolvidos.
- Ficheiros alterados: confirme que a migração para v2 não deixou metadados legados no local errado.
- Caixa de integração: normalmente, o GitHub indica se ainda é necessária uma revisão, uma verificação de estado, a resolução de conflitos ou uma atualização do branch.
Se a CI estiver verde e a caixa de integração não indicar nenhum bloqueio que o contribuidor possa resolver, o passo restante será provavelmente a revisão humana, e não outra alteração de código.
Para submissões v2, valide o contrato de origem — não apenas o contentor Docker
Um contentor funcional não é automaticamente uma entrada válida na App Store. O protocolo v2 atual espera que a definição da aplicação de origem contenha uma configuração de execução Docker Compose padrão, além de um bloco de metadados x-casaos de nível superior. O esquema de metadados x-casaos define campos como id, main, index, port_map, icon, title, categoria, arquitetura e metadados da versão.
Assim, quando uma submissão indica «CI passed», o acompanhamento útil não é «o SonarQube passou?», mas sim:
- Fá-lo
./scripts/build_dist.shpassou no branch mais recente? - A aplicação gera o resultado v2 esperado?
- Todos os ícones, miniaturas e capturas de ecrã referenciados estão acessíveis?
- A arquitetura declarada corresponde à imagem?
- Os metadados da versão e da publicação estão atualizados?
- Todos os comentários da revisão foram resolvidos?
Como fazer o acompanhamento sem gerar ruído
Se a submissão estiver sem novidades há muito tempo, publique uma atualização de estado breve em vez de repetir toda a apresentação original. Um acompanhamento útil é semelhante a isto:
PR: #888
Último commit: <SHA>
Compilação v2: ./scripts/build_dist.sh concluída com êxito
GitHub Actions: aprovado no commit mais recente
Comentários de revisão em aberto: nenhum
O que preciso: confirmação de qualquer bloqueio ainda existente do lado do responsável pela manutençãoIsso dá imediatamente ao responsável pela manutenção uma questão à qual pode responder.
Se a revisão da loja oficial for demorada, uma loja de terceiros é um canal de distribuição válido
O ecossistema v2 não está limitado a um único repositório. A ZimaOS também documenta a configuração de lojas de terceiros para repositórios compatíveis. Se uma aplicação precisar de distribuição pela comunidade antes de uma integração oficial, publicá-la através de uma loja de terceiros mantida pode ser uma alternativa prática enquanto o PR original continua aberto.
Para os utilizadores, e não para os contribuidores, a Loja de aplicações ZimaOS explica o modelo de aplicações com um clique e o conceito de lojas de terceiros. A plataforma de aplicações ZimaOS apresenta a visão geral atual do ecossistema. Se estiver a criar um anfitrião compacto para testar aplicações com utilização intensiva de Docker, a ZimaBoard 2 é uma plataforma de teste x86 relevante, mas não é um requisito para submeter uma aplicação.
Perguntas frequentes
A aprovação na CI significa que a minha aplicação já deve ser integrada?
Não. A CI apenas comprova o que os fluxos de trabalho automatizados validam. A revisão humana, as regras do repositório, os comentários por resolver, os conflitos e as decisões dos responsáveis pela manutenção são aspetos distintos.
Qual é o comando de validação local mais útil para a App Store atual?
O guia de contribuição do repositório aponta para ./scripts/build_dist.sh. Confirme que termina corretamente e produz os ficheiros v2 esperados.
Devo continuar a alterar o código se todas as verificações estiverem aprovadas?
Não sem um motivo específico. Primeiro, inspecione a caixa de merge e reveja os comentários. Se não houver nenhum bloqueio que o contribuidor possa resolver, peça a decisão de revisão em falta em vez de fazer alterações especulativas.
Posso publicar a aplicação fora da loja oficial?
Sim. A documentação atual da v2 suporta explicitamente lojas ZimaOS de terceiros, pelo que uma loja externa pode ser um canal de distribuição legítimo.
