Skip to content

Add branch previews of the website with cleanup on merge/close - #678

Open
Koroeskohr wants to merge 2 commits into
typelevel:mainfrom
Koroeskohr:main
Open

Add branch previews of the website with cleanup on merge/close#678
Koroeskohr wants to merge 2 commits into
typelevel:mainfrom
Koroeskohr:main

Conversation

@Koroeskohr

@Koroeskohr Koroeskohr commented Aug 3, 2026

Copy link
Copy Markdown

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_ID and CLOUDFLARE_API_TOKEN have 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.

Comment thread .github/workflows/ci.yml Outdated
Comment thread .github/workflows/ci.yml Outdated
@Koroeskohr

Koroeskohr commented Aug 3, 2026

Copy link
Copy Markdown
Author

env.BRANCH_NAME doesn't behave the way I thought it did, needs a tweak

edit: done

@jducoeur jducoeur left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Koroeskohr

Copy link
Copy Markdown
Author

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 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants