Modularized Workflow Toggles in GitHub Actions: Cutting CI/CD Run Time Without Losing Control

The Problem: Every Push Runs Everything, and It’s Killing Your Feedback Loop

The most expensive CI failure isn’t a flaky test — it’s running the full pipeline on a commit that changed two lines in README.md. A typical monolithic .github/workflows/ci.yml queues lint, unit tests, integration tests, Docker build, push to registry, deploy to staging, and a Slack notification for every single push to every branch. That setup makes sense for exactly one scenario: your first week before you have enough complexity to care. After that, it’s billing you for work that produces zero signal.

The operator cost is concrete. GitHub-hosted runners bill per minute, and a full pipeline that takes 18 minutes on a docs-only commit is 18 minutes of pure waste — multiplied by every engineer pushing WIP commits. On a self-hosted runner, the billing is electricity and thermal load on hardware you own. My local runner sits on the same workstation running Ollama inference; a needless Docker multi-stage build competes with whatever model is warming up. Idle CPU cycles aren’t free when the machine has a day job. The waste isn’t abstract — it shows up in slower feedback, higher costs, and runners that are busy when you actually need them.

The fix isn’t splitting into a dozen separate workflow files and maintaining them all independently. That trades one problem for another — diverging logic, copy-pasted steps, and no single place to audit what actually runs. The better model is workflow toggles: a combination of workflow_dispatch inputs, path-based conditionals, reusable workflows called with workflow_call, and matrix include/exclude blocks that let you dial exactly what executes based on who triggered the run, what changed, and what the target environment is. A push to a feature branch with only docs/** changes should run spell-check and nothing else. A manual dispatch with deploy: true should run the full chain. The same YAML, scoped by context.

This kind of conditional orchestration is one layer of a broader automation stack. If you’re thinking about where CI toggles fit alongside event-driven pipelines, webhook triggers, and cross-system workflows, the guide on Workflow Automation in 2026: n8n, Zapier, and Self-Hosted Pipelines covers the wider space and is worth reading alongside this one.

The Three Toggle Mechanisms Worth Understanding

The mechanism most developers reach for first — workflow_dispatch boolean inputs — is also the one most often misused. It gives you explicit, human-readable control over which stages run, and it works equally well when called via the GitHub API for programmatic triggers. The YAML is straightforward, but the if expression syntax trips people up because it’s not quite standard boolean comparison:

on:
  workflow_dispatch:
    inputs:
      run_deploy:
        description: "Deploy to production after build"
        type: boolean
        default: false
      target_env:
        description: "Target environment"
        type: choice
        options:
          - staging
          - production
        default: staging

jobs:
  deploy:
    runs-on: ubuntu-latest
    # inputs.run_deploy returns the string "true", not boolean true —
    # the == 'true' comparison is intentional, not a bug
    if: inputs.run_deploy == 'true'
    steps:
      - name: Deploy
        run: ./scripts/deploy.sh ${{ inputs.target_env }}

That string-vs-boolean distinction catches everyone once. The type: boolean declaration makes the UI render a checkbox, but the value arrives in if expressions as the string 'true' or 'false'. Use == 'true', not == true. Also worth knowing: if you trigger the same workflow via push (not workflow_dispatch), inputs.run_deploy evaluates to empty string, which means every if: inputs.run_deploy == 'true' gate silently skips — that’s usually what you want, but only if you intended it.

Path filters solve a different problem: not “should this stage run” but “should this workflow run at all given what changed.” If your monorepo has a docs/ directory and a src/ directory, there’s no reason a markdown edit should trigger your full build and test matrix. The paths filter handles this at the trigger level, before any job ever starts:

on:
  push:
    branches: [main, "release/**"]
    paths:
      - "src/**"
      - "packages/**"
      - ".github/workflows/ci.yml"  # workflow changes should always re-run
    paths-ignore:
      # paths-ignore and paths are mutually exclusive — pick one per trigger
      # listed here only for documentation; remove if using paths above
      - "docs/**"
      - "*.md"
      - ".gitignore"

One gotcha: paths and paths-ignore are mutually exclusive on the same trigger block. If you mix them, GitHub silently drops one. Use paths with an allowlist or paths-ignore with a denylist — not both. Also include the workflow file itself in your paths allowlist, otherwise a change to the CI config won’t trigger a run, which makes debugging infuriating.

Reusable workflows via workflow_call are the mechanism that actually enables modular composition at scale. The pattern is an orchestrator workflow that conditionally calls sub-workflows based on job-level if conditions:

# .github/workflows/orchestrator.yml
on:
  workflow_dispatch:
    inputs:
      run_integration_tests:
        type: boolean
        default: false

jobs:
  build:
    uses: ./.github/workflows/build.yml
    # no condition — build always runs

  integration:
    needs: build
    # only call the expensive sub-workflow when explicitly requested
    if: inputs.run_integration_tests == 'true'
    uses: ./.github/workflows/integration-tests.yml
    with:
      node_version: "20"
    secrets: inherit

  deploy:
    needs: [build, integration]
    # needs: integration — but integration might be skipped.
    # result == 'skipped' must be handled or this job never runs.
    if: |
      always() &&
      needs.build.result == 'success' &&
      (needs.integration.result == 'success' || needs.integration.result == 'skipped')
    uses: ./.github/workflows/deploy.yml
    secrets: inherit

That always() + skipped-result pattern in the deploy job is the part nobody documents. If a needs dependency was skipped, GitHub marks the dependent job as skipped too — automatically, without running your if condition. The only escape is wrapping the condition in always() and explicitly allowing 'skipped' as an acceptable upstream result. These three mechanisms also interact in ways that compound quickly: a path filter can suppress the trigger entirely so workflow_dispatch inputs never exist; a skipped upstream job breaks naive needs chains; and an orchestrator calling a reusable workflow can’t inspect the sub-workflow’s internal job results, only its overall conclusion. Document which toggles are active and why at the top of every orchestrator workflow — a three-line comment block saves an hour of trace-reading two weeks later.

Building the Toggle Layer: A Real Orchestrator Workflow

The most counter-intuitive part of building a toggle layer isn’t the boolean inputs — it’s what happens downstream when a job gets skipped. GitHub Actions’ default needs: behavior treats a skipped upstream job the same as a failed one, which means your entire pipeline silently dies the moment you flip a toggle off. That gotcha alone has caused more broken pipelines than any misconfigured secret. Fix that first, build the rest around it.

Here’s the full orchestrator skeleton. Four boolean inputs, all defaulting to false so a bare workflow_dispatch trigger does nothing unless you explicitly opt in:

name: Orchestrator

on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      run_lint:
        description: "Run linting"
        type: boolean
        default: false
      run_test:
        description: "Run tests"
        type: boolean
        default: false
      run_build:
        description: "Run build"
        type: boolean
        default: false
      run_deploy:
        description: "Run deployment"
        type: boolean
        default: false

jobs:
  lint:
    # On push, always lint. On manual dispatch, only if toggled on.
    if: github.event_name == 'push' || inputs.run_lint
    uses: ./.github/workflows/lint.yml
    secrets: inherit

  test:
    # Same dual-trigger pattern — push always runs, dispatch checks the toggle.
    if: github.event_name == 'push' || inputs.run_test
    needs: lint
    # This is the critical fix: accept 'skipped' as a valid upstream state.
    # Without this, skipping lint kills test even when lint was intentionally off.
    if: |
      (github.event_name == 'push' || inputs.run_test) &&
      (needs.lint.result == 'success' || needs.lint.result == 'skipped')
    uses: ./.github/workflows/test.yml
    secrets: inherit

  build:
    needs: [lint, test]
    if: |
      (github.event_name == 'push' || inputs.run_build) &&
      (needs.lint.result == 'success' || needs.lint.result == 'skipped') &&
      (needs.test.result == 'success' || needs.test.result == 'skipped')
    uses: ./.github/workflows/build.yml
    secrets: inherit

  deploy:
    needs: [build]
    if: |
      (github.event_name == 'push' || inputs.run_deploy) &&
      (needs.build.result == 'success' || needs.build.result == 'skipped')
    uses: ./.github/workflows/deploy.yml
    secrets: inherit

The github.event_name == 'push' || inputs.run_lint pattern does real work here. On a push to main, all four stages run unconditionally — the toggles are irrelevant. On a manual workflow_dispatch, each stage is opt-in. One YAML file covers both the automated path and the surgical “just redeploy” path a developer needs at 11pm. The alternative — separate YAML files for manual vs automated — sounds clean until you have to keep them in sync across three months of changes.

The needs: chaining deserves more attention than the docs give it. When you write needs: lint and lint gets skipped, GitHub marks the downstream job as skipped too, without evaluating its if: condition at all — unless you’ve written that condition to handle the skipped result explicitly. The exact pattern that actually works:

# This handles three valid upstream states: job ran and passed,
# job was skipped by toggle, or job doesn't exist in this event context.
if: |
  needs.lint.result == 'success' || needs.lint.result == 'skipped'

Do not use if: always() as a blanket fix here. always() will run the downstream job even when the upstream genuinely failed, which destroys your failure signal. The needs.X.result == 'skipped' check is surgical — it unblocks the toggle path while preserving real failure propagation. For the deploy job specifically, you want to be even stricter: if build failed (not skipped), deploy should never run regardless of toggles. The condition above handles that correctly because a real failure returns 'failure', not 'skipped'.

Reusable Workflows as the Toggle Target: Structure and Secrets Passing

The part most teams get wrong first: they treat reusable workflows like shared bash scripts — useful, but dumb. The workflow_call trigger makes them something closer to typed function signatures. When you define inputs and secrets blocks directly in the called workflow file, that file becomes self-documenting in a way that a raw composite action or a script-with-args pattern never quite achieves. The orchestrator that calls it is forced to satisfy a contract. That’s the actual value — not code reuse, but enforced interface boundaries between your pipeline stages.

Here’s a minimal deploy.yml that accepts an environment choice and inherits secrets from the caller:

# .github/workflows/deploy.yml
on:
  workflow_call:
    inputs:
      environment:
        description: "Target deployment environment"
        type: choice
        options:
          - staging
          - production
        required: true
    # secrets: inherit is the shortcut — the called workflow sees everything
    # the caller has access to, without you explicitly naming each secret.
    # Use it during early development or when the secret set is stable and
    # well-understood. Switch to explicit mapping before the workflow is
    # called from more than one orchestrator with different secret scopes.
    secrets:
      inherit

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: ./scripts/deploy.sh
        env:
          # secrets.DEPLOY_KEY is available because of secrets: inherit
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
          TARGET_ENV: ${{ inputs.environment }}

The secrets: inherit shortcut is convenient but carries a real tradeoff: it implicitly grants the called workflow access to every secret visible in the calling context, including ones it has no business touching. If your orchestrator has PROD_DATABASE_URL and STRIPE_SECRET_KEY in scope and you call a build workflow that only needs REGISTRY_TOKEN, you’ve silently over-permissioned it. Explicit secret mapping is more verbose but documents exactly what’s being passed:

# in the orchestrator (caller):
jobs:
  call-deploy:
    uses: ./.github/workflows/deploy.yml
    with:
      environment: production
    secrets:
      DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
      # Only DEPLOY_KEY crosses the boundary. Nothing else.

The output mechanism is where reusable workflows stop feeling like isolated scripts and start behaving like pipeline stages with return values. A called workflow can surface data back to the orchestrator via workflow_call.outputs mapped from a job’s outputs. The pattern that actually matters in practice: a build workflow that pushes a container image emits the immutable digest, and the deploy workflow consumes it — so you’re never deploying “latest” by accident, you’re deploying a specific SHA-pinned artifact.

# in build.yml (called workflow)
on:
  workflow_call:
    outputs:
      image_digest:
        description: "The pushed image digest (sha256:...)"
        value: ${{ jobs.build.outputs.digest }}

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        id: push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.sha }}
      # docker/build-push-action emits `digest` as a step output automatically

# in orchestrator.yml (caller consuming the output)
jobs:
  build:
    uses: ./.github/workflows/build.yml

  deploy:
    needs: build
    uses: ./.github/workflows/deploy.yml
    with:
      environment: staging
      image_digest: ${{ needs.build.outputs.image_digest }}

The nesting limitation is the sharp edge that trips up anyone who tries to build a genuinely modular pipeline from reusable workflows. As of current GitHub Actions behavior, a called workflow cannot itself call another reusable workflow. The chain is flat: orchestrator calls workflow A, and workflow A cannot then call workflow B as a reusable workflow — it would have to inline those steps or trigger them through a separate mechanism. The documentation uses language about composability that implies deeper nesting works, but it doesn’t. The practical consequence is that your orchestrator ends up owning more coordination logic than feels clean, and “reusable” workflows max out at one level of abstraction. If you find yourself wanting to compose two called workflows together, the honest answer is to either inline the second one into the first, or use composite actions (which can nest) for the leaf-level step logic and reserve reusable workflows for the job-level orchestration boundary.

Matrix Toggles: Scoping Environments and Platforms Dynamically

The most underused feature in GitHub Actions matrix configuration is treating the matrix itself as a runtime input rather than a static list baked into the workflow file. Instead of commenting out environments or maintaining a dozen nearly-identical workflow files, you can pass a JSON array through workflow_dispatch and let the matrix expand dynamically at runtime. The entry point looks deceptively simple:

on:
  workflow_dispatch:
    inputs:
      target_envs:
        description: 'JSON array of target environments'
        required: false
        default: '["staging"]'
        type: string

jobs:
  deploy:
    runs-on: ubuntu-22.04
    strategy:
      matrix:
        env: ${{ fromJson(inputs.target_envs) }}
    steps:
      - name: Deploy to ${{ matrix.env }}
        run: ./scripts/deploy.sh --env ${{ matrix.env }}

The default of '["staging"]' matters: it means a bare trigger with no inputs filled in still produces a valid single-vector matrix rather than blowing up the job. When you need to hit production and canary simultaneously, you pass ["production","canary"] through the dispatch UI or the API payload. No branch gymnastics, no hardcoded job duplicates. The fromJson() call is doing the heavy lifting — it converts the string input into an actual array that the matrix engine can iterate over.

Once you have dynamic environments, you’ll want certain steps to fire only for specific ones. That’s where matrix.include and conditional step guards work together. A common pattern: smoke tests should only run against production because staging data is inconsistent and you don’t want false alarms blocking the pipeline:

jobs:
  deploy:
    runs-on: ubuntu-22.04
    strategy:
      matrix:
        env: ${{ fromJson(inputs.target_envs) }}
        include:
          # Attach extra config only when env is production
          - env: production
            run_smoke: true
          - env: staging
            run_smoke: false
    steps:
      - name: Deploy
        run: ./scripts/deploy.sh --env ${{ matrix.env }}

      - name: Smoke Tests
        if: matrix.run_smoke == true
        run: ./scripts/smoke.sh --env ${{ matrix.env }}

matrix.include here acts as a lookup table — it attaches the run_smoke flag to each matrix cell based on the environment value. The step-level if condition then reads that flag. One gotcha: if you pass an environment that has no matching include entry, the variable is undefined rather than false — so write your if guard as matrix.run_smoke == true rather than != false, or you’ll get unexpected step execution when new environments get added to the input array without a corresponding include entry.

Now the sharp edge: pass an empty array ([]) and the job fails immediately with “matrix must define at least one vector” — no graceful skip, just a red job. This happens more than you’d expect when upstream logic generates the input programmatically and produces an empty result set. The fix is a job-level guard that runs before the matrix ever expands:

jobs:
  # Gate job: check if the matrix input is non-empty before expanding
  matrix-guard:
    runs-on: ubuntu-22.04
    outputs:
      has_targets: ${{ steps.check.outputs.has_targets }}
    steps:
      - id: check
        run: |
          ENVS='${{ inputs.target_envs }}'
          COUNT=$(echo "$ENVS" | jq 'length')
          echo "has_targets=$([ "$COUNT" -gt 0 ] && echo 'true' || echo 'false')" >> $GITHUB_OUTPUT

  deploy:
    needs: matrix-guard
    if: needs.matrix-guard.outputs.has_targets == 'true'
    runs-on: ubuntu-22.04
    strategy:
      matrix:
        env: ${{ fromJson(inputs.target_envs) }}
    steps:
      - name: Deploy to ${{ matrix.env }}
        run: ./scripts/deploy.sh --env ${{ matrix.env }}

The matrix-guard job uses jq length to count array elements and publishes a boolean output. The deploy job’s if condition reads that output via needs.matrix-guard.outputs.has_targets and skips the entire job — including matrix expansion — when the array is empty. This means the workflow shows as skipped rather than failed, which is the correct behavior when “no environments selected” is a valid state, not an error condition.

Self-Hosted Runner Considerations When Using Toggles

The thermal angle gets overlooked almost entirely in CI documentation. On a self-hosted runner that shares hardware with other services — say, an Ollama inference server or an n8n Docker stack — a job that runs but does nothing still consumes queue slots, spins up the runner process, and generates heat from the CPU doing bookkeeping. A toggle that skips the job entirely at the workflow level means the runner never receives the job assignment. That’s not a minor optimization; on a machine where the GPU is already warm from LLM inference, preventing an unnecessary CUDA context initialization from a build job genuinely matters.

Tagging Runners by Capability, Not Just “Self-Hosted”

The default advice — slap runs-on: self-hosted on everything — causes real pain once you have more than one runner or more than one job type. The fix is capability labels. When you register a runner, you assign labels during setup or via the GitHub UI. A GPU-equipped machine gets [self-hosted, gpu, linux]. A lightweight runner on a cheap VPS gets [self-hosted, linux]. Then your workflow targets labels with intent:

jobs:
  docs-lint:
    # Docs linting has zero reason to touch the GPU runner.
    # This label set will never match the gpu-tagged machine.
    runs-on: [self-hosted, linux]
    if: ${{ inputs.run_docs_lint == 'true' }}
    steps:
      - uses: actions/checkout@v4
      - run: npx markdownlint-cli2 "**/*.md"

  model-eval:
    # Only dispatched to the machine that actually has CUDA available.
    runs-on: [self-hosted, gpu, linux]
    if: ${{ inputs.run_model_eval == 'true' }}
    steps:
      - uses: actions/checkout@v4
      - run: python eval/run_benchmarks.py

