Lint wrangler.jsonc in GitHub Actions Before You Deploy

A valid Wrangler file can still deploy the wrong environment, omit a binding, reuse production state, or commit a value that should be a secret. Put the configuration check next to your build so the pull request shows the risky line before anyone runs a production deploy.

The smallest FlareCheck workflow is two steps: check out the repository, then run the Action.

name: Check Worker configuration

on:
  pull_request:
  push:
    branches: [main]

jobs:
  flarecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: loke-dev/flarecheck@v0.9.0

Start with annotations, not another dashboard

GitHub workflow commands can attach warnings and errors to a file and line. FlareCheck uses that native format, so a finding appears on the Wrangler file instead of being buried in raw logs. Each annotation includes the stable rule ID, the consequence, a suggested fix, and the supporting documentation.

The reusable Action enables strict mode by default. Errors fail the workflow, and warnings fail it too. That is useful for a new project. For an existing repository, start with a focused rule set rather than adding a check everyone immediately learns to ignore.

- uses: loke-dev/flarecheck@v0.9.0
  with:
    path: apps/api
    only: FC003,FC005,FC008,FC009

Check the config behavior a build cannot prove

Cloudflare documents bindings and environment variables as non-inheritable. A root D1, KV, R2, service, or vars declaration does not automatically appear inside a named environment. FC005 compares each environment with the root binding categories and points at an omission.

Declaring a binding is only half the review. A staging environment can declare DB and still point at the production database. FC008 compares stateful resource identities between production and non-production environments. FC009 checks that every named environment in a routed project states its own route, routes, or workers.dev target.

The rule reference lists all nine checks with examples, fixes, severity, and links to the relevant Cloudflare docs. Rule selection stays explicit through only and ignore inputs.

Choose the failure policy deliberately

Use strict mode when every warning must block a merge. Set strict to false when you want annotations without failing on warnings. Errors still return a failing exit code.

- uses: loke-dev/flarecheck@v0.9.0
  with:
    strict: false
    ignore: FC002

Keep the exception visible in the workflow and leave a short comment explaining why the rule does not apply. A temporary ignore is easier to remove than a warning buried inside a long shell command.

Scan every Worker in a monorepo

Set all to true when a repository contains several Wrangler projects. FlareCheck discovers each configuration below the selected path, skips common generated directories, annotates findings against the correct file, and reports an aggregate result.

- uses: loke-dev/flarecheck@v0.9.0
  with:
    path: apps
    all: true

Add SARIF when you want code scanning history

GitHub accepts SARIF 2.1.0 from third-party analysis tools and turns supported results into code scanning alerts. Use the upload-sarif Action after generating the file. This is a separate choice from pull request annotations. Start with annotations, then add SARIF if the repository benefits from Security-tab history and triage.

permissions:
  contents: read
  security-events: write

steps:
  - uses: actions/checkout@v6
  - name: Generate FlareCheck SARIF
    run: npx flarecheck --sarif > flarecheck.sarif
    continue-on-error: true
  - name: Upload FlareCheck results
    uses: github/codeql-action/upload-sarif@v4
    with:
      sarif_file: flarecheck.sarif

The generation step continues after findings so the upload still runs. The uploaded file contains rule metadata, severity, locations, suggested fixes, and stable fingerprints. GitHub Code Scanning availability depends on the repository type and plan, so keep the annotation workflow as the baseline.

Run the same check locally

The Action runs the public npm package. That keeps local and CI behavior aligned, and it means the check does not need a Cloudflare account or upload source code to a service.

npx flarecheck
npx flarecheck --list-rules
npx flarecheck . --all --strict

Install FlareCheck from GitHub Marketplace or inspect the rules, fixtures, and reporter source before adding it to a protected branch. The useful check is the one your team can understand, reproduce, and change deliberately.