# `runner preflight`

Roda as checagens de prontidao que ja acontecem antes de um deploy e as agrega num relatorio unico — manifesto, secrets, portas, DNS e argumentos de imagem — com verde/amarelo/vermelho por componente. Nao sobe container nenhum.

O exit code so e diferente de zero quando o status geral e vermelho (problema bloqueante). Amarelo passa. Isso e o que permite CI e o Deploy Wizard do CCS gatearem em cima dele sem quebrar por avisos.

# Dois modos

O modo repo clona para um tempdir, opcionalmente escreve o .deploy.yml gerado pelo wizard (via stdin), roda as mesmas checagens e limpa tudo — sem registrar, sem commitar, sem deployar. E o que permite validar um manifesto antes de ele existir.

De exatamente um dos dois: <app> ou --repo + --branch. Sao mutuamente exclusivos.

# Hosts internos que não resolvem (v2.160.0+)

O componente rede olha as envs que citam um host de nome curto. Entram as que têm forma de URL (http://muxally-sys:5000) e as *_HOST/*_HOSTNAME. Para cada host, confere se ele é nome ou alias de algum container numa das redes da app.

● rede   SYS_INTERNAL_URL → "muxally-sys" não resolve(m) em nenhuma rede deste
         container [public, mysql, redis]. Redes compartilhadas não recebem
         network_aliases: ponha as duas apps numa rede do projeto e declare o
         alias lá.

É só aviso: o deploy segue, e o mesmo aviso aparece no log do deploy. FQDN, IP, localhost e template não resolvido ({{::Var}}) ficam de fora. Para corrigir, veja Container não resolve sibling.

# Identidade do registro (v2.152.0+)

No modo app registrada, o relatório abre com o componente identidade: o que o próximo deploy vai usar, antes de agir.

preflight: minha-api-b
  ● identidade   staging-b (registro) · projeto minha-api-b
                 instancia        staging-b
                 origem_instancia registro
                 projeto          minha-api-b
                 cofre            .runner/secrets.staging-b.enc
                 esquema_cofre    v2
                 container        minha_api_b_staging_b_v1-2-0
                 routers          minha-api-b-staging-b
                 dominios         b.exemplo.com.br
                 branch           dev-b

Em -o json, os campos vêm em components[].dados do componente identidade.

• Vermelho quando a instância do registro não existe no manifesto.
• Amarelo quando o registro não fixa a instância e o manifesto declara mais de uma. A resolução depende da ordem do bloco instances:, e reordená-lo muda domínio e cofre em silêncio. A correção é runner edit <app> -i <instância>.

Desde a v2.152.0, as checagens de roteamento usam a instância do registro, e não production.

# Diferença de env (v2.197.0+)

O componente env_drift compara o que o manifesto declara com o valor em uso no .env/.secrets da app. Quando fica amarelo, o texto de sempre continua em detail, e -o json traz também components[].dados:

{
  "vence": ".env/.secrets",
  "itens": [
    {
      "chave": "SITE_URL",
      "tipo": "valor",
      "manifesto": "{{::URL do site?https://docs.exemplo.com.br}}",
      "manifesto_padrao": "https://docs.exemplo.com.br",
      "runtime": "https://app.exemplo.com.br",
      "mascarado": false
    }
  ]
}

Verde não traz dados.

# Sintaxe

runner preflight <app>
runner preflight <app> --json
runner preflight --repo acme/app --branch main --json
cat gen.deploy.yml | runner preflight --repo acme/app --branch dev --manifest-stdin --json

# Flags

# Semantica do exit code

Gatear CI em preflight e seguro justamente porque amarelo nao derruba o pipeline.

# Preflight vs validate vs doctor

# Ver tambem

• `runner validate`
• `runner doctor`
• `runner wizard`