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/github-pages-deploy-action@4.1.4 to deploy output to the gh-pages branch
  • Excludes pr/ folder from clean deployment
• pr.yml:
  • Uses JamesIves/github-pages-deploy-action@4.1.4 to deploy output to the gh-pages branch under pr/<number>
  • Generates a preview URL using https://tc39.es/<repository>/pr/<number>
  • Uses phulsechinmay/rewritable-pr-comment@v0.3.0 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?