build(web): Workers Static Assets, because Cloudflare stopped offering Pages projects - #332
Merged
Merged
Conversation
…g Pages projects
`wrangler pages deploy` refused with
✘ [ERROR] The Pages project "polyemesis" does not exist.
and there is no longer a supported way to create one. Cloudflare's dashboard
"create" flow builds a Worker; its "Upload your static files" option there is
Workers Static Assets, not Pages. So the choice was not Pages-versus-Workers on
merit -- one of the two can still be created.
The migration is small because the hard part does not exist here. Pages
Functions are what make this migration painful, and astro.config.mjs sets
output: "static": no functions/ directory, no _worker.js, no _routes.json, no
middleware, no routing file to reconcile.
pages_build_output_dir = "./dist" -> [assets]
directory = "./dist"
plus a pinned compatibility_date, which a Worker requires and a Pages project
does not. Pinned rather than floating: it is the runtime contract, and one that
moved on its own would change behaviour with no commit to point at.
`not_found_handling = "404-page"` is new and is not decoration -- a static
site's 404 is a page, Astro emits 404.html, and the default would answer an
unknown path with an empty body. Verified web/dist/404.html exists.
THE GUARD MOVED WITH IT, and one detail of that is worth reading. It identified
the publish step by `strings.Contains(s.Run, "pages deploy")`. The new run block
still CONTAINS that string, inside a comment explaining why it no longer uses
it -- so a loose match would find the comment, call it the publish step, and
pass. It now matches the full command.
Verified: `wrangler deploy --dry-run` reads 27 files from web/dist. Both halves
of the guard proven able to fail -- deleting the publish command, and pointing
assets.directory at a directory the build does not produce.
Nothing about the site changes. Same files, same output directory, same
credential gate, same refusal to publish from a pull request.
There was a problem hiding this comment.
Pull request overview
This PR migrates the web deploy configuration from Cloudflare Pages to Cloudflare Workers Static Assets after Pages project creation is no longer available, while preserving guardrails that ensure the workflow deploys the same directory the build produces.
Changes:
- Switch
wrangler.tomlfrompages_build_output_dirto Workers Static Assets[assets]configuration and add a pinnedcompatibility_date. - Update the GitHub Actions publish step from
wrangler pages deploytowrangler deploy. - Update the deploy-guard test to find the new assets directory field and to identify the publish step by the full command.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| web/wrangler.toml | Move from Pages output-dir config to Workers Static Assets config and pin compatibility_date. |
| internal/testenv/pagesdeploy_test.go | Update guards to parse [assets].directory and to detect the new publish command reliably. |
| .github/workflows/pages.yml | Swap the publish command from Pages deploy to Workers deploy while keeping the gate behavior. |
Suppressed comments (1)
web/wrangler.toml:33
- The comment block still claims there should be no
compatibility_datebecause “a runtime does not exist”, but this PR now addscompatibility_datefor Workers Static Assets. This is contradictory and will mislead future edits/debugging; update the comment to reflect the current Workers configuration and rationale (no bindings, but compatibility_date required).
# NO compatibility_date, and no bindings. Those configure Pages *Functions*, and
# this site has none: astro.config.mjs sets output: "static", so a deploy is an
# upload of files and nothing runs per request. Adding a date here would suggest
# a runtime that does not exist.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+14
to
+18
| # WORKERS, NOT PAGES, AND NOT BY PREFERENCE. Cloudflare no longer offers Pages | ||
| # project creation in its dashboard -- the "create" flow builds a Worker, and | ||
| # "Upload your static files" there is Workers Static Assets. `wrangler pages | ||
| # deploy` refused with `The Pages project "polyemesis" does not exist` and there | ||
| # was no supported way to create one by hand. |
Comment on lines
+129
to
+133
| # `wrangler deploy`, not `wrangler pages deploy`. Cloudflare no longer | ||
| # offers Pages project creation in its dashboard -- its create flow | ||
| # builds a Worker -- and `pages deploy` refused with `The Pages project | ||
| # "polyemesis" does not exist` with no supported way to make one. See | ||
| # the header of web/wrangler.toml. |
Comment on lines
+112
to
+115
| // The Workers form. This read `pages_build_output_dir` until Cloudflare stopped | ||
| // offering Pages project creation; the field it replaces served the identical | ||
| // purpose, so the assertions below are unchanged in substance. | ||
| var pagesOutputDirRE = regexp.MustCompile(`(?ms)^\s*\[assets\].*?^\s*directory\s*=\s*"([^"]+)"`) |
…was wrong
Two corrections after reading Cloudflare's Astro and static-asset routing
guides, which I should have read before writing the migration rather than after.
HTML_HANDLING. Cloudflare defaults to `auto-trailing-slash`, which answers
/features with a redirect to /features/. astro.config.mjs sets
`build: { format: "file" }` and `trailingSlash: "never"` precisely to avoid
that, and says so: directory output "costs every internal navigation an extra
round trip for nothing". Taking the default would have reinstated, on every
page, the redirect the site is configured to avoid -- and the site would have
worked, so nothing would have reported it. Pinned to `drop-trailing-slash`.
THE OBSERVABILITY CLAIM WAS WRONG. The PR body cited Workers Logs and Logpush
as a gain over Pages. That comes from a general Pages-versus-Workers comparison
and does not apply here: this Worker has no `main`, so no code runs, and
Cloudflare's own routing doc says navigation requests to a static asset do not
invoke the Worker script at all. There is nothing to log. `[observability]`
would have been configuration that reads as a feature and does nothing, so it
is not being added and the claim is withdrawn instead.
Also confirmed rather than assumed: `_headers` IS honoured by Workers static
assets, same file, same location, so web/public/_headers carries over
unchanged. Its comment named Pages and now names what actually reads it.
The rest of the config is unchanged and matches Cloudflare's documented static
Astro path exactly -- no `main`, no @astrojs/cloudflare adapter, which their
guide states outright is not needed when Astro is used as a static site
generator.
Verified again after the change: build clean, 6 pages, `wrangler deploy
--dry-run` reads 27 files, deploy guard passes.
|
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.
wrangler pages deployrefused withThe Pages project "polyemesis" does not exist, and Cloudflare no longer offers a way to create one — its dashboard create flow builds a Worker, and the "Upload your static files" option there is Workers Static Assets.So this is not Pages-versus-Workers on merit. One of the two can still be created.
The migration is small because the hard part does not exist here. Pages Functions are what make this painful, and
astro.config.mjssetsoutput: "static"— nofunctions/, no_worker.js, no_routes.json, no middleware.not_found_handlingis not decoration: a static site's 404 is a page, Astro emits404.html, and the default answers an unknown path with an empty body.One guard detail worth reading. It identified the publish step by
strings.Contains(s.Run, "pages deploy"). The new run block still contains that string — inside a comment explaining why it no longer uses it. A loose match would have found the comment, called it the publish step, and passed. It now matches the full command.Verified:
wrangler deploy --dry-runreads 27 files fromweb/dist. Both guard halves mutation-proven — deleting the publish command, and pointingassets.directoryat a directory the build does not produce.