Runner CI/CD Documentação 9fe087f

`runner deploy-all`

Deploy de todas as aplicações registradas no runner, em ordem de dependência (depends_on). Equivalente a runner deploy --all, mas exposto como subcommand top-level para orquestradores externos (CCS, MCP, scripts) chamarem sem precisar de flag knowledge.

Disponível desde v2.22.8.

Gate de amplitude (v2.80.0)

Este comando alcança todas as apps do servidor. A partir da v2.80.0 ele imprime as famílias afetadas antes de executar:

ATENÇÃO: deploy-all --all alcança 34 PROJETOS (ccs, elementic, muxally, ...) em 80 apps:
  ccs (5): ccs, ccs-beacon, ccs-front, ccs-scanner, ccs-sys
  elementic (5): elementic-api, elementic-engine, ...
  ...
Confirmar operação em TODO o servidor? [y/N]

Em terminal, pergunta. Em cron ou script, exige --yes — sem ela, aborta.

Breaking na v2.80.0. Orquestradores que chamavam runner deploy-all sem --yes passam a receber erro em contexto não-interativo. Acrescente a flag.

O motivo: deploy --all ganhou gate, e deixar este sem criaria um bypass — bastaria trocar de comando. Os dois chamam o mesmo executor.

Não use deploy-all --force como recuperação de incidente. Ele rebuilda tudo sem cache e um app saudável pode reprovar num gate de segurança — foi o que aconteceu com o cdn-rembg em 19/08/2026. Para recuperar, deploye app por app.

Sintaxe 

runner deploy-all [--yes] [--force] [--verbose] [--json]
Flag Default Descrição
-y, --yes false Confirma sem perguntar. Obrigatório em cron/script quando o servidor tem mais de um projeto
-f, --force false Força redeploy mesmo se a versão já está rodando
-V, --verbose false Logs detalhados
--json false Output JSON

Ordem de deploy

Topological sort por depends_on no .deploy.yml de cada app. Se app B depende de A:

  1. A é deployada primeiro
  2. Espera A ficar healthy (per depends_on.condition)
  3. B começa
  4. Se A falhar, B (e qualquer dependente) é skippada

Apps sem depends_on: são deployadas em ordem alfabética.

Qual instância de cada app é deployada (v2.55.1+)

Para cada app, a instância é resolvida nesta ordem — a primeira que existir vence:

Prioridade Consulta Fonte
1 state.instance state do registro (/opt/runner/state/<app>.yml), fixado por runner add --instance <N>
2 default do manifesto .deploy.yml: production se declarada, senão a primeira instância
3 production (literal) fallback quando o manifesto não declara instâncias

Mesma resolução do runner deploy e do runner fetch --deploy (v2.55.1+). Antes, deploy --all ignorava o passo 1 e mirava sempre o default do manifesto de cada app.

Sem production e sem state.instance, o passo 2 usa a primeira instância declarada no .deploy.yml (determinístico desde a v2.55.2). Ainda assim, declare production ou registre com --instance para deixar explícito.

Exemplos 

# Deploy padrão de todas as apps
runner deploy-all

# Forçar redeploy (mesmo versão já rodando)
runner deploy-all --force

# JSON pra CCS / orquestrador
runner deploy-all --json

Output JSON 

{
  "action": "deploy_all",
  "success": true,
  "deployed": 3,
  "failed": 0,
  "timestamp": "2026-05-15T..."
}

deployed = apps que atualizaram (versão mudou ou --force). failed = apps cujo deploy falhou. success é false se failed > 0.

Diferença vs `runner fetch --deploy`

Aspecto deploy-all fetch --deploy
Quando usar Operador / dashboard pedindo deploy Cron job automático
Order Topological (depends_on) Pelo timestamp de fetch
Force Sim (--force) Não — só deploya se mudou
Output JSON conciso (success/counts) Detalhado por app

Use deploy-all quando você QUER forçar/garantir que tudo esteja na última versão. Use fetch --deploy no cron pra deploy automático passivo.

Quem chama isso

  • CCS dashboard: action runner_deploy_all
  • MCP: tool runner_deploy_all
  • Scripts de bootstrap: runner deploy-all --force --json | jq .

Veja também

By Borlot.com.br on 15/05/2026

Tags

deploy lifecycle cli