Pular para conteúdo

0030 — Adota o CI 100% GitHub Actions e o deploy pelo control-plane

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-10 · Decidido em: 2026-08-31

Contexto

Este RD não decide nada novo: são quatro normas da casa, cada uma com o seu ADR central —

  • o CI/CD 100% GitHub Actions (ADR central 0027): um pipeline.yml único, Forgejo sem CI;
  • o control-plane de deploy (ADR central 0026): o CI dispara o deploy por API M2M no central-backend, sem ponte SSH;
  • o native-image como alvo de deploy do server Micronaut elegível (ADR central 0022);
  • o slug de registry (ADR central 0024): o slug é o nome da imagem e pode divergir do app_id.

O que faltava aqui era o rastro local — quando este app adotou e o que declarou.

Antes, o caminho foi em degraus: build native no modelo Docker com o slug vantroba-xls no registry (7b967a1, 2026-08-24); deploy do native pela ponte SSH (34ef27c, 2026-08-28); build do jar fora do host, com o Coolify só puxando a imagem (41c4fa3, 2026-08-29, e recurso pull em c3b1585). Gate, doc e release ainda rodavam em workflows separados no runner Forgejo.

Decisão

Adota os quatro ADRs; o corte final foi em 2026-08-31, em dois commits:

  • 2cdfcae — deploy pelo control-plane (0026). O CI chama POST https://central-backend.xadm.biz/api/ci/deploy, autenticado pelo CENTRAL_DEPLOY_TOKEN (secret do GitHub), no lugar da ponte SSH. A primeira release entregue assim foi a v2.2.3 (2026-08-31).
  • 8e44eed — pipeline único no GitHub (0027). O .github/workflows/pipeline.yml junta gate, doc, release, build e deploy; o repo não tem mais workflow no Forgejo.

Declarações locais:

  • Três identidades, divergentes de propósito (0024). Slug de registry vantroba-xls (= imagem fonte.xadm.biz/xadm/vantroba-xls, e o slug do portal de docs); app_id bi-transporte-xls (GlitchTip, Central de Apps); repo vantroba-bi-xls (Forgejo). Não "corrigir" um pelo outro.
  • Dois alvos (0022): build.targets: [jar, native] no docs/app.json. Cada build publica a tag móvel <target>-amd64 (a que o deploy pede) e a imutável <sha>-<target> — o alvo do rollback do smoke (0029).
  • Canário 50/50 no Traefik. vantroba-xls-native-pull é dono do domínio principal excel.vantroba.xadm.biz e tem o fqdn próprio excel-native.vantroba.xadm.biz; vantroba-xls-jar-pull responde em excel-jar.vantroba.xadm.biz. O principal divide 50/50 entre as duas pernas; o fqdn próprio isola uma perna.
  • O pedido de deploy não carrega uuid. Leva só alvo + imagem; quem resolve o recurso Coolify é o central-backend (reconcile pelo slug da imagem). Os uuids ficam em docs/app.json → deploy.* só como registro.
  • Deploy só no release: tag v* (ou workflow_dispatch). Push e PR rodam gate/doc por caminho alterado, sem deploy; o deploy espera o gate (gate vermelho não sobe).

Consequências

  • As imagens são buildadas no runner do GitHub; o Coolify só puxa (auto-deploy desligado). O host de produção não compila nada.
  • Recriar um recurso Coolify (uuid novo) não quebra o deploy: não há allow-list de uuid para ficar órfã (o problema que o 0026 resolve).
  • Os segredos do CI vivem no repo GitHub: CENTRAL_DEPLOY_TOKEN, FORGEJO_USER/FORGEJO_TOKEN (push no registry), DOCS_S3_* e GLITCHTIP_API_TOKEN (smoke, 0029).
  • Com duas pernas no mesmo domínio, as envs de runtime têm de ser iguais nos dois recursos — senão o canário responde diferente conforme a perna. Operação no runbook de deploy.
  • Este RD é ponteiro: divergência de mérito sobre o mecanismo (pipeline único, control-plane, native, slug) se resolve nos ADRs centrais, não aqui. O que se registra localmente é quando e com que declarações o app adotou.