— Gatsby, Github Pages, Github Workflows — 2 min read
Now that I've got things rolling with my Gatsby conversion and everything seems good working with Github Pages, it was time to automate the build/release process. What a great chance to start playing with a little Github Actions (Yup, I know this stuff is old - but it's still new to me!). Right off the bat, my two priorties are to:
gatsby branchWith these two things, I have the ability to make modifications on the fly directly from Github as well as start following a few best practices for new content. Enter:
Github Workflows provide the ability to configure any number of jobs, performed as reactions to common Gitub and API actions.
While Googling around I found this little gem of a project, Gatsby Publish action that did exactly what I was looking for; with regards to publishing the gatsby branch to master on push. With a couple changes it's possible to perform only a build, by skip-publishing the job.
The first step to setting up workflows is to create a configuration file, from your project page:
ActionsNew Workflow.1# Publish Gatsby2name: publish-gatsby3
4# Controls when the action will run. Triggers the workflow on push or pull request5# events but only for the master branch6on:7  push:8    branches:9      - gatsby10
11# A workflow run is made up of one or more jobs that can run sequentially or in parallel12jobs:13  # This workflow contains a single job called "build"14  build:15    # The type of runner on which this job will run16    runs-on: ubuntu-latest17
18    # Steps represent a sequence of tasks that will be executed as part of the job19    # - Checkout gatsby branch20    # - Update authentication for Github Package Registry @kenjdavidson/base16-scss21    # - Build gh-pages using action22    steps:23      - uses: actions/checkout@v124      - name: Authenticate with GitHub package registry25        run: echo "//npm.pkg.github.com/:_authToken=${{ secrets.ACCESS_TOKEN }}" > ~/.npmrc26      - uses: enriikke/gatsby-gh-pages-action@v227        with:28          access-token: ${{ secrets.ACCESS_TOKEN }}At a high level this file is:
gatsby branch, which is configured as my main branchThe highlighted lines are used to import the
@kenjdavidson/base16-scsspackage which I have posted to Github Package Registry, if you don't have any package registry requirements, these lines can be removed from your configuration file.
1# Validates that the pull request branch will build2name: validate-pull-request3
4# Fires on pull-request to gatsby branc5on:6  pull_request:7    branches:8      - gatsby9
10# A workflow run is made up of one or more jobs that can run sequentially or in parallel11jobs:12  # This workflow contains a single job called "build"13  build:14    # The type of runner on which this job will run15    runs-on: ubuntu-latest16
17    # Steps represent a sequence of tasks that will be executed as part of the job18    # - Checkout gatsby branch19    # - Update authentication for Github Package Registry @kenjdavidson/base16-scss20    # - Build gh-pages using action21    steps:22      - uses: actions/checkout@v123      - name: Authenticate with GitHub package registry24        run: echo "//npm.pkg.github.com/:_authToken=${{ secrets.ACCESS_TOKEN }}" > ~/.npmrc25      - uses: kenjdavidson/gatsby-gh-pages-action@feature/build-only-config26        with:27          access-token: ${{ secrets.ACCESS_TOKEN }}28          skip-publish: trueconfigured with the same items as the original, except for the added skip-publish: true in order stop after a successful build. Ensures that pull requests will at least compile properly when merging the pull request from Github.
This workflow requires access to the Github Package Registry and Push to the repository, this is where the secrets.ACCESS_TOKEN comes in. First you'll need to create a Github personal access token, I won't get into those steps here, they are pretty straight forward.
Note - once you create your access token you can't ever get it back. So you'll either need to store it somewhere safe, regenterate it (which would require you updating all other places its required), or have one per action/feature so that resetting doesn't affect anything else. I'm unsure of Github best practices?
In order to configure your secrets, from you project page:
SettingsSecretsAdd New SecretYou'll be asked to enter the name ACCESS_TOKEN (required by the action) and the content.
As the actions are defined, you'll kick off one of the two actions by either:
Each push will now fire a build and publish - great for editing/correcting those pesky issues directly on Github.
Note - originally I had the publish workflow configured for pull-reqeust as well. This caused the build to actually publish the feature/branch to production, instead of just ensuring the build.
      
   
    
I've submitted a pull request for this specific draft, which kicked off the validate-pull-request action:
      
   
    
Once I get up and running with some actual React/Gatsby testing, I'll be able to take more advantage of these workflows.