A kill switch only works if flipping it actually stops something, without anyone having to touch the pipeline itself. A flag check buried inside application code stops the running service, but it does nothing for a deploy that's already in flight in CI. By the time the new code is live, the flag came too late to matter for that rollout.
rollfuse's GitHub Action evaluates a flag as a step in the workflow itself. If the resolved variation doesn't match what you told it to expect, the step fails, and everything after it in the job never runs: no new commit, no redeploy, just flipping the flag off.
Adding it to an existing workflow
- name: Check deploys-enabled flag
uses: rollfuse/github-action@v1
with:
flag: "deploys-enabled"
credential: ${{ secrets.ROLLFUSE_CREDENTIAL }}
want-variation: "on"
Put this step before whatever it should gate: a deploy, a migration, a job that ships something. credential is a rollfuse Service Credential scoped to config:read, kept in a repository or environment secret, never a literal in the workflow file.
What happens on each run
The action evaluates flag against the credential's project and environment, using the same Node.js SDK (@rollfuse/sdk-js) your services can use, and compares the resolved variation to want-variation (defaults to "on"). If they match, the action exits 0 and the job continues. If they don't, it exits non-zero, and GitHub Actions stops the job there by default: nothing after that step runs.
The evaluation runs for the subject key ci unless you set the optional subject input, and you can pass targeting attributes as a JSON object in attributes. The gate also fails closed: if the rollfuse API can't be reached or the flag key doesn't exist, the step fails instead of letting the job through.
The action also exposes the evaluation as outputs (variation, reason, value, passed), so a later step in the same job can read the result without evaluating the flag a second time.
Why this beats a flag check inside the deploy itself
A flag check written into application code only protects the running service. It can't stop a deploy already underway in a pipeline that never asks. Putting the check in the workflow means the same flag that gates behavior in production also gates whether the pipeline is allowed to ship it, checked into version control alongside everything else the deploy does.
Your GitHub Actions workflow already knows when code ships. Now it can also ask, before it does, whether it's supposed to.