Suggestion: PR Preview Github Action Workflows

[rbuckton]

I noticed the proposal template repo has a build.yml github action. I recently wrote something similar for https://github.com/tc39/proposal-class-static-block that might be a useful improvement:

• build.yml:
  • Uses JamesIves/[email protected] to deploy output to the gh-pages branch
  • Excludes pr/ folder from clean deployment
• pr.yml:
  • Uses JamesIves/[email protected] to deploy output to the gh-pages branch under pr/<number>
  • Generates a preview URL using https://tc39.es/<repository>/pr/<number>
  • Uses phulsechinmay/[email protected] to post a comment to the PR with a link to the generated preview:
    

By publishing to gh-pages you don't need to check in the docs folder (which can be safely added to .gitignore), which makes PR diffs easier to read.

NOTE: This does not currently do any kind of automatic pruning generated PR outputs, so that the links in a PR remain working. Pruning stale PR renders is a manual process that can be done by deleting PR-specific subfolders under the pr folder in the gh-pages branch using the GitHub UI.

[ljharb]

PR diffs shouldn't be difficult to read currently, since the html file is marked as autogenerated per https://github.com/tc39/template-for-proposals/blob/main/.gitattributes#L1, so any diff is collapsed.

That said, I do like the deploy approach!

For PRs, I'm not sure about auto-deploying PRs to proposal repos, since proposal authors might not always be vigilant about keeping spam or inappropriate content out of them, and since closing a PR wouldn't automatically prune it. However, it seems like it'd be possible to add a workflow_run action that triggers on closed or merged PRs that auto-cleaned up the PR preview?

Either way, let's start with just the build.yml change for now, and we can iterate from there?

[bakkot]

I'm not sure about auto-deploying PRs to proposal repos, since proposal authors might not always be vigilant about keeping spam or inappropriate content out of them

You have to manually approve jobs from first-time contributors, I think, which should basically eliminate that problem, right?

[ljharb]

Maybe we could use https://pkg.pr.new instead of pushing commits to git? If so, I'd take a PR :-)

[bakkot]

https://pkg.pr.new/ appears to be for npm packages, not webpages, from what I can tell? Which is neat but does not fulfill the same function.

[ljharb]

ah, you're right :-/

[rbuckton]

I don't think there's much harm in pushing to gh-pages. It's what it's there for, and proposals don't get anywhere near as much churn as other repos.