GitHub Actions "Unable to interpret 'X' as boolean"
Keys such as continue-on-error and a workflow_dispatch boolean input expect a real boolean. An expression that evaluates to an arbitrary string (for example the literal text "true ") fails strict boolean coercion.
What this error means
A boolean-typed key fails with a message naming the offending value, usually after an input or expression produced a quoted or padded string instead of true/false.
Error: Unable to interpret 'yes' as a boolean.Diagnose it: print the context before you change anything
Most workflow-expression bugs are not syntax errors, they are an expression reading something that is empty. GitHub resolves a missing property to an empty string instead of failing the run, so a wrong reference looks like a logic bug rather than a mistake. Dump the contexts first and you will usually see the answer immediately.
- name: Dump contexts
run: |
echo '--- github ---' ; echo '${{ toJSON(github) }}'
echo '--- needs ---' ; echo '${{ toJSON(needs) }}'
echo '--- steps ---' ; echo '${{ toJSON(steps) }}'
echo '--- matrix ---' ; echo '${{ toJSON(matrix) }}'
echo '--- inputs ---' ; echo '${{ toJSON(inputs) }}'Check the context is allowed where you used it
Contexts are not available everywhere. The same expression can be valid in a step if and invalid in a job if, which is why an expression that works in one workflow fails when moved.
| Where you wrote it | Contexts available there |
|---|---|
run-name | github, inputs, vars |
concurrency | github, inputs, vars |
Top-level env | github, secrets, inputs, vars |
jobs.<id>.if | github, needs, vars, inputs |
jobs.<id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs |
jobs.<id>.outputs | Full access, including secrets |
Reusable workflow outputs | github, jobs, vars, inputs |
Common causes
Expression returns a string, not a boolean
An input default like 'true' is a string; some keys reject it where a literal true is required.
Non-boolean literal supplied
Values like yes/no/1/0 are not booleans to the expression engine.
How to fix it
Produce a real boolean expression
- Compare to get a boolean: \${{ inputs.flag == 'true' }}.
- Declare workflow_dispatch inputs with type: boolean so they arrive as true/false.
- Avoid quoting boolean literals in keys that expect them.
on:
workflow_dispatch:
inputs:
deploy:
type: boolean
default: false
jobs:
ship:
if: ${{ inputs.deploy }}
runs-on: ubuntu-latest
steps:
- run: echo "deploying"Catch it before it reaches CI
Every failure in this cluster is statically detectable. actionlint parses workflow expressions, checks context availability against the same rules above, and validates needs references, so these bugs never need to cost you a run.
# one-off
docker run --rm -v "$(pwd):/repo" --workdir /repo rhysd/actionlint:latest -color
# as a job, before anything expensive runs
- uses: actions/checkout@v4
- run: |
bash <(curl -s https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
./actionlint -colorHow to prevent it
- Use type: boolean for dispatch inputs that gate jobs or steps.
- Coerce strings to booleans with an explicit == comparison.