Migrate deployment to GitHub Pages

[Repiteo]

A (relatively) new feature to take advantage of on GitHub is the ability to deploy webpages directly via GitHub Actions¹. This means we no longer need gh-pages as a workaround; a site can be built and deployed within the same action. This eliminates a major annoyance of redundancy: the website no longer needs to be built/uploaded twice! While the redundant upload wasn't a concern for this repo, it absolutely would speed things up on the documentation & main site repositories.

Output logic can be observed on my fork through two actions: one for the default branch, and one on a standalone branch (the one used for this PR).

• Default branch: Both uploads the built website as an artifact AND deploys the website to GitHub Pages. Pushes/merges to our default branch will operate as they always have, albeit a fair bit faster.
• Standalone branch: Uploads the built website as an artifact, but does NOT deploy the website. The only branch that can deploy to the website is the default branch. This lets PRs have sanity-checks on their builds, but will never attempt a deployment.

The successfully deployed site on my repository can be viewed here. Note that my repository does not have a gh-pages branch², so this is all handled by the action.

Important

If this is approved, one adjustment to the settings must be made prior to merging: changing the website source from "Deploy from a branch" to "GitHub Actions". This is something I can actually achieve myself with the limited repository permissions I have available, but anyone with the power to do so can accomplish this

Footnotes

1. https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#publishing-with-a-custom-github-actions-workflow ↩

2. https://github.com/Repiteo/godot-interactive-changelog/branches ↩

[adamscott]

I'm curious about why removing branches from push (isn't any push to any branch would trigger the action?) and adding pull_request also.

[Repiteo]

(isn't any push to any branch would trigger the action?)

Nope! That's protected by this conditional in the deploy job:

    if: github.ref_name == github.event.repository.default_branch

This will only execute that job if the ref_name exactly matches the default branch's name. The only two conditions this will happen in are if the default branch recieves a push or a workflow run is activated on the default branch. All PRs (including ones from the default branch) and push/workflow_run from any non-default branch will only perform the build/artifact steps.

I included pull_request because we want to sanity-test incoming PRs, so that's allowed by default. Including workflow_dispatch is more niche, but it's for if a maintainer wants to manually initialize an action in a generic context (ex: something goes awry with the website and we need a re-deploy without a dummy push)