# `runner canary`

Controla o scheduler de canary: o processo que sobe uma versao nova recebendo uma fatia pequena do trafego e vai aumentando essa fatia por etapas, em vez de trocar tudo de uma vez.

Este grupo opera o scheduler. Os comandos de trafego bruto — ver, fixar e promover peso — sao de primeiro nivel e estao em instances.

# Sintaxe

runner canary list
runner canary status <project> [-i <instance>]
runner canary history <project> [-i <instance>]
runner canary pause <project> [-i <instance>]
runner canary resume <project> [-i <instance>]
runner canary abort <project> [-i <instance>] [-r <motivo>]
runner canary promote <project> [-i <instance>]

# Subcomandos

# `pause` mantem o peso

pause nao volta o trafego para a versao estavel — congela onde esta. Se o canary esta em 25%, ele continua em 25% ate voce dar resume, abort ou promote. Para tirar o trafego da versao nova, o comando e abort.

# `history` e um contrato estavel

O history expoe a linha do tempo sob o envelope canary.history, feito para o sys consumir. Complementa o `logs history`, que cobre o deploy — este cobre a progressao de peso.

runner canary history meu-app -i production -o json

# `abort` aceita motivo

runner canary abort meu-app -i production -r "erro 500 em /checkout"

O -r, --reason fica registrado no historico. Vale a pena preencher: seis meses depois, "por que este canary foi abortado" e uma pergunta cara de responder sem isso.

# Flags

# `canary promote` vs `runner promote`

Os dois levam a versao a 100%, e a diferenca e o que eles conhecem:

Se ha um canary em curso, use canary promote — ele fecha o scheduler junto. Promover por fora deixa o scheduler ativo achando que ainda tem trabalho.

# Ver tambem

• instances — weights, weight, promote, versions
• `runner logs` — historico do deploy
• `runner rollback`