CI & verdict — laravel-workers docs

The tool decides, the reporter publishes, your pipeline schedules. The split is why a green check means something specific.

Three layers

layer	what	owns
tool	`npx laravel-workers build` / `deploy` in your app	the verdict (`READINESS`)
reporter	`action/verdict` in this repository	one sticky PR comment + the job summary
pipeline	`ci.yml`/`deploy.yml` (yours) or the `app-*` workflows (ours)	when to run which

The canonical workflow

.github/workflows/ci.ymlyaml

name: ci
on:
  pull_request:
  push: { branches: [main] }

permissions:
  contents: read
  pull-requests: write
  issues: write

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      # ... php, node, npm ci, npm run build, cp .env.example .env
      - name: Random app_key (never production)
        run: |
          KEY="$(node -e 'process.stdout.write(require("crypto").randomBytes(32).toString("base64"))')"
          echo "APP_KEY=base64:${KEY}" >> "$GITHUB_ENV"
      - name: Edge build (--strict)
        run: |
          set -o pipefail
          npx laravel-workers build --no-cache 2>&1 | tee edge-build.log
      - name: Verdict
        if: always()
        uses: arfoux/laravel-workers/action/verdict@v1

Two details are not optional.--no-cache: a cache hit prints no READINESS block, so the reporter would read an empty log and call a green build BUILD FAILED. And avalid random APP_KEY: compiling error views boots Laravel, and a malformed key fails the build with Unsupported cipher or incorrect key length.

The reporter

action/verdict reads the log of build --no-cache (or ofdeploy) and publishes one comment plus the job summary. It is fork-safe, always exits 0, and never hides a gap.

input	default	meaning
log	edge-build.log	the build (or deploy) log to read
comment	true	`false` keeps the summary and skips the comment — the merge case

### Verdict: RUNS WITH DECLARED GAPS

2 declared gaps — your decision, and they ship
  GET /health    ignored in registry.json
  GET /internal  ignored in registry.json

  what an ignored route does at the edge: the request reaches no handler
  and the platform answers 404. Laravel itself still serves it everywhere else.

The reusable workflows

If your app matches the defaults, skip the copying. These are trigger-agnostic: call them frompull_request, push or workflow_dispatch.

.github/workflows/app.ymlyaml

jobs:
  check:
    uses: arfoux/laravel-workers/.github/workflows/app-check.yml@v1
    permissions: { contents: read, pull-requests: write, issues: write }

  ship:
    if: github.ref == 'refs/heads/main'
    uses: arfoux/laravel-workers/.github/workflows/app-deploy.yml@v1
    secrets: inherit
    with:
      app-url: https://my-app.example.workers.dev

app-check.yml assumes a normal Laravel app with package-lock.json and.env.example; it takes php-version, node-version,working-directory, build-args, lint, tests.app-deploy.yml takes app-url (required), mode,schema and needs APP_KEY + CLOUDFLARE_API_TOKEN secrets and CLOUDFLARE_ACCOUNT_ID. Neither runs composer: deploy provisions the vendor tree itself. They encode assumptions, so the documented pattern is the contract — fork them if your app deviates.

Pin the action

Pin @v1 — a moving major tag updated on release — or pin a full commit sha when you want the reporter to be unable to change under you between runs. The workflows and the action are published together with the npm package, so @v1 always matches a releasedlaravel-workers.