A docs-lint job will never queue on your GPU runner because GitHub Actions requires all specified labels to match. This is the label-as-capability-gate pattern — you’re not just routing, you’re enforcing resource access at the dispatch layer. Combined with a toggle that skips model-eval entirely when you’re pushing a docs change, the GPU runner stays free for the work that actually needs it.

Concurrency Controls on Top of Toggles

Toggles prevent unneeded types of jobs from running. Concurrency controls prevent the same job from stacking when someone triggers workflow_dispatch twice in a row, or when a push and a manual dispatch land close together. These two concerns are orthogonal and both need to be in the config. The group key should encode both the branch ref and the specific toggle inputs so that a deploy-enabled dispatch doesn’t cancel a non-deploy dispatch on the same branch:

jobs:
  deploy:
    runs-on: [self-hosted, linux]
    if: ${{ inputs.run_deploy == 'true' }}
    concurrency:
      # Group key ties together: the workflow name, the branch, and whether deploy is on.
      # Two deploy runs on main will cancel-and-replace each other.
      # A deploy run and a lint-only run are in different groups and don't interfere.
      group: ${{ github.workflow }}-${{ github.ref }}-deploy-${{ inputs.run_deploy }}
      cancel-in-progress: true
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

Without inputs.run_deploy in the group key, a lint-only run (where run_deploy is false) and a full deploy run can cancel each other out — which is not what you want. The group key needs to be specific enough that only genuinely redundant runs collapse.

