• Home
  • Blog
    • Programming
    • Art
    • Recipes
    • Home Automation
    • Life
    • Friday Faves
    • Books
    • Writing
    • Games
    • Web Accessibility
    • Advent of Code
  • Projects
  • GLSL Shader Art
  • Glitch Art

  • Github
  • Bluesky
  • Mastodon
  • Duolingo
  • LinkedIn
  • RSS
  • Bridgy Fed

mary.codes

Web development, art, and tinkering with fun projects. JavaScript, Python, WebGL, GLSL, Rust, Lua, and whatever else I find interesting at the moment.

Updating blog deployments with Github Actions

Mary KnizeBlog iconNov 19th, 2023
3 min read

Programming

Moving from Gatsby Cloud back to GitHub pages, with automatic deployments.

Remember when I was all excited to migrate from Netlify to Gatsby Cloud because they had the latest and greatest way to automate deployments? It was supposed to take seconds to deploy?

Well, that never really happened for me. Maybe it's because I have a lot of posts and pictures to generate, but it always took a few minutes for my site to generate, even with caching.

And as of a few months ago, Gatsby Cloud has been retired.

Before I ever migrated to Netlify, I was hosting this site on GitHub pages, and you know what? GitHub pages has always been a solid option for hosting static sites. So I'm going back to hosting this site on GitHub pages, and it turns out there is a way to automatically build and deploy my site just by updating the main branch.

What I used to do

Back when I first started hosting this site on GitHub pages, I had my source repository privated. I'm not sure why I had it privated, other than I didn't want to publish the really ugly state of my site at the time. Now I figure, yeah, there's a lot of ugly unfinished stuff in the source here, but nobody's going to read the source code for my site, and if they do, maybe they'll find something useful (either genuinely good code or a cautionary tale).

What I would do was run gatsby build in my source repo and copy the contents of the /public folder into a second repository, which would hold all of the static files to be served on GitHub pages.

Obviously, this is a bad idea. Yes, it's simple, but it was also slow, complicated, and inefficient. Unfortunately, the Gatsby Cloud deprecation ran up against a planned vacation, and by the time I got around to fixing my site, I just had time to band-aid it with this old, inefficient workflow.

Setting up for GitHub actions

The first thing I had to do was to make the source repository public. It's easily done from the settings tab on the repository page.

Next, I had to delete the old static page repository. First, I went into the settings and removed the custom domain from the GitHub pages settings, freeing my domain up to be used on the other repo. At that point, my website was no longer available at mary.codes. Then, I deleted the repository in the settings.

On the source repository, I went back into the settings. On the pages tab, I saw under "Build and Deployment" that "Deploy from a branch" was selected by default. After selecting "GitHub actions", a suggested starter action for deploying Gatsby sites appeared, and I clicked the button to configure the action.

GitHub automatically opened a new pull request at that point, and created a new file, .github/workflows/gatsby.yml. At that point, I didn't change anything, but after my first deployment I did find that there was one change that needed to be made.

      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v3
#        with:
          # Automatically inject pathPrefix in your Gatsby configuration file.
          #
          # You may remove this line if you want to manage the configuration yourself.
#          static_site_generator: gatsby

The static_site_generator: gatsby line tries to helpfully prefix routes with the name of the repository, however, since I'm serving my blog from a custom domain, it only served to break all of my routes. Commenting out those two lines removes the prefixing. I also changed the line node-version: 18 to node-version: 20, since I'm using 20 locally. More information about the build script can be found at the gatsby-gh-pages-action repo.

Once those changes were made, all I had to do was save and merge the pull request into the main branch. This immediately kicked off the action to deploy my site. Since I already had my domain's DNS servers pointed to GitHub, all I had to do was add my domain name to this repo, and my site was live!

Maybe one of the best perks to this deployment strategy? I can basically use GitHub as a CMS. Before, I would have to use the command line, clone the entire repo, make a change, commit, merge the pr to master... it was a lot. Now, I'm typing right in a new branch in the text editor on GitHub. I can do almost everything from GitHub's web interface.

Editing on GitHub

I can even take a screenshot and upload the image straight from the web! Sure, every file addition and change is another commit, which will cause a lot of churn in my branches, but I'm enjoying the convenience of being untethered from the command line and Termux. Sure, I could've done this earlier, but, well, I'm just now realizing that it's an option!


Other Programming posts

How I'm organizing my work in 2024

Finding the Design Engineer within the Full-Stack Developer

Displaying the current Git branch in my Linux terminal prompt

Generating a 3D map with OpenStreetMap and A-Frame

Translating OpenStreetMap data to HTML5 Canvas with Rust and WebAssembly

Latest posts

I started painting again

100 days of Japanese on Duolingo

How I'm organizing my work in 2024

Watch the documentary 'Good Night Oppy' if you're feeling science-y

Sculpted robo-goldfish, a rainbow office building, and a look inside click farms