Automating Site Deployments Using GitHub Releases

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.


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:

name: Deploy to Cloudflare Pages on New Release
    types: [released]
    name: Trigger Cloudflare Pages Deploy Hook
    runs-on: ubuntu-latest
      - uses: 1ockwood/simple-webhook-trigger-action@v1
          webhook-url: ${{ secrets.CF_DEPLOY_HOOK }}

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 a release is released, 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, but released 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 provided webhook-url, so I'm passing it a GitHub secret variable that's set to a Cloudflare Pages Deploy Hook URL.


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.