Add branch previews of the website with cleanup on merge/close - #678
Add branch previews of the website with cleanup on merge/close#678Koroeskohr wants to merge 2 commits into
Conversation
|
env.BRANCH_NAME doesn't behave the way I thought it did, needs a tweak edit: done |
There was a problem hiding this comment.
I love this in principle (and would love to use it for my current PR), but I have a niggling security concern: are there ways in which someone could use this to hack our site?
Eg, is it possible that someone could:
- Create a malicious PR that reads in our secrets and exposes them on a page
- Open that PR against this repo
- This GHA creates and runs the branch automatically
- The attacker exfiltrates the secrets via that branch build
I'm by no means certain that this works, but it feels somewhat plausible to me, and that would probably kill this automatic-run idea if so.
We realised secrets are simply not accessible in fork-based pull requests. I modified this PR to introduce a dual-workflow approach: the |
This PR allows running branch previews of the website on pull requests, and delete the deployments on merge/close.
This was tested against my personal cloudflare account, both for the creation of the deployment and the cleanup on merge.
The Pages project was setup in the Typelevel cloudflare account, environment variables
CLOUDFLARE_ACCOUNT_IDandCLOUDFLARE_API_TOKENhave already been provisioned with the most minimal scope (Pages: edit) and added to this repo's secrets. I expect this to work as it, but you know, software development.I studied the alternative of plugging the git repository to the project in the Pages dashboard but it requires using one of the usual static pages project builders.
It is the first time I actually use Github Actions so feel free to point out things that look weird!
EDIT: this was updated to use a dual workflow setup: the pr-preview-deploy action that is run will use the version from the main branch even in branches. In PRs we instead simply build and upload the artifact, and let the second workflow (which is safe to run against forks because it cannot be edited) retrieve the artifact and upload it with the secrets.