In this post I explained how I deployed my website using a simple deploy script.
There is another method to do this same thing but with continuous delivery. It uses GitHub’s new feature called GitHub Actions. It is obviously not necessary for my personal website. However I think it’s pretty cool to have a personal website with continuous delivery!
Enter GitHub Actions
As I was scouring the internet to figure out how to host my Gatsby site on GitHub Pages I came across GitHub Actions as a CI/CD server. I thought figuring out how CI/CD works and what GitHub Actions is by setting it up for my website would be pretty cool.
From all the reading I’ve done, if I had to describe what GitHub Actions does in one word I’d say automation.
Put simply, a GitHub Action defines a workflow to perform some task. This workflow will be automatically triggered each time a specified event occurs.
The docs define the following components that make up a GitHub Action,
- Actions: are the smallest building block of a workflow, an action is any standalone command.
- Steps: performs a single task, a step is made up of a single action.
- Jobs: are made up of one or more steps that execute on the same runner.
- Runner: is a server that listens for jobs, runs one job at a time, reports progress, logs results back to GitHub.
- Workflow: is made up of one or more jobs. A workflow with multiple jobs will run those jobs in parallel (default) or sequentially.
- Event: a specific activity (for example a new pull request) which triggers a workflow.
Before I explain the workflow I require, let me give you some context. I’m developing locally on the dev branch and the remote gh-pages branch is the publishing source for my GitHub Pages website.
So the workflow I need for my website would look like this,
Whenever I push to the dev branch, the “build” job will be executed. This job has two steps.
- First step will checkout the repository to a runner (i.e. a linux virtual machine server) on which the code can be executed.
- Second step will create the build and push it to the
gh-pagesbranch.
For the second step, this community action on GitHub Marketplace does exactly what I need. Think of GitHub Marketplace as a open source library for GitHub Actions- this means a kind person wrote and open-sourced step two for me.
I modified the community action to work with my website. In particular I configured the access token and the source branch. The workflow is defined inside the ./github/workflows/main.yml file. This is my workflow definition,
| # The name of the workflow as it will appear in the Actions tab of the GitHub repository. | |
| name: "Publish my Gatsby site to GitHub Pages." | |
| # Specifies the "event" that automatically triggers the workflow file. | |
| # Here, a push to the dev branch will trigger the jobs below to run. | |
| on: | |
| push: | |
| branches: | |
| - dev | |
| # This workflow is made up of one job. | |
| jobs: | |
| # The job is called "build" | |
| build: | |
| # Configures the runner. This job will run on an Ubuntu Linux virtual machine. | |
| runs-on: ubuntu-latest | |
| # Define the steps to perform the "build" job | |
| # 1. Check out this repository to the runner, now it is possible to run actions against the code | |
| # 2. Build and deploy the website using the community action | |
| # Configure the access token to allow pushing the build to the repository | |
| # Configure the branch that GitHub accepts as source of the static files. | |
| steps: | |
| - uses: actions/checkout@v1 | |
| - uses: enriikke/gatsby-gh-pages-action@v2 | |
| with: | |
| access-token: ${{ secrets.WEBSITE }} | |
| deploy-branch: gh-pages |
And we’re done! Now each time I run the git push command the workflow will be triggered and a new version of my website will be deployed automatically!