The Idle Timeout Phantom Offline Problem

This one doesn’t appear in the GitHub Actions runner docs prominently, but you’ll hit it within a week of running toggles on a self-hosted setup managed by PM2 or systemd. When a skipped job ends immediately — because every step is gated by an if condition that evaluates false — the runner completes the job in seconds and goes idle. If your runner’s idle timeout is shorter than the interval between jobs, the GitHub Actions service marks the runner as offline. You then see phantom “offline” states in the Settings → Actions → Runners panel, and queued jobs fail to dispatch.

Two practical fixes. First, use the ACTIONS_RUNNER_HOOK_JOB_COMPLETED environment variable to fire a keepalive or logging script at the end of every job — this resets the runner’s internal idle clock. Second, and simpler: bump the idle timeout in the runner’s .env file before starting the service:

# In the runner's root directory: .env (create if not present)
# Default idle timeout is 50 seconds in older runner versions.
# Bump it to avoid phantom offline during toggle-heavy workflows.
RUNNER_IDLE_TIMEOUT=300

# If using the job-completed hook instead, point it at a no-op keepalive:
ACTIONS_RUNNER_HOOK_JOB_COMPLETED=/opt/actions-runner/hooks/keepalive.sh

#!/bin/bash
# /opt/actions-runner/hooks/keepalive.sh
# Called by the runner after every job completes.
# Exists purely to produce a log line and reset the idle clock.
echo "[$(date -u +%Y-%m-%dT%H:%M:%SZ)] job completed hook fired, runner staying warm"

