atualiza Deploy workflows #5

Merged

victor merged 6 commits from dev into main

2026-10-01 09:33:51 -03:00

victor commented

2026-10-01 09:33:31 -03:00

Owner

No description provided.

victor added 6 commits

2026-10-01 09:33:31 -03:00

ci(producao): deploy automatico por tag, no runner do staging 31b9c31bb3

Esteira irma da do staging (docs/infra/deploy-staging.md §14), no mesmo
servidor e no mesmo runner. O gatilho e o push de uma tag vX.Y.Z: a main
protegida no Forgejo decide O QUE vai para producao, a tag decide QUANDO.

infra/producao/devflow-deploy-producao (root, via sudo) exige os dois portoes
antes de tocar em qualquer container: o commit da tag tem de estar na main e a
tag tem de bater com a "version" do package.json daquele commit — o mesmo
numero do selo do header, da tela de Novidades e do /api/health. Depois:
dump do banco (7 ultimos em $DATA_PATH/backups; PRE_DEPLOY_BACKUP=0 desliga),
imagem atual guardada como devflow:production-anterior para o rollback de um
passo, up -d --build, up -d --force-recreate --no-deps app, e smoke que confere
a VERSAO devolvida pelo /api/health, nao so o 200.

Tambem aqui:
- docker-compose.production.yml ganha x-devflow-version (o deploy recusa rodar
  quando a copia instalada diverge) e context: ${DEVFLOW_SRC:-.}, porque o
  compose roda com --project-directory na pasta de configuracao, que nao tem o
  codigo. Sem DEVFLOW_SRC o deploy a mao de dentro do clone nao muda.
- infra/producao/install, irmao do de staging: instala fora do clone, mostra o
  diff e pede confirmacao. Recusa o clone do staging (que leva reset --hard a
  cada push na dev) e poe o .env.production em root:600 nos dois lados — ele
  nao pode ficar legivel num clone do usuario do runner, que executa o que
  vier de qualquer push.
- sudoers proprio: remove-lo desliga so o deploy de producao.
- docs/infra/deploy-producao.md: secao com o fluxo da tag, a instalacao no
  servidor passo a passo, rollback, re-run e as falhas tipicas.

O drop-in do systemd e o devflow-test-staging continuam vindo do lado do
staging e servem as duas esteiras.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs(producao): a primeira tag e a primeira versao com a esteira na main 7c5500c627

O passo 4 da instalacao mandava rodar o deploy a mao com uma tag que ainda
nao existia, e o script exige a tag no clone. Registra tambem o que nao era
obvio: o Forgejo executa o workflow do commit taggeado, entao tag em commit
anterior a esta esteira nao dispara nada.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ci: um script de deploy para os dois ambientes, com o ambiente como argumento bb41f73e0d

Havia um script por ambiente (infra/staging + infra/producao) repetindo ~31
linhas de esqueleto: helpers, flock, fetch/is-ancestor/reset, bloco de
versoes, os dois `up` e o laco do smoke. Agora e um so, em infra/deploy, e o
ambiente e o primeiro argumento:

  devflow-deploy staging  <sha>
  devflow-deploy producao <sha> <tag>
  devflow-test   <ambiente> <sha>
  devflow-install <ambiente> [--clone <caminho>]

O que muda entre os ambientes (branch, pasta de configuracao, arquivo de env,
porta do smoke, exigir tag, backup) esta numa tabela unica no topo do
devflow-deploy; o resto do corpo e comum.

O que impedia a unificacao era o gate de versao exigir IGUALDADE entre a copia
instalada e a do clone: como o clone do staging vive na dev e o de producao na
main, um script unico seria comparado com duas versoes diferentes do mesmo
arquivo e uma delas recusaria. A regra passa a ser **instalado >= clone**:
mais velho que o clone continua sendo erro (servidor desatualizado), mais novo
e o caso normal enquanto uma correcao feita pela dev nao chega na main — o
script novo sabe fazer o que o antigo fazia. Pelo mesmo motivo o install nunca
rebaixa: a partir de um clone atrasado ele avisa e mantem a copia instalada.

O install tambem remove os arquivos da estrutura antiga (devflow-deploy-staging,
devflow-test-staging, devflow-staging-install e os de producao), listando-os
antes da confirmacao. A ordem da migracao — reinstalar os dois ambientes ANTES
de empurrar os workflows novos, senao o primeiro push na dev acha um sudo que
ja nao existe — esta no passo a passo de docs/infra/deploy-producao.md.

shellcheck limpo nos tres scripts (so um SC2012 informativo no ls -1t da
retencao de backups, cujos nomes o proprio script gera).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Merge remote-tracking branch 'origin/dev' into dev 0e45d15058

ci(producao): gatilho por merge na main ou por tag, escolhido numa variavel 25000f561f

O workflow de producao escuta push na main e tags v*, e a variavel
PRODUCAO_GATILHO do repositorio (Settings -> Actions -> Variables) decide
qual dos dois roda: vazia ou "merge" implanta todo merge na main; "tag"
volta ao desenho anterior. O evento do outro modo fica skipped. Trocar de
modo nao exige commit nem acesso ao servidor.

No devflow-deploy a tag vira opcional em producao: sem ela, o portao e o
commit estar na main protegida; com ela, continua valendo a conferencia
contra o package.json. O smoke agora confere a versao do /api/health nos
dois casos, e producao avisa (sem barrar) quando a versao do commit ja e a
que esta no ar, o sinal de um merge que esqueceu de subir versao e Novidades.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs(producao): instalacao na ordem real, com o Devflow-Prod como clone

CI e deploy staging / test (push) Successful in 4m2s

Details

CI e deploy staging / deploy (push) Successful in 2m18s

Details

3e811af5de

O install copia do clone do ambiente, e o de producao so tem infra/deploy/
depois do merge que, no modo merge, ja implanta. A instalacao passa a usar
PRODUCAO_GATILHO=tag durante a transicao e o primeiro deploy e feito a mao.
O clone de producao e o diretorio de onde ela ja subia a mao, convertido
para o usuario do runner, em vez de um clone novo em /var/lib.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>