That feeling when you realize it’s been almost a year since your last post, and one of your new year’s goals was to write more.
So when I broke out the website repo to get back to writing, I found the workflows I use to deploy the site were broken.
The site’s repository is hosted on Github. I use (Firebase) for the actual serving. When the Github action attempted to push an update to Firebase, the action produced the following error:
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, peaceiris/actions-hugo@v2. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
I guess it had been a while since my last update.
Once I upgraded my actions to use those versions, the errors weren’t over:
⚠ Authenticating with `FIREBASE_TOKEN` is deprecated and will be removed in a future major version of `firebase-tools`. Instead, use a service account key with `GOOGLE_APPLICATION_CREDENTIALS`: https://cloud.google.com/docs/authentication/getting-started
=== Deploying to '$(FIREBASE_PROJECT)'...
i deploying hosting
Error: HTTP Error: 401, Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
So I started reading documentation: https://github.com/w9jds/firebase-action, which led me to https://firebase.google.com/docs/hosting/github-integration. The way authentication is performed has changed, and I needed to adapt to the new way of life.
Given that I’ve done this before, I had a bit of prior art, but it needed a bit of massaging:
I use a Docker container to generate the credentials for the authentication. It’s something I don’t do that often, but when I do, I want a repeatable set of steps.
docker run -it --rm \
-v /home/jforman/repos/write.jeffreyforman.net:/tmp/blog \
--net=host node:lts-alpine /bin/ash
The volume mount into the Git repo is needed since the Firebase CLI commands will use your pre-existing configuration to do some auto-filling and adding of configuration for you.
The --net=host is needed because the following Firebase command doesn’t respect the --no-localhost flag, so you need to access a port on the container. Not wanting to mess around with ports on both the host and the container, I just attached the container’s network stack to the host. After the login command, the following command adds the necessary Github actions to deploy to Firebase:
firebase init hosting:github
In the process of following the output of the command, the URL required to authenticate the OAUTH connection redirects to a url http://localhost:9005.
Using vscode, I configured a port forward from port 9005 to the Docker container on the remote host running the Firebase CLI. There must be some magic going on, since I never had to configure a desination port on the port-forward. I assume it was also 9005, though I never looked in the middle of running these actions.
Once I did this, the new Actions were auto-configured for me.
Make sure to answer No to the following question:
Set up the workflow to run a build script before every deploy? No
I never could figure out what this would have done, but I had to manually remove it since it was broken from the start.
The actions still didn’t work though, because the public directory was missing.
I needed to re-add the following steps into the build_and_deploy yaml:
steps:
- name: Set up Hugo
uses: peaceiris/actions-hugo@v3
with:
hugo-version: 'latest'
extended: true
- name: Build
run: hugo --minify
Now things are back to normal, and I can get back to writing more….Right?
I loaded up the site and was receiving 404’s. No index.html was found. And with the help of a handly npx Gist, I was able to uncover that only XML files were being generated.
After lots of staring at YAML files, I realized that after blindly-copying over the generated Github action from the firebase command, the checkout step wasn’t checking out submodules.
Updating the actions/checkout snippet to look like the following fixed things up:
- uses: actions/checkout@v4
with:
submodules: true
fetch-depth: 0
I guess Hugo’s behavior is that when there arent any submodules (like themes) present, it only generates XML files.
Once I committed that snippet and re-ran the workflows, everything worked again.
Resources: