Repository navigation
feat(ci): deploy to Cloudflare Pages on release publish - #7
Merged
Merged
Conversation
Adds a workflow gated on release: published only (no push, PR or dispatch) that builds the prerendered site and uploads build/client with a SHA-pinned wrangler-action. Documents the project name, domains and rollback in docs/deploy.md, linked from the README. Does not create the Cloudflare project, attach domains or touch DNS; that stays a manual dashboard step. Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
Contributor
Author
|
Approved. The site deploys to Cloudflare Pages only when a website release is published. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
Separate from the content PR (#6): this adds the workflow that actually puts a built release on
Cloudflare Pages. Nothing in this PR changes what happens on a push or a merged PR -- the new job
only fires on
release: published, so the site stays off the internet until I publish a releaseby hand, same as the no-tags-automatically rule everywhere else in this repo.
What it does, in order:
release: published(nopush,pull_request, orworkflow_dispatch).npm cithennpm run build(the same prerender CI alreadyruns on every PR).
build/client/to thecryptos-pki-wwwCloudflare Pages project withcloudflare/wrangler-action, pinned by full commit SHA (v4.1.3), using the org secretsCLOUDFLARE_API_TOKENandCLOUDFLARE_ACCOUNT_ID.It does not create the Cloudflare Pages project, attach
cryptos-pki.com/www.cryptos-pki.com,or touch DNS -- that's a one-time manual step in the Cloudflare dashboard, documented in
docs/deploy.mdalong with what goes live and when, and how to roll back (re-publish an olderrelease, or roll back from the Cloudflare dashboard's Deployments tab).
Permissions are
contents: readonly; this job doesn't needdeployments: writesince Wranglertalks to Cloudflare's API directly, not the GitHub Deployments API.
Verification
How this was verified
actionlint -shellcheck=on the new workflow file -- clean, no findings.npm run lint,npm run buildstill pass (lint shows the same pre-existing warning onhome.tsxthat's unrelated to this change and present onmain).cloudflare/wrangler-actiontagv4.1.3to its commit SHA via the GitHub API(tag object -> commit) rather than trusting a cached value, and double-checked it against
commits/v4.1.3.Pages project, both outside this PR's scope and this box's permissions. The build half of the
job is exactly what CI already runs on every PR; the deploy half is
wrangler-action's owntested code, only given different input values.
Refs #8
Closes #8