The hook approach is more surgical — it doesn’t change idle behavior globally, just ensures the runner signals activity after every job regardless of how fast it finished. On a PM2-managed runner, make sure the hook script is executable and the PM2 process has the env variable set in its ecosystem config, not just in the shell where you ran pm2 start. Environment variables set in the shell are not inherited by PM2 processes started at boot unless they’re declared in ecosystem.config.js or the .env file the runner process reads on startup.

When This Pattern Breaks Down (and What to Use Instead)

The silent green run is the most dangerous failure mode in toggle-based workflows. A new contributor runs gh workflow run ci.yml accepting all defaults, every input defaults to false, the workflow completes in 8 seconds with a green checkmark, and nothing actually ran. The fix is a required summary job that always executes and explicitly asserts that at least one stage was enabled — treat it like a guard clause, not an afterthought:

sanity-check:
  runs-on: ubuntu-latest
  needs: [lint, test, build, deploy]
  if: always()
  steps:
    - name: Assert at least one stage ran
      run: |
        # Fails the workflow if every toggle was false
        if [[ "${{ inputs.run_lint }}" == "false" && \
              "${{ inputs.run_test }}" == "false" && \
              "${{ inputs.run_build }}" == "false" && \
              "${{ inputs.run_deploy }}" == "false" ]]; then
          echo "::error::All stages disabled — this run did nothing. Enable at least one toggle."
          exit 1
        fi

