Trabalhar numa branch, fazer commits e enviar para o Git existente.
Rever e integrar em main segundo as designações já aprovadas pela Tempo.
O push em main activa o webhook existente. A fila serializa as execuções; a revisão mais recente é verificada e compilada numa pasta nova.
Conferir o commit efectivamente servido em /build/revision.json. Um commit no Git só está instalado quando consta desse endereço. Em caso de falha, a revisão anterior continua servida; o operador consulta os relatórios e logs protegidos.

Não editar a pasta servida. Uma alteração manual detectada interrompe a substituição até ser reconciliada, preservando os ficheiros existentes.

O que segue o Git

Fontes, menus, estilos e formulários são instalados com o build da mesma revisão. Não são transportados por Git a base de dados, ficheiros carregados, contas, permissões, segredos nem estados de publicação.

As migrations são comparadas com o contrato nominal protegido do destino. Uma alteração nesse contrato exige análise e autorização específicas; este executor não executa SQL de migração no destino. A criação do schema durante a verificação usa exclusivamente PostgreSQL/PostGIS descartável, em 127.0.0.1:55441, com nome terminado em _test e identidade conferida pela guarda QA.

Operação e recuperação

O receptor /deploy conserva a protecção própria do Nginx e a assinatura HMAC do Gitea. As páginas públicas não exigem a credencial ambiental; as operações privadas conservam login, permissões e MFA aplicável.

O executor instalado e a configuração em /etc/investmoz-deploy são controlados pelo operador. Alterar as suas fontes no repositório não substitui automaticamente esse controlo. A imagem de CI é fixada por digest; não modifica o PostgreSQL ou PostGIS da aplicação.

O operador consulta:

systemctl status teste-investidor-deploy.service teste-investidor-deploy.path
/var/lib/investmoz-deploy/reports/: commit solicitado, resultado e revisão instalada.
/var/lib/investmoz-deploy/logs/: detalhe protegido da verificação e compilação.

Para reverter, suspender primeiro novas execuções com systemctl stop teste-investidor-deploy.path e aguardar a execução em curso. Executar, como o utilizador de disponibilização existente:

python3 /var/www/deploy/investmoz-pipeline.py --config /etc/investmoz-deploy/delivery.json --rollback

A reversão verifica os hashes, repõe a release anterior e reinicia graciosamente os workers. Conserva a base, uploads, configurações partilhadas e dados posteriores. Não é restauro integral de dados. Repor uma release incompatível com dados/schema posteriores exige análise específica. Retomar a path unit apenas depois da decisão de corrigir ou voltar a disponibilizar a revisão integrada.

O checkout físico anterior é preservado; não é feito reset --hard nele. Assets com nomes hash permanecem num conjunto partilhado para conservar páginas já abertas. Não há eliminação automática de releases ou dados.

Limites

Uma verificação automática não publica conteúdos nem comprova todos os percursos de negócio. Mantêm-se as provas aceites e as pendências funcionais da matriz. Falhas do fluxo devem indicar o comando e o log concreto, sem exposição de segredos ao visitante.