Skip to content

feat(pages): add Cloudflare acceptance deploy and release-gated production#181

Open
DevSecNinja wants to merge 2 commits into
mainfrom
feat/pages-cloudflare-acceptance
Open

feat(pages): add Cloudflare acceptance deploy and release-gated production#181
DevSecNinja wants to merge 2 commits into
mainfrom
feat/pages-cloudflare-acceptance

Conversation

@DevSecNinja

Copy link
Copy Markdown
Owner

What

Adds two opt-in inputs to the reusable Pages workflow so callers can run a
Cloudflare Pages acceptance environment on every main commit while
reserving production for release events.

New inputs (all default false/safe — fully backward compatible)

Input Default Purpose
cloudflare-acceptance false Deploy every production-branch commit to a stable Cloudflare branch alias (acceptance URL).
cloudflare-acceptance-branch acceptance Cloudflare branch name used for the acceptance deploy.
cloudflare-production-on-release false Deploy Cloudflare production only on GitHub release events instead of on every production-branch commit.

How it works

  • main pushdeploy-cloudflare-acceptance runs (stable acceptance URL via --branch=<acceptance-branch>). Production is skipped when cloudflare-production-on-release: true because the ref is a branch, not a release.
  • release: publisheddeploy-cloudflare-production runs. Acceptance is skipped because the ref is a tag, not the production branch.

Because acceptance (push to branch) and release-gated production (release event)
are triggered by different events, no mutual-exclusion logic is needed — they
never run in the same workflow run.

detect-cloudflare now also treats acceptance as a reason Cloudflare is
"enabled", and the missing-secrets error fires when either production or
acceptance is requested.

Backward compatibility

Both new inputs default to false. With defaults unchanged:

  • cloudflare-production keeps its existing "deploy on every production-branch push" behavior.
  • No acceptance job runs.

Consumer follow-up (separate change)

To actually use release-gated production + acceptance, a caller must:

  1. Add a release: { types: [published] } trigger to its on:.
  2. Set cloudflare-acceptance: true and cloudflare-production-on-release: true.
  3. Bump the pinned reusable-workflow ref to the release that includes this PR.

Validation

  • actionlint ✅ (pages.yml + workflow-templates/pages.yml)
  • yamllint
  • dprint check ✅ (docs/architecture.md table re-aligned)

Docs (docs/architecture.md inputs table) and the workflow-templates/pages.yml
comment block are updated to mention the new inputs.

…ction

Add an opt-in 'cloudflare-acceptance' deploy that publishes every
production-branch commit to a stable Cloudflare branch (default 'acceptance'),
and 'cloudflare-production-on-release' so production deploys only on GitHub
release events instead of every main commit. Both default to false, so
existing callers are unaffected. Acceptance reuses the production build path
and requires Cloudflare secrets (same as production).
Comment thread .github/workflows/pages.yml Fixed
Collapse the duplicated deploy-cloudflare-production and
deploy-cloudflare-acceptance jobs into a single deploy-cloudflare job driven
by a matrix that detect-cloudflare computes per event (only the targets that
should actually deploy are included, so no empty/protected environment runs).
Disable the package-manager cache on the deploy job to resolve the zizmor
cache-poisoning alert on published artifacts.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants