From f5c466bd27f2bbcbfa082f7e55b4a1cfc980f0b9 Mon Sep 17 00:00:00 2001
From: Lars Weiser <lars@blackbrowedlabs.com>
Date: Wed, 13 May 2026 15:02:05 +0200
Subject: [PATCH] feat(ci): staging counterpart of rebuild-on-dispatch.yml
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Adds `.github/workflows/rebuild-on-dispatch-staging.yml`, mirroring the
existing production dispatch workflow but checking out `dev`, building
with `PUBLIC_ENVIRONMENT=staging`, and deploying via
`wrangler deploy --env staging`. A single `product-release-published`
dispatch from a product repo now refreshes both environments in
parallel.

Matches the per-environment-file convention already in place for
`rebuild-nightly.yml` / `rebuild-nightly-staging.yml` and
`deploy-production.yml` / `deploy-staging.yml`.

Note on routing: `repository_dispatch` workflows only fire from files
on the repo's default branch (`main`). This file becomes active only
after the next dev → main rollout — captured as a comment in the file
header.

Motivation: the bare-SemVer integration test on 2026-05-13 surfaced
that staging was not refreshed by product-release dispatches, so a new
release on a draft-only product (e.g. pipeline-test-fixture) required a
manual `workflow_dispatch` on deploy-staging.yml to verify on staging.
This closes that gap.

Co-Authored-By: Claude <noreply@anthropic.com>
---
 .../workflows/rebuild-on-dispatch-staging.yml | 58 +++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100644 .github/workflows/rebuild-on-dispatch-staging.yml

diff --git a/.github/workflows/rebuild-on-dispatch-staging.yml b/.github/workflows/rebuild-on-dispatch-staging.yml
new file mode 100644
index 0000000..0f09463
--- /dev/null
+++ b/.github/workflows/rebuild-on-dispatch-staging.yml
@@ -0,0 +1,58 @@
+name: rebuild-on-dispatch-staging
+
+# Mirrors rebuild-on-dispatch.yml on the same `product-release-published`
+# event, but builds from `dev` with PUBLIC_ENVIRONMENT=staging and deploys
+# via `wrangler deploy --env staging`. A single dispatch from a product
+# repo therefore refreshes both production and staging in parallel.
+#
+# Note on default-branch routing: `repository_dispatch` workflows only
+# fire from files on the repo's default branch (`main`). This file must
+# reach `main` via the periodic dev → main rollout before it begins
+# receiving dispatches.
+
+on:
+  repository_dispatch:
+    types: [product-release-published]
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true"
+
+permissions:
+  contents: read
+
+jobs:
+  rebuild:
+    name: Rebuild and deploy staging
+    runs-on: ubuntu-latest
+    steps:
+      - name: Log dispatch payload
+        run: |
+          echo "Dispatched by product: ${{ github.event.client_payload.productSlug }}"
+          echo "Tag: ${{ github.event.client_payload.tagName }}"
+
+      - name: Checkout dev
+        uses: actions/checkout@v6
+        with:
+          ref: dev
+
+      - name: Setup Node 24
+        uses: actions/setup-node@v6
+        with:
+          node-version: 24
+          cache: npm
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Build for staging
+        env:
+          PUBLIC_ENVIRONMENT: staging
+          PRODUCT_REPOS_PAT: ${{ secrets.PRODUCT_REPOS_PAT }}
+          PUBLIC_CWA_TOKEN: ${{ secrets.PUBLIC_CWA_TOKEN }}
+        run: npm run build
+
+      - name: Deploy to Cloudflare
+        uses: cloudflare/wrangler-action@v3
+        with:
+          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          command: deploy --env staging