flowchart TD accTitle: Worker GitHub Actions Pipeline accDescr { This repo now has one guarded Worker pipeline for pull requests and post-merge Cloudflare deploys. } A["Pull request"] --> B["Worker Pipeline PR job"] B --> C["Install deps and immutable test guard"] C --> D["Type checks and regression tests"] D --> E["Local AI Wrangler config generation"] E --> F["Merge guard conditions verified"] F --> G{All checks pass?} G -->|No| H["PR blocked"] G -->|Yes| I["Worker Pipeline passes"] I --> J["Push to main"] J --> K["Deploy jobs run"] K --> L["Validate required secrets / variables"] L --> M["Generate configs with local AI first"] M --> N["Deploy shards + controller to Cloudflare"] N --> O["Manual workflow_dispatch allowed"] O --> P["CI re-run before manual deploy"] K --> Q["Workflow manifest blocks unauthorized edits without override"] Q --> R["Branch protection requires required checks"]

Worker GitHub Actions Pipeline

This repo now has one guarded Worker pipeline for pull requests and post-merge Cloudflare deploys.

What runs on every pull request

The Worker Pipeline workflow runs on pull requests into main or master and must pass before merge:

Install Worker and Controller dependencies with npm ci.
Run the legacy immutable-test guard.
Run the Worker pipeline immutable guard.
Verify the pipeline workflow still has PR tests, protected deploy gating, Cloudflare secrets, local-AI deploy settings, and shard deployment concurrency.
Generate and verify local-AI Wrangler configs.
Type-check the Worker.
Type-check the Controller.
Run the local-AI deployment lock regression.
Run the fully mocked offline Worker E2E regression.

What deploys after merge

After a PR merges into main or master, the same workflow runs the full CI job again. The Deploy Workers to Cloudflare job starts only after CI passes and only on a push to main or master.

The deploy job does this:

Validates required GitHub secrets are present.
Generates production Wrangler shard configs with local AI first and OpenAI fallback enabled.
Deploys all generated Worker shards to Cloudflare, five at a time.
Deploys the controller Worker to Cloudflare.

Required GitHub secrets

Add these in GitHub → repo → Settings → Secrets and variables → Actions:

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID
NUTSNEWS_SECRETS_STORE_ID
NUTSNEWS_KV_NAMESPACE_ID
LOCAL_AI_URL

Optional secrets:

NUTSNEWS_KV_PREVIEW_NAMESPACE_ID
LOCAL_AI_API_KEY_SECRET_NAME

Optional repository variables:

ENABLE_UPSTASH_REDIS_SECRET_BINDING
UPSTASH_REDIS_REST_URL_SECRET_NAME
UPSTASH_REDIS_REST_TOKEN_SECRET_NAME
ENABLED_SUMMARY_LANGUAGES
SUMMARY_TRANSLATION_LIMIT
HOLD_ARTICLES_FOR_TRANSLATIONS

Immutable tests policy

Rami’s rule: tests and deployment guardrails are non-modifiable unless explicitly approved.

The new guard uses .github/worker-pipeline-immutable.manifest and blocks edits to these files after the first PR lands:

.github/workflows/worker-pipeline.yml
scripts/check_worker_pipeline_immutable.mjs
scripts/verify_worker_pipeline_config.mjs
scripts/deploy_worker_shards.mjs
.github/worker-pipeline-immutable.manifest

Only set NUTSNEWS_APPROVE_PIPELINE_TEST_CHANGES=true after Rami explicitly approves a test or pipeline guardrail change.

Branch protection to turn this into an enforced gate

In GitHub branch protection, make Worker Pipeline / Worker pipeline tests a required status check for main or master.

That is the part that makes GitHub block merges when someone removes or bypasses the workflow. Without branch protection, the workflow still runs, but GitHub will not force maintainers to wait for it.

Manual deploy

You can still run the deploy pipeline manually from GitHub Actions with workflow_dispatch. Manual runs execute the CI job first. The deploy job is intentionally limited to push events on main or master, so use a merge to deploy production.

Primary diagram