Runs e aprovação · Firstlume Docs

Um run é uma execução de plan, apply, destroy ou drift de um stack. Cada fase roda no seu próprio Job do Kubernetes, e o apply executa exatamente o que o plan produziu.

Ciclo de vida de um run

queued ─▶ planning ─┬─▶ no_changes                       (sem mudanças)
                    ├─▶ planned                          (type=plan)
                    ├─▶ awaiting_approval ─┬─▶ apply_queued ─▶ applying ─▶ applied
                    │                      └─▶ discarded
                    ├─▶ apply_queued                     (sem exigir aprovação)
                    └─▶ drifted                          (type=drift)
qualquer fase em execução ─▶ failed  |  queued/apply_queued ─▶ canceled

Dispare um run com o tipo:

curl -s -H "$H" $O/stacks/$ST/runs -d '{"type": "plan"}'

Os tipos são plan, apply, destroy e drift. Veja em Seu primeiro run como definir $H, $O e $ST.

Fila e lock

Só um run por vez executa ou aguarda aprovação em cada stack. Os demais esperam na fila, em ordem de chegada. A UI mostra em todas as telas os runs ativos da organização, com destaque para os que esperam aprovação.

O apply roda o que foi planejado

O plan grava o commit SHA e o arquivo de plano, criptografado no banco. O apply faz checkout desse commit e aplica esse arquivo. Ele também usa as variáveis do plan e o config.yaml daquele commit. Mudar as variáveis de uma pasta entre o plan e o apply não afeta este run.

Se o state mudou depois do plan, o próprio Terraform recusa o plano salvo e o run falha. Nesse caso, planeje de novo.

Revise as mudanças

A partir da saída estruturada do plan, o Firstlume lista as mudanças por recurso:

curl -s -H "$H" $O/runs/$RUN/changes | jq .

A página do run agrupa nesta ordem, com contagem por grupo:

Vai ser deletado
Vai ser recriado
Vai ser atualizado
Vai ser criado

Cada item mostra o endereço, o tipo e os atributos que mudam. Uma recriação mostra o atributo que a força, e o resumo conta recriações separadas: 1 delete · 1 replace · 2 update · 2 create. Valores marcados como sensíveis aparecem como (sensitive) e nunca vão para a API nem para a UI. No Terragrunt run --all, cada mudança também indica a unit.

O log completo continua disponível na visão de Logs, ao vivo.

Aprovação

A aprovação é uma configuração herdada, require_approval, e é exigida por padrão. Defina na organização, numa pasta ou num stack, pela UI ou pela API de configurações. A regra é lida quando o plan termina.

curl -s -X POST -H "$H" $O/runs/$RUN/approve -d '{"acknowledged": []}'
curl -s -X POST -H "$H" $O/runs/$RUN/discard

Hoje, qualquer membro da organização pode aprovar. Aprovadores por pessoa ou grupo estão planejados.

Confirmar cada exclusão ou recriação

confirm_destructive é uma configuração herdada, desligada por padrão. Quando ligada:

cada recurso que vai ser deletado ou recriado ganha uma caixa de confirmação na UI, e o botão de aprovar só libera com todas marcadas
o servidor também confere: a aprovação é recusada com 409 se faltar algum desses endereços em acknowledged
os endereços confirmados ficam registrados no run, junto com quem aprovou

Acompanhe o apply

Durante e depois do apply, cada recurso da lista mostra o seu estado:

Estado	Significado
`pending`	aprovado, ainda não começou
`applying`	rodando
`done`	terminou
`failed`	falhou, com o erro do Terraform no recurso
`not_applied`	o apply terminou antes de ele começar, o que só acontece quando outro recurso falhou

Um recurso not_applied vem no próximo plan. Uma recriação mostra as duas etapas, na ordem em que rodaram. Os estados vêm da saída do próprio Terraform (apply -json), e o log continua em texto legível. Um erro que não pertence a nenhum recurso, como uma falha de provider ou de autenticação, vira o erro do run.

O que cada run mostra

Passos: checkout, init, plan, aprovação, apply e assim por diante, cada um com status, duração e o próprio log
Commit: autor, primeira linha da mensagem e link para o commit no Git
Configuração usada: o config.yaml do commit, as configurações efetivas e os nomes das variáveis, cada um com a origem. Segredos ficam ocultos
State: qual backend cada unit usou

Quando um run falha

Se o executor parar de enviar heartbeat por FIRSTLUME_HEARTBEAT_TIMEOUT (10 min por padrão, controlPlane.heartbeatTimeout no Helm), o run é marcado como failed. Se o pod morrer, por exemplo por OOM ou deadline, o agent reporta a falha.

Cancelar

Runs na fila (queued, apply_queued) podem ser cancelados. Cancelar um run em execução não é suportado, de propósito: interromper um apply pode corromper o state.