ci: Deploy to Cloudflare using a Github Action#1159
Conversation
jderochervlk
force-pushed
the
vlk/cloudflare-workers
branch
from
7ed801e to
0273917
Compare
cometkim
left a comment
cometkim
left a comment
There was a problem hiding this comment.
Deploying via actions is good.
It would be helpful to migrate the pages project to a workers project immediately afterward.
The @cloudflare/pages-plugin-vercel-og project provides excellent support for dynamic OG using a combination of Satori and HTMLRewriter. Also, a change to the CDN cache configuration is required to reduce unnecessary function calls.
Why would we want to use workers? Wouldn't pages be best for the static content? |
…nto vlk/cloudflare-workers
Cloudflare deploymentDeployement ID: 3842c61e-331d-4bac-86c4-e791e3e5ae26 ⛅️ wrangler 4.61.1 ✨ Uploading _redirects |
3 participants
This PR switches builds over from being configured in the Cloudfront dashboard to a Github action, which means it's now Infrastructure as Code. We can now also use a Github action to manually fire off a build, which is nice. Having this happen on a Github action will give us access to the deployment URL, which will be needed if we want to setup Playwright or Chromatic for automated testing (which would be great!).
This also tested out an example Cloudflare function, which you can see at https://d0b34a60.rescript-lang.pages.dev/echo?foo=bar. This doesn't mean that the app is using SSR, but Cloudflare pages can still have access to functions, which I plan on using to create dynamic open graph images. The function has been removed after testing. I wanted to make sure that Cloudflare could handle
.jsxfiles.This also changes some of the commands used for builds and development to simplify things. Now you can run
yarn devto kick off concurrent builds for ReScript, Vite, and Wrangler (which will be used to develop functions locally).The existing Cloudflare job is expected to fail and will need to be removed alongside of merging in this PR (probably right before).