When I rebuilt my site, I implemented a Changelog page. I thought it'd be neat to make that information available on the site itself, for anyone to be able to see how the site has changed over time. The page is populated by pulling release info from the GitHub API during the build process, which meant I needed to have my site deployments happen after a release is published on GitHub in order for the build to include the latest release information.
Since this may be an uncommon use case or workflow, I thought it'd be worth sharing how I'm handling it.
Overview
Previously, I had Cloudflare Pages set up to do automatic deployments anytime a commit
is made to the main
branch. I ended up disabling that altogether, and instead set up a GitHub workflow that triggers a deployment when a release is published. You could use both methods together, but in my case, restricting it to only be triggered by new releases helps ensure I keep a well documented changelog.
Setting up the Workflow
The majority of the setup is handled by a GitHub Workflow. If you're new to workflows in GitHub, they're actions that are triggered by various events in your repository. In this case, when a release is published.
The GitHub docs dive much deeper into the technical details, so for the purposes of this, I'll skip all of that and cover how my workflow is set up.
A workflow file—which uses YAML syntax and a .yml
or .yaml
extension—needs to be created in the repository within a .github/workflows
directory at the root of the project. Here's what my workflow file looks like:
There are three top-level things this file is doing:
- Giving the workflow a friendly, descriptive
name
. - Defining which events the workflow should trigger
on
. In my case, it's being triggered when arelease
isreleased
, which happens when a release is published, or is changed from pre-release to release. There are various events that trigger workflows that can be used here, butreleased
covers my intent. - Defining the
jobs
that will run as part of the workflow. This workflow has one job, which is to trigger a webhook that fires off a site deployment. I created a simple GitHub action for triggering webhooks, which I'm using to handle that. The action is set up to send a request to the providedwebhook-url
, so I'm passing it a GitHub secret variable that's set to a Cloudflare Pages Deploy Hook URL.
Conclusion
With that workflow in place, I now have automatic site deployments happening when I publish a new release on GitHub. Thanks for reading, and please reach out to me if you have any questions, suggestions, or feedback.