For monorepos, toggles are often the wrong tool entirely. If what you actually need is “run the backend job only when files under services/api/ changed,” you’re modeling a path-scoping problem as an input problem. Native paths: triggers in GitHub Actions apply at the workflow level, not the job level — you can’t say “trigger this job but not that one based on which files changed.” The third-party action dorny/paths-filter fills that gap by outputting per-path boolean signals you can consume in job if: conditions. The tradeoff is a real one: you’re adding a dependency on a third-party action with its own release cadence, and you’re coupling your job graph to a paths-filter step that must run first. Worth it for a true monorepo with three or more distinct service roots; not worth it if your “monorepo” is two packages sharing a lockfile.

# dorny/paths-filter approach — jobs respond to actual file changes
- uses: dorny/paths-filter@v3
  id: changes
  with:
    filters: |
      api:
        - 'services/api/**'
      frontend:
        - 'apps/web/**'

# Then in a downstream job:
build-api:
  needs: changes
  if: needs.changes.outputs.api == 'true'

A more subtle signal that the pattern is collapsing: you’ve written a script to decide which toggle values to pass to the workflow. The moment decision logic lives inside a shell script or composite action that computes inputs for another workflow, the workflow is no longer the source of truth — it’s just an executor with a confusing interface. That logic belongs in an orchestrator. On my setup, this lands in n8n: a webhook receives the trigger event, a Function node evaluates branch name, changed paths, PR labels, and environment targets, then calls the GitHub API to dispatch the workflow with explicit inputs already resolved. The workflow itself stays dumb — it receives concrete boolean inputs and executes exactly what it’s told. A small Node.js script via the Octokit REST client works equally well if n8n feels heavy for the use case.

There’s also a hard architectural ceiling: workflow_dispatch inputs are capped at 10 per workflow in the current GitHub Actions spec. If you’re at 8 toggles and considering adding more, that’s not a configuration problem — it’s a signal the workflow has accumulated too many responsibilities. The right move at that boundary is decomposition: split into multiple focused workflows (ci-quality.yml, ci-build.yml, ci-deploy.yml) called via workflow_call, each with their own narrow input surface. The toggle pattern works well in the range of 3–6 inputs for a single workflow; beyond that, you’re managing complexity with more complexity.

---

---