Turn everything into a leaf

content/posts/names.txt

@@ -0,0 +1,28 @@
+./automating-caddy-on-my-droplet.md
+./making-noise.md
+./first-post.md
+./integrating-cobra-and-lipgloss.md
+./notes-as-tools.md
+./mapping-aardwolf-with-graphviz.md
+./golang-quantize.md
+./prom-primer.md
+./beautiful-builds-with-bazel.md
+./filtering-hugo-pages-by-type.md
+./non-mechanical-ttrpg-fundamentals.md
+./one-dimensional-automata-and-you.md
+./path-of-market.md
+./standing-up-gogs.md
+./series-and-navigation.md
+./gitea-lfs-and-syncing-obsidian-vaults.md
+./genesis-flags.md
+./the-joy-of-versioning.md
+./validating-yaml-frontmatter-with-jsonschema.md
+./genesis-roadmap.md
+./bf-in-go.md
+./first-aardwolf-remort.md
+./pagerduty-synthetic-retrigger-loop.md
+./stamping-builds-with-bazel.md
+./drone-and-hugo.md
+./data-interfaces.md
+./selinux-and-nginx.md
+./pragmatic-projections-primer.md

content/posts/the-joy-of-versioning/index.md

@@ -19,10 +19,10 @@ tags:
 
 ## What am I Doing?
 Too many times this year I've found myself struggling to improve my [blog pipeline](https://blog.ndumas.com/series/blogging-with-quartz/) because I couldn't keep track of when code stopped and started doing what it was supposed to do. This was entirely my own fault, I was not observing best-practices:
-- I wasn't using semantic versioning 
+- I wasn't using semantic versioning
-- I wasn't tagging 
+- I wasn't tagging
-- all development happened on main 
+- all development happened on main
-- etc etc 
+- etc etc
 
 All of this worked well enough for private use monoliths, one-offs and skunkworks projects but these Drone pipelines presented a new challenge.
 
@@ -37,7 +37,7 @@ All of this added up to things breaking for far longer than they needed to, more
 
 After some digging I found resources that helped me build a Makefile to take care of things. That first Makefile added a **lot** but I'm only going to cover the tooling for semantic versioning and git tagging; the rest of that Makefile was go cross-compilation and docker image stuff that I'm replacing with bazel.
 
-To handle automatically incrementing semver values, I landed on  `bump`. Because it's written in Go, I was able to fork it and patch a few minor issues and make sure that it keeps working for the foreseeable future. 
+To handle automatically incrementing semver values, I landed on  `bump`. Because it's written in Go, I was able to fork it and patch a few minor issues and make sure that it keeps working for the foreseeable future.
 
 ## Why does it work?
 My current solution relies on a few pieces: `bump` and my Makefile invoking some git commands.
@@ -58,9 +58,9 @@ bump-patch: setup-bump
   bump patch
 ```
 
-[bump](https://github.com/guilhem/bump) is a golang utility that'll read a git repository's tags and apply a [semantic versioning](https://semver.org/) compliant version increment. `bump patch` bumps `v0.0.1` to `v0.0.2`. `bump major` goes from `v2.24.5` to `v3.0.0`. You get the idea. 
+[bump](https://github.com/guilhem/bump) is a golang utility that'll read a git repository's tags and apply a [semantic versioning](https://semver.org/) compliant version increment. `bump patch` bumps `v0.0.1` to `v0.0.2`. `bump major` goes from `v2.24.5` to `v3.0.0`. You get the idea.
 
 All together, this suite works perfectly for handling tagging. I don't have a super rigorous policy on what constitutes a major, minor, or patch version but being able to `make bump-patch` to tag a specific known-good commit made a world of difference. My drone pipelines became drastically more reliable thanks to version pinning.
 
-# But what about Bazel? 
+# But what about Bazel?
-Bazel isn't directly involved in manipulating tags yet. To do that, I'll need to add bazel build files to the `bump` repo. I'll cover that in the next post, where I cover how to use bazel's stamping funtionality.
+Bazel isn't directly involved in manipulating tags yet. To do that, I'll need to add bazel build files to the `bump` repo. I'll cover that in the next post, where I cover how to use bazel's stamping funtionality.