2023-08-22 08:55:00 +0700 by Mark Smith
I ran out of build minutes, so that's the end of new content on the website until next month. It's the same thing that happened last month. Last month I ended up going on a bit of a coding frenzy. Of course I couldn't test any of the code so I ended up with around 25 feature branches that I then had to merge in once the new billing cycle started and I had a fresh set of build minutes. That merge extravaganza was in a way what led to me running out of build minutes this month.
The silver lining in all this is that I have the new notes feature, which I'm finding really useful. It's also raising lots of questions in my head about frictionless publishing workflows. This month I'm going to try not to write any code while build minuteless. That's harder than you might imagine. The impulse to code is quite strong.
I'm going to keep publishing links, notes and blog posts though. They will be quite easy to merge back in because you don't tend to get bugs or merge conflicts with prose. There will probably be an increase in spelling mistakes though, as I won't have the opportunity to read back what I've written after publishing.
These two incidents have highlighted a downside to the current website architecture. Namely that if the build system is blocked for whatever reason, then that not only affects coding new features, but it directly affects adding new content. I spent a while thinking of ways to mitigate that but I haven't managed to come up with a full solution.
The limited build minutes was the reason why I batch all content updates to once per day. That way the number of build minutes needed is predictable. I'm also looking to optimize the deploy workflow. The npm cache I added hasn't worked for some reason, but I'm confident I'll find a way to speed things up.
Having said that, the build system could go down for other reasons too. Ideally there would still be a way to publish even if the build system was down, even if it was a slower method. I'm not sure how I could achieve that short of rendering the markdown on the client, and I'd rather not do that. Something to think about I suppose.