Um kill switch só funciona se acioná-lo realmente parar alguma coisa, sem que ninguém precise mexer na pipeline. Uma checagem de flag escondida dentro do código da aplicação para o serviço em execução, mas não faz nada por um deploy que já está em andamento no CI. Quando o novo código já está no ar, a flag chegou tarde demais para importar naquele rollout.
A GitHub Action do rollfuse avalia uma flag como um passo do próprio workflow. Se a variação resolvida não corresponder ao que você configurou como esperado, o passo falha, e tudo que vem depois dele no job nunca roda: sem novo commit, sem redeploy, só desligar a flag.
Adicionando a um workflow existente
- name: Check deploys-enabled flag
uses: rollfuse/github-action@v1
with:
flag: "deploys-enabled"
credential: ${{ secrets.ROLLFUSE_CREDENTIAL }}
want-variation: "on"
Coloque esse passo antes do que ele deve travar: um deploy, uma migração, um job que publica alguma coisa. credential é uma Service Credential do rollfuse, escopada para config:read, guardada em um secret de repositório ou ambiente, nunca um valor literal no arquivo do workflow.
O que acontece em cada execução
A action avalia flag contra o projeto e ambiente da credencial, usando o mesmo SDK de Node.js (@rollfuse/sdk-js) que seus serviços podem usar, e compara a variação resolvida com want-variation (o padrão é "on"). Se coincidirem, a action encerra com código 0 e o job continua. Se não coincidirem, ela encerra com código diferente de zero, e o GitHub Actions para o job ali por padrão: nada depois desse passo roda.
A avaliação usa a chave de sujeito ci, a menos que você preencha a entrada opcional subject, e você pode passar atributos de targeting como um objeto JSON em attributes. A trava também falha fechada: se a API do rollfuse não responder ou a chave da flag não existir, o passo falha em vez de deixar o job seguir.
A action também expõe a avaliação como outputs (variation, reason, value, passed), então um passo posterior no mesmo job pode ler o resultado sem avaliar a flag de novo.
Por que isso é melhor que uma checagem de flag dentro do próprio deploy
Uma checagem de flag escrita no código da aplicação só protege o serviço em execução. Ela não consegue parar um deploy que já está em andamento numa pipeline que nunca pergunta nada. Colocar a checagem no workflow faz com que a mesma flag que controla o comportamento em produção também controle se a pipeline tem permissão para publicá-lo, versionada junto com tudo que o deploy já faz.
Seu workflow do GitHub Actions já sabe quando o código vai ao ar. Agora ele também pode perguntar, antes disso acontecer, se ele tem permissão para isso.