Cutting The Monster Into Pieces

2025-04-13  |   4 minutes

Now that I’ve identified a useable hosting candidate, my final test of their service will be to roll out a full implementation of the websmith deployment scheme. But in contemplating how I’m going to do that, I’ve realized that I may not have broken the project into distinct repos properly. So I’m going to figure it out by explaining it to the rubber duck. (Meaning you. :-)

My original decision, back when I started this project, was that there would be one repo called websmith, for the engine that produces the site HTML, and one repo called creativityhacker, for the generated files. But as I contemplate rolling this out into a production system, I realize that I may not have thought that decision through sufficiently. I now see several more distinct components in this system:

1. The Obsidian vault, a subset of which are the source files being sent to the site.
2. The shadowmaker script that converts the Obsidian vault into a hugo-friendly folder of markdown files, media files, and downloadables
3. The hugo templates and config files that describe the layout and behavior of the site
4. The scripts that monitor the site content files, trigger rebuilds when something changes, and deploys the changes to the production server
5. The rendered HTML and media files that make up the static website

In my current repo scheme, #2 and #3 are merged together into the websmith repo, #4 is the creativityhacker repo, and #1 and #5 don’t have a repo at all.

There are many ways these could be grouped into logical components, or even broken down further, but rather than dance around all the possible theoretical arrangements, I’m really just trying to decide the minimal set that suits my needs.

First and foremost, I need repo #5 to encapsulate the entire production site hierarchy. In addition to providing a safe backup and recovery system, this will also be my deployment vehicle.

Secondly, I need to capture all the scripts, templates, configs and CSS files that generate the HTML, because I’ll be using them on both my dev machine, when I need to modify the site design, and on my deployment server, which will use the latest stable scripts for deploying the site when new content gets added.

The less certain parts are whether the shadowmaker should be in its own repo, and whether the Obsidian vault needs a repo as well.

Solo Shadowmaker

My thinking here is that using Obsidian is the weird bit of my process - one that I could imagine eventually changing. In theory, I might decide to start writing my content directly in Hugo’s file system and eliminate the whole Obsidian front end. Or maybe other users might want to use my Hugo automation scheme but don’t want to use the Obsidian part.

But upon reflection, I think shadowmaker is just one of the scripts that implement my pipeline, and if somebody doesn’t want that part, they can simply not use it.

I can still think of other scenarios in which I might one day wish I had kept shadowmaker distinct, but I can always split it out then. For now, shadowmaker is staying as part of websmith.

Obsidian Git

It seems fairly obvious that if I want to protect my content, I should just bite the bullet and set up an Obsidian repo. I had worried that trying to capture every change would generate a storm of micro changes, since the files keep changing every time I pause while I’m writing a new post. But I can minimize that, and also keep the source repo matched to the HTML repo, by timing the two repos to update together, whenever the deployment server pushes a new update to the web.

Timestamps

The only thing left to decide is what to do with the timestamps database.

When Obsidian updates a file, the timestamp changes, so the only date attached to the file by the OS is always the most recent modification time. Then Hugo comes along and wants to knowthe creation date too, so the posts will sort properly. To handle this, websmith keeps a database of the very first time each file was encountered, and uses that to set the creation date metadata for the post.

So here’s the question: Does that metadata describe the source files, in which case it goes in creativityhacker-obsidian; or is it state data required by Hugo, in which case it goes in creativityhacker-hugo?

I could debate this nine different ways and come up with a different answer each time, so I’m not going to try to find the “ideal” answer. Instead I’m going to observe that if I include it in the hugo repo, I would not be able to test the system on fake data, or on historical data, because doing so would pollute the timestamps. So for that reason, I’m going to treat it as Obsidian metadata. (Whew! You wouldn’t believe how much time I’ve wasted overthinking this.)

So to recap, I’ll have 3 repos:

1. creativityhacker-obsidian (including timestamps)
2. creativityhacker-hugo (including shadowmaker)
3. creativityhacker-html

That looks like a workable plan.