[zZMathSP]

Fecha o ciclo que hoje é manual: build da imagem à mão → docker push → editar a tag no repo Infra.

Par deste PR: Buzzlabs/Infra#69 (documentação do fluxo do lado da infra).

O fluxo

push na develop
  → runner ARC `buzzlabs` (k3d Hetzner)
  → build de apps/web/Dockerfile (cache no registry)
  → docker.buzzlabs.com.br/element-grupos:<AAAAMMDD-HHMMSS-sha7>
  → commit `deploy(element): <tag>` na main do Buzzlabs/Infra
  → ArgoCD sincroniza o app matrix-buzzlabs (chat.buzzlabs.com.br)

O runner não fala com o apiserver — quem deploya é o ArgoCD, lendo o repo Infra. Rollback = revert do commit de deploy lá.

Só o matrix-buzzlabs é bumpado. O element do nexojornal (comunidades.nexojornal.com.br, ns default) segue com bump manual: é produção de cliente e tem ignoreDifferences de image no Application.

Decisões

• Workflow novo em vez de editar cd.yaml/docker.yaml. Aqueles são upstream e mexer neles cria conflito em todo merge do element-web original. buzzlabs-cd.yaml é só nosso.
• git checkout --detach antes do build. O scripts/docker-link-repos.sh faz USE_CUSTOM_SDKS=true + JS_SDK_BRANCH=develop quando git rev-parse --abbrev-ref HEAD devolve develop — e o actions/checkout cria exatamente essa branch local num push. O js-sdk develop quebra o build pelo pin do pnpm; era por isso que a build manual era feita a partir de uma branch image-build (ver o plano 2026-07-24-jitsi-jwt-minter no repo Infra). Com HEAD destacado o atalho não dispara e o .git continua disponível para o bind mount do Dockerfile.
• concurrency: buzzlabs-cd com cancel-in-progress: false. Dois jobs concorrentes disputariam o push na main do Infra, e cancelar um no meio publicaria imagem sem o bump correspondente. Runs pendentes coalescem para o commit mais novo (comportamento do GitHub, e o desejado aqui — ver a discussão com o Copilot); o push tem retry com pull --rebase para o caso de outra automação commitar junto.
• Job travado em refs/heads/develop. O workflow_dispatch aceita qualquer ref; sem a guarda, um run manual de uma branch de feature deployaria aquele código em chat.buzzlabs.com.br.
• Tag <data>-<hora>-<sha7> e commit deploy(element): <tag>, iguais ao que o clock-buzz já usa no Infra.
• Actions pinadas por SHA, como o resto dos workflows do repo (zizmor / lint:workflows).

Antes de mergear

O workflow usa os mesmos segredos do arc-canary.yml do repo Infra: vars.BUZZLABS_REGISTRY_USER, secrets.BUZZLABS_REGISTRY_PASSWORD, vars.BUZZLABS_APP_ID, secrets.BUZZLABS_APP_PRIVATE_KEY. Eles são de organização — vale conferir se o element-web está na lista de repositórios com acesso (não consegui ler isso com meu token) e se a GitHub App buzzlabs-app está instalada no Infra com permissão de escrita em conteúdo.

O primeiro run é o teste de verdade: o build do Element é mais pesado que qualquer coisa que já rodou nesses runners (limite de 2 CPU / 8Gi no container do runner). Se der OOM ou estourar tempo, o caminho é subir o teto do scale set. Dá para disparar por workflow_dispatch sem esperar um commit — a partir da develop, que é a única ref que o job aceita.

Vale registrar: o build da imagem (apps/web/Dockerfile) está verde, mas a develop tem CI vermelho em lint/tipos/testes de código, anterior a este PR. Este workflow não tem portão de qualidade na frente — publica o que estiver na ponta da develop. Pôr um needs: num job de lint só faz sentido depois que essa dívida for paga, senão trava todo deploy.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Manual dispatch is not restricted to trusted develop, and concurrency can drop pending commits.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Automates Buzzlabs CD from develop, building and publishing the Element image and updating the Infra deployment.

Changes:

• Adds timestamp/SHA image tagging with registry caching.
• Authenticates and updates the Infra repository via GitHub App.
• Adds serialized deployment updates with retry logic.

File summaries

File	Description	Findings
.github/workflows/buzzlabs-cd.yaml	New Buzzlabs build, publish, and Infra bump workflow.	Critical (3 votes): Manual dispatch can deploy arbitrary branches. Moderate (2 votes): Concurrency can drop pending commits.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[zZMathSP]

Procedente, e era pior do que parece: a descrição deste PR sugeria usar o workflow_dispatch para testar o primeiro run — o que teria deployado a branch de teste em chat.buzzlabs.com.br.

Adicionado if: github.ref == 'refs/heads/develop' no job. O dispatch continua existindo (serve para repetir um deploy sem commit novo), mas de qualquer outra ref o job aparece como pulado em vez de deployar.

[zZMathSP]

A descrição do comportamento está certa e meu comentário no arquivo estava errado — dizia "serializa", que não é o que o GitHub faz.

Fiquei com a segunda opção que você sugere (deixar explícito que é latest-commit-only), não com a fila FIFO: para um CD que publica a ponta da develop, buildar e deployar commits intermediários já superados é trabalho jogado fora num runner que é o de menor prioridade do cluster, e ainda faria o ArgoCD passar por versões intermediárias. Coalescing é o comportamento desejado; o que não pode é cancelar um run em andamento, senão sobra imagem publicada sem o bump — daí o cancel-in-progress: false continuar.

Comentário reescrito dizendo isso, inclusive que quem quiser a imagem de um commit intermediário precisa buildar à mão.