And we’re live baby! (after a bit of DNS set-up head scratching…) Not to brag too much, but I’ve basically perfected the optimization and publishing pipeline for this blog now. I was sweating the fact that Firebase CLI only lets me sign into one account at a time; since I need Firebase for my work projects (with my work account), I’d basically need to log off / log in every time I wanted to deploy and update to my blog here.
Well, it turns out that Firebase easily integrates with GitHub actions and lets me redeploy on push! So, no need to deploy manually from my device. Now, my pipeline works like this:
- Create new blog entry + add media to it
- Create new commit
- Auto run pre-commit hook:
- Move all media to the correct directory, optimize for web (resize + conversion to
.webp/.webmformat), and rename all media files to a consistent format. - Sync all media to my Google Drive
- Add tags to posts using Gemini or Claude
- Move all media to the correct directory, optimize for web (resize + conversion to
- Push to GitHub
- Run GitHub Action to build and deploy static site to Firebase
Pretty nifty!
Just noticed that all my non-homepage pages on my live site returned a 404 error. According to Claude, my firebase.json was missing rules that explain how it should handle clean URLs that don’t have .html in them. It was a one prompt fix.
I also noticed that my auto-tagging doesn’t quite work right with my pre-commit hook because the tags get added to entries that need them, but the commit pushes the old entries instead of the newly tagged ones. This should have been a one-prompt fix, but because I refused to open a new chat window, Claude kept focusing on updating my project’s README instead of actually solving the issue (I had previously asked it to update the README). After two failed attempts (and probably ~$0.05 worth of tokens), I opened a new chat and got it fixed with the same single prompt that had previously failed twice before. There’s a lesson in here: new problem –> new context window.
There’s a second lesson to be learned too. I declared the issue fixed when it really was not. Let’s try again.
After the third failure, I realized this must simply be a limitation of pre-commit hooks. One does not simply
stage–>commit–>run pre-commit hook–>cancel commit–>restage files–>commit.
LLMs have a tough time acknowledging when something is not feasible to implement (see 2025-07-13 ), probably because they’re so good at solving problems in creative ways. The better solution is for me do run a pre-stage hook rather than a pre-commit one. With this new system in place, let’s try again.
It worked! Running npm run commit "message" instead of git commit -m "message" isn’t bad at all, but it is worse than using the big blue VSCode “Commit” button, which is my preferred way. The other downside is that it forces me to stage all files rather than selected ones I’d like to update. I don’t anticipate that being much of an issue though, and if I ever need to select specific files for staging, I can still do that the old fashioned way or via the GUI.
As a secondary optimization, I made it so the pre-commit hook gets bypassed when committing via the npm command. No need to run the same optimizations twice.
Tags: devops firebase github ai prompting debugging workflow