SpaceX rocket launching from the Kennedy Space Center in Florida

Ignition sequence start

A GitHub Action to deploy a Hugo site to Firebase Hosting

published:  September 27, 2020
last modified:  October 26, 2020

Image: SpaceX; Unsplash

Note: Unlike the last two posts, this one very definitely is for only my fellow web geeks—and, anyway, they’re the only folks likely to be using Firebase Hosting, I would think.

I mentioned in a footnote to my previous post that my “lurch” among hosts now has this site on Firebase. If you’ve read both the original “Goodbye and hello” and its semi-retconned second part, you may remember my describing why I chose not to use Firebase. If so, you then may also wonder what changed my mind.

Actually, there were multiple reasons:

  • Last month, Firebase belatedly adopted Brotli compression, its previous lack of which had been a deal-breaker for me.
  • I had already been an admirer of the performance of the Fastly content delivery network (CDN) that Firebase uses, and found it was consistently better than the CDN setups provided with the free tiers for the other three hosts I’d been using and testing (Netlify, Render, and Vercel).
  • In the last few days, I tinkered around and was able to come up with a GitHub Action that made it possible to deploy (in Firebase terminology) to Firebase Hosting every time I pushed a change to the site repo’s default branch—i.e., making it as easy as when using the repo with those other three hosts. Yes, you can just do a local site build and then invoke firebase deploy, but that’s an extra step; I’ve kinda gotten accustomed to the ease of the push-to-repo method and didn’t want to give it up.

Sharing that GitHub Action with you is the purpose of this post, in case it might be of use to those who use both Firebase Hosting and the Hugo static site generator.

(Whoa, Hugo and not Eleventy any more? Yes. See the epilogue for more on that.)

This GitHub Action purposely does not use the widely used and excellent GitHub Actions for Hugo by Shohei Ueda (peaceiris) to install Hugo during the build process, because—as was the case with Andrew Connell, whose example I followed and to whom I am grateful for the information he imparted in “Automated Hugo Releases With GitHub Actions”—I preferred having more control over that exact part.

Enough talk; on with the GitHub Action. Of course, it’s based on two assumptions: (a.) you’ve initialized your repo for Firebase, thus creating the .firebaserc and firebase.json files mentioned at the end; and (b.) you’ve stored your Firebase token—called below by ${{ secrets.FIREBASE_TOKEN }}—in your repo’s Secrets. If you don’t have a Firebase token, you get that with firebase login:ci from the CLI, as explained in the documentation. You’ll note that I have npm run build in the Build site with Hugo step; but that’s peculiar to my formerly-using-NodeJS repo (a long story) and, in fact, only does rm -rf public && hugo --gc --minify—so you may want to use a variation of that, instead, if you’ve kept your Hugo repo Node-free. The Hugo version shown is the latest as of this post’s original publication; set it as you wish.1 I’m using the extended version because, sometimes, I support SCSS through Hugo Pipes; I switch the themes back and forth among SCSS, PostCSS without Tailwind, and PostCSS with Tailwind as situations warrant.2

name: CI-Hugo-site-to-Firebase

      - main

  HUGO_VERSION: 0.75.1 # steps below will pick extended version

    runs-on: ubuntu-latest

      - name: Checkout default branch
        uses: actions/checkout@v2
      - name: Download Hugo v${{ env.HUGO_VERSION }} Linux x64
        run: "wget${{ env.HUGO_VERSION }}/hugo_extended_${{ env.HUGO_VERSION }}_Linux-64bit.deb -O hugo_extended_${{ env.HUGO_VERSION }}_Linux-64bit.deb"
      - name: Install Hugo
        run: sudo dpkg -i hugo*.deb
      - name: Build site with Hugo
        run: npm run build
      - name: Install Firebase Tools
        run: npm install firebase-tools
      - name: Deploy to Firebase
        run: npx firebase deploy
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
          # Other args should come from .firebaserc and firebase.json


So, what up, homie? At least, some of you may be thinking that, in so many words.

Yes, it’s true: I’m back with the Hugo SSG after nearly ten months of peace from my infamous “dance” among multiple SSGs. As for why, it’s actually a mercifully short story. I can assure you it has absolutely nothing to do with a change of opinion about Eleventy—as I hope my laudatory words about it in “A normal person’s guide to static websites” made clear. I still tremendously admire Eleventy and its great community, and think it’s an excellent choice for anyone wanting to build one’s website, and even more so if one is interested in a JavaScript-based SSG. On that score, one can’t possibly do better than Eleventy.

The TL;DR version for the change: after much thought, I felt an overwhelming desire to return to the simplicity I had in the early days of building and running this site. That led me back to the single-binary, all-in-one Hugo (with its built-in support for SCSS).3

Yes, some not-so-simple things—most definitely including Firebase Hosting—may be nerdy fun, but I decided I wanted much less complexity on the other parts of the site. So I hit the Rewind button, and that’s where we are.

It is, if you’ll pardon the unintentional wordplay, as simple as that.

Note: Decided to leave Firebase Hosting a few days later, since it appeared I might occasionally have a chance of exceeding the free tier’s 10 GB monthly traffic limit, which is the skimpiest such allowance of all the hosts I’ve considered during the aforementioned “lurch.” (To be fair, Firebase doesn’t really push itself as a solution for this kind of free-tier use.) I knew of this limit ahead of time, of course, but didn’t know whether it would truly be a factor; figured the only way I’d find out would be to give it a try and see what kinds of numbers I got. Once I knew and did the math—well, that was all she wrote.

  1. Just be sure the version conforms to how it shows up in the Hugo release filename, since this reference helps build that name for the download process in the GitHub Action; always check the Hugo releases page to be sure about the accurate filename. ↩︎

  2. I now have this site’s repo set up so that there are three themes for Hugo’s use—one with purely SCSS, one with CSS-on-PostCSS (but still no Tailwind), and one with Tailwind. So, now, depending on which I want to use, I can simply switch themes in the site’s config.yaml file. ↩︎

  3. By the same token, I also decided to give up webmentions and all the ongoing technical debt they required—even though I obviously knew how to get them working in Hugo, too—in favor of more easily added and maintained commenting. ↩︎

Other posts

Next: Forward PaaS

Previous: A normal person’s guide to static website hosting