GitHub Actions Boolean Input Runs When False? Use the inputs Context

Define the deploy decision as a boolean#

workflow_dispatch lets a workflow expose typed inputs in the Actions UI. For an operation that writes to a deployment environment, make the decision explicit and default it to false:

1
name: Manual deploy
2

3
on:
4
  workflow_dispatch:
5
    inputs:
6
      deploy:
7
        description: 'Deploy the current ref?'
8
        required: true
9
        default: false
10
        type: boolean
11
      environment:
12
        description: 'Target environment'
13
        required: true
14
        type: environment
15

16
jobs:
17
  deploy:
18
    if: ${{ inputs.deploy }}
19
    runs-on: ubuntu-latest
20
    environment: ${{ inputs.environment }}
21
    steps:
22
      - uses: actions/checkout@v4
23
      - run: ./scripts/deploy.sh

GitHub documents boolean and environment as supported workflow_dispatch input types. The workflow file must be on the repository’s default branch before the manual trigger is available. If this is a production workflow, keep the environment protections and permissions in the same review—not in a later cleanup.

Why github.event.inputs can run the wrong branch#

Both contexts receive the submitted values, but their types differ. inputs.deploy remains a Boolean; github.event.inputs.deploy becomes the string 'true' or 'false'.

1
jobs:
2
  safe-deploy:
3
    if: ${{ inputs.deploy }}
4
    runs-on: ubuntu-latest
5
    steps:
6
      - run: ./scripts/deploy.sh
7

8
  unsafe-deploy:
9
    if: ${{ github.event.inputs.deploy }}
10
    runs-on: ubuntu-latest
11
    steps:
12
      - run: ./scripts/deploy.sh

In the second job, a non-empty string is not the same thing as the Boolean value false. The practical result is a condition that is harder to reason about and easy to copy into a deployment workflow by mistake. GitHub’s workflow syntax reference explicitly distinguishes the two contexts and calls out Boolean preservation in inputs.

If you inherit a workflow that cannot switch contexts immediately, compare the event value as a string instead of relying on its truthiness:

1
if: ${{ github.event.inputs.deploy == 'true' }}

That is a compatibility measure, not the preferred shape for new manually triggered workflows.

Pick the condition by input source#

The right expression depends on where the value came from. Do not treat every value named deploy as a Boolean.

GitHub’s expression rules list false, empty strings, zero, and null as falsy. The string 'false' is not on that list: it is a non-empty string. That distinction explains why this condition can select a job even though the Actions form showed a cleared checkbox:

1
if: ${{ github.event.inputs.deploy }}

Use fromJSON() only at a boundary where you genuinely receive a string, such as an environment variable or step output. Do not add conversion around inputs.deploy; it is already a Boolean.

Keep strings at the command boundary#

Shell environment variables are strings, even when the expression that supplies one came from a Boolean input. Put the typed decision in the job or step if; pass values to a command only after the job is already selected.

1
jobs:
2
  deploy:
3
    if: ${{ inputs.deploy }}
4
    runs-on: ubuntu-latest
5
    steps:
6
      - name: Deploy selected environment
7
        env:
8
          TARGET_ENVIRONMENT: ${{ inputs.environment }}
9
        run: ./scripts/deploy.sh "$TARGET_ENVIRONMENT"

This separates two jobs that are often confused: the expression decides whether deployment is permitted to run, while the shell variable supplies an argument to a command that is already running. Treating a shell variable as the source of the deploy decision brings the string-conversion problem back.

Reproduce the type difference without deploying#

Before attaching a real deploy command, add a temporary job that prints both values through toJSON(). The JSON form makes the type difference visible: the typed context prints false, while the event context prints "false".

1
jobs:
2
  inspect-inputs:
3
    runs-on: ubuntu-latest
4
    steps:
5
      - name: Show submitted input objects
6
        run: |
7
          printf 'inputs.deploy=%s\n' '${{ toJSON(inputs.deploy) }}'
8
          printf 'github.event.inputs.deploy=%s\n' '${{ toJSON(github.event.inputs.deploy) }}'

With the checkbox clear, the relevant output shape is:

1
inputs.deploy=false
2
github.event.inputs.deploy="false"

Run the workflow twice from the Actions tab—once with the checkbox clear and once selected. This verifies both branches without executing a deployment. Then remove the diagnostic job or keep it limited to non-sensitive input names. Do not print secrets or assume GitHub masks every value that merely resembles a secret.

If this manual workflow builds a static Astro site before deployment, Dockerize an Astro Static Site: Build dist, Serve It with Caddy shows a reproducible build-and-serve boundary. Keep that build step behind the same typed deploy gate.

The decision is mechanical: use inputs.deploy when the workflow owns a typed input, compare github.event.inputs.deploy with 'true' only for compatibility, and convert string boundaries explicitly. A cleared checkbox must produce a Boolean false at the condition that guards deployment.

FAQ#