Distillation

Date: Aug 3, 2026

• 🔴 (21:07) User stated the CI poller always adds ci-ready after checking CI; the publish workflow must therefore trigger only on a fresh ci-ready labeled event, not directly on accepted.
• 🔴 (21:07) User stated release approval should always require a second person, analogous to code review, rather than allowing the release owner to self-approve.
• 🔴 (21:07) User stated Cloudflare Pages releases must always land on production; productionBranch is the Cloudflare environment selector, distinct from Craft’s git release branch.
• 🔴 (21:07) User stated configuration values must never be expanded into secrets; strings matching environment-variable expansion syntax such as ${CLOUDFLARE_API_TOKEN} must be rejected before being passed to Wrangler.
• 🔴 (21:07) User stated an API-sourced value that looks like an environment-variable expansion must never reach Wrangler arguments.
• 🟡 (21:07) User asked whether release repository owners should be able to publish by directly running the workflow or must use the approval workflow.
• 🟡 (21:07) User asked whether release owners should still create a publishing issue even when approving their own release, or whether a second-person approval should always be required.
• 🟡 (21:07) User asked how much friction the issue-and-approval workflow would cause.
• 🟡 (21:07) User asked whether approval authority should be restricted by release and how that restriction should work.
• 🟡 (21:07) User asked whether exposing all tokens to all authorized personnel is acceptable.
• 🟡 (21:07) The Publish workflow listens to issues.labeled, uses issue-title concurrency groups with cancel-in-progress: false, and grants contents: read, issues: write, and packages: write.
• 🟡 (21:07) The waiting-for-ci job runs on ubuntu-latest in the production environment only when an open issue receives the accepted label and its title starts with publish: . It obtains a GitHub App token via actions/create-github-app-token@v3, using vars.SENTRY_INTERNAL_APP_ID and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY.
• 🟡 (21:07) The accepted-label path resets labels by removing ci-failed and ci-ready, then adding ci-pending; it enables the poller with CI_POLLER_HAS_PENDING=true, comments on the issue, and triggers the poller immediately rather than waiting for the next cron tick.
• 🟡 (21:07) The publish job runs on ubuntu-latest in the production environment with a 90-minute timeout and requires an open issue event where the label is ci-ready, labels include both accepted and ci-ready, and labels exclude ci-pending and ci-failed.
• 🟡 (21:07) The publish job sets SENTRY_DSN to https://303a687befb64dc2b40ce4c96de507c5@o1.ingest.sentry.io/6183838 and checks out repository contents with actions/checkout@v6 into .__publish__.
• 🟡 (21:07) CloudflareTargetConfig defines deployType ("worker" or "pages"), optional Pages projectName, optional productionBranch, required wranglerCliPath, optional workingDir, and optional accountId.
• 🟡 (21:07) Cloudflare deployment supports two paths: Workers deployment and Pages deployment; a broad generic “Workers” permission would be overprivileged because the paths require distinct permissions.
• 🟡 (21:07) For Pages, projectName is required when deployType is pages; productionBranch is passed to wrangler pages deploy --branch and must exactly match the server-side production branch, because a mismatch silently deploys to preview.
• 🟡 (21:07) When productionBranch is omitted, the target reads the project’s production branch from the Cloudflare API so the release deploys to production; accountId is an identifier rather than a secret and is forwarded to Wrangler when set.
• 🟡 (21:07) Configuration validation rejects projectName, productionBranch, or workingDir when a string matches ENV_EXPANSION_REGEX, preventing spawnProcess() from expanding config values against an environment containing CLOUDFLARE_API_TOKEN or CLOUDFLARE_ACCOUNT_ID.
• 🟡 (21:07) Cloudflare API production-branch resolution treats an API production_branch matching ENV_EXPANSION_REGEX as suspicious, logs a warning, omits --branch, and relies on Wrangler’s production default; a normal branch is logged and returned, while a missing branch also omits --branch with a warning.
• 🟡 (21:07) Implementation planning identified documentation/setup updates for the publish repository, exact Cloudflare worker permissions, and verification of the Wrangler version used by the Docker package as remaining work.
• 🟡 (21:07) Permission investigation distinguished Pages deployment permission Account → Cloudflare Pages → Edit from Worker deployment permission Account → Workers Scripts → Edit; additional Wrangler read-call scopes were still being verified.