{{ i18n "tag" }}: {{ .Title }}
+ {{ .Content }} + {{with .Params.summary}} +{{.}}
+ {{end}} + {{partial "page-list.html" .Paginator.Pages}} + {{ template "_internal/pagination.html" . }} +
+
+ {{partial "header.html" .}}
+
+
+ {{partial "contact.html" .}}
+
+
+
+```
+
+### Where does it come from?
+There was a really confusing issue I had with the title section of the term page. The title was appearing correctly, even pulling from the `_index.md`, but it was being prefixed with `Tag: `.
+
+It took me some digging to find the cause. I started with grepping for `Tag`, and found it in the `i18n/en.toml`. This told me that a template was calling `i18n`, and there we had it in `layouts/_default/term.html`
+```html
+{{ i18n "tag" }}: {{ .Title }}
+``` +In practice, I don't think + + +The final template looks like this. +```html + + +{{ partial "head.html" . }} + + +{{partial "search.html" .}} +
+
+ {{partial "header.html" .}}
+
+
+ {{partial "contact.html" .}}
+
+
+
+```
+
+## Now what?
+We've got a nice looking series page now:
+
+{{< figure
+ src="series-display-screenshot.png"
+ alt="Screenshot of a website with four links to blog posts connected as a series"
+ caption=""
+>}}
+
+The next steps are to start filling out my series pages and writing about my projects. This actually clears out the outstanding list of projects I had for the blog, so I don't have any big structural stuff to do.
\ No newline at end of file
diff --git a/content/posts/adding-content-to-taxonomy-terms/series-display-screenshot.png b/content/posts/adding-content-to-taxonomy-terms/series-display-screenshot.png
new file mode 100644
index 0000000..de1931e
--- /dev/null
+++ b/content/posts/adding-content-to-taxonomy-terms/series-display-screenshot.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:bfb309fed293348de4b3a3d44eb061d1e56cb12f53dff49b186a0335454ff368
+size 86850
diff --git a/content/posts/automating-caddy-on-my-droplet/index.md b/content/posts/automating-caddy-on-my-droplet/index.md
new file mode 100644
index 0000000..1a36802
--- /dev/null
+++ b/content/posts/automating-caddy-on-my-droplet/index.md
@@ -0,0 +1,130 @@
+---
+draft: false
+title: "Automating Caddy on my DigitalOcean Droplet"
+date: "2023-01-05"
+author: "Nick Dumas"
+authorTwitter: "" #do not include @
+cover: ""
+tags: ["webdev", "devops"]
+keywords: ["", ""]
+summary: "Automation ambitions fall flat"
+showFullContent: false
+---
+
+## Defining units of work
+I've got a few different websites that I want to run: this blog, my portfolio, and my about page which acts as a hub for my other sites, my Bandcamp, and whatever else I end up wanting to show off.
+
+To keep things maintainable and reproducible, I decided to stop attempting to create a monolithic all-in-one configuration file. This made it way harder to keep changes atomic; multiple iterations on my blog started impacting my prank websites, and it became harder and harder to return my sites to a working state.
+
+## Proof of concept
+
+The first test case was my blog because I knew the Hugo build was fine, I just needed to get Caddy serving again.
+
+A static site is pretty straightforward with Caddy:
+
+```
+blog.ndumas.com {
+ encode gzip
+ fileserver
+ root * /var/www/blog.ndumas.com
+}
+```
+
+And telling Caddy to load it:
+
+```bash
+curl "http://localhost:2019/load" \
+ -H "Content-Type: text/caddyfile" \
+ --data-binary @blog.ndumas.com.caddy
+```
+
+This all works perfectly, Caddy's more than happy to load this but it does warn that the file hasn't be formatted with `caddy fmt`:
+
+```
+[{"file":"Caddyfile","line":2,"message":"input is not formatted with 'caddy fmt'"}]
+```
+
+## The loop
+
+Here's where things went sideways. Now that I have two unit files, I'm ready to work on the tooling that will dynamically load my config. For now, I'm just chunking it all out in `bash`. I've got no particular fondness for `bash`, but it's always a bit of a matter of pride to see whether or not I *can*.
+
+```bash
+# load-caddyfile
+#! /bin/bash
+
+function loadConf() {
+ curl localhost:2019/load \
+ -X POST \
+ -H "Content-Type: text/caddyfile" \
+ --data-binary @"$1"
+}
+
+loadConf "$1"
+```
+
+```bash
+# load-caddyfiles
+#! /bin/bash
+
+source load-caddyfile
+
+# sudo caddy stop
+# sudo caddy start
+for f in "$1/*.caddy"; do
+ echo -e "Loading $(basename $f)"
+ loadConf "$f"
+ echo
+done
+```
+
+After implementing the loop my barelylegaltrout.biz site started throwing a 525 while blog.ndumas.com continued working perfectly. This was a real head scratcher, and I had to let the problem sit for a day before I came back to it.
+
+After some boring troubleshooting legwork, I realized I misunderstood how the `/load` endpoint works. This endpoint completely replaces the current config with the provided payload. In order to do partial updates, I'd need to use the `PATCH` calls, and look who's back?
+
+## can't escape JSON
+
+The `PATCH` API *does* let you do partial updates, but it requires your payloads be JSON which does make sense. Because my current set of requirements explicitly excludes any JSON ( for now ), I'm going to have to ditch my dreams of modular code.
+
+
+
+Not all my code has gone to waste, though. Now that I know `POST`ing to to `/load` overwrites the whole configuration, I don't need to worry about stopping/restarting the caddy process to get a clean slate. `load-caddyfile` will let me keep iterating as I make changes.
+
+## Proxies
+
+In addition to the static sites I'm running a few applications to make life a little easier. I'll showcase my Gitea/Gitlab and Asciinema configs. At the moment, my setup for these are really janky, I've got a `tmux` session on my droplet where I've manually invoked `docker-compse up`. I'll leave cleaning that up and making systemd units or something proper out of them for a future project.
+
+Reverse proxying with Caddy is blessedly simple:
+```
+cast.ndumas.com {
+ encode gzip
+ reverse_proxy localhost:10083
+}
+```
+
+```
+code.ndumas.com {
+ encode gzip
+ reverse_proxy localhost:3069
+}
+```
+
+With that, my gitea/gitlab is up and running along with my Asciinema instance is as well:
+
+[](https://cast.ndumas.com/a/28)
+
+## Back to Square One
+After finally making an honest attempt to learn how to work with Caddy 2 and its configurations and admin API, I want to take a swing at making a systemd unit file for Caddy to make this a proper setup.
+
+## Finally
+
+Here's what's currently up and running:
+- [My blog](blog.ndumas.com)
+- [Asciinema](blog.ndumas.com)
+- [Gitea](blog.ndumas.com)
+
+I've had loads of toy projects over the years ( stay tuned for butts.ndumas.com ) which may come back, but for now I'm hoping these are going to help me focus on creative, stimulating projects in the future.
+
+The punchline is that I still haven't really automated Caddy; good thing you can count on `tmux`
+[](https://cast.ndumas.com/a/aWYCFj69CjOg94kgjbGg4n2Uk)
+
+The final code can be found [here](https://code.ndumas.com/ndumas/caddyfile). Nothing fancy, but troublesome enough that it's worth remembering the problems I had.
diff --git a/content/posts/beautiful-builds-with-bazel/index.md b/content/posts/beautiful-builds-with-bazel/index.md
new file mode 100644
index 0000000..73629c3
--- /dev/null
+++ b/content/posts/beautiful-builds-with-bazel/index.md
@@ -0,0 +1,494 @@
+---
+draft: false
+title: "Beautiful Builds with Bazel"
+aliases: ["Beautiful Builds with Bazel"]
+series: ["building-with-bazel"]
+series_order: 1
+date: "2023-08-25"
+author: "Nick Dumas"
+cover: ""
+summary: "bzlmod makes bazel extremely appealing and isn't hard to grasp for anyone already familiar with go modules. My frustration with make for complex builds led me to bazel."
+showFullContent: false
+tags:
+ - bazel
+ - golang
+ - devops
+---
+
+## What am I Doing?
+I write programs to solve problems. Most of the time these are pretty personal and only get used once or twice, never see the light of day again, and that's fine.
+
+Lately, though, I've been working on tooling for my Obsidian notes and I want to make my tools as accessible as possible. This involves a couple steps that are particularly important, tedious, and error prone when done manually:
+- trying to cross compile my binaries for a relatively long list of cpu/arch combinations
+- build a docker image
+ - push that docker image to OCI image repositories
+- run tests
+- run benchmarks
+- cache builds effectively
+
+I've started with a Makefile I stole from some gist I didn't save a link to. This [makefile](https://code.ndumas.com/ndumas/wikilinks-parser/src/tag/v0.0.5/Makefile) is kinda hefty so I'm gonna focus on compiling go binaries and preparing OCI images that contain those binaries.
+
+This makefile's extremely opinionated, hyper-targeted at Go builds. It assumes that your binaries live in `cmd/binaryName/`.
+
+```Makefile
+# Parameters
+PKG = code.ndumas.com/ndumas/obsidian-markdown
+NAME = parse-wikilinks
+DOC = README.md LICENSE
+
+DISTDIR ?= $(WD)/dist
+CMDS := $(shell find "$(CMDDIR)/" -mindepth 1 -maxdepth 1 -type d | sed 's/ /\\ /g' | xargs -n1 basename)
+INSTALL_TARGETS := $(addprefix install-,$(CMDS))
+
+VERSION ?= $(shell git -C "$(MD)" describe --tags --dirty=-dev)
+COMMIT_ID := $(shell git -C "$(MD)" rev-parse HEAD | head -c8)
+LDFLAGS = -X $(PKG).Version=$(VERSION) -X $(PKG).Build=$(COMMIT_ID)
+
+GOCMD = go
+GOINSTALL = $(GOCMD) install -a -tags "$(BUILD_TAGS)" -ldflags "$(LDFLAGS)"
+GOBUILD = gox -osarch="!darwin/386" -rebuild -gocmd="$(GOCMD)" -arch="$(ARCHES)" -os="$(OSES)" -output="$(OUTTPL)" -tags "$(BUILD_TAGS)" -ldflags "$(LDFLAGS)"
+
+GZCMD = tar -czf
+SHACMD = sha256sum
+ZIPCMD = zip
+
+
+build: $(CMDS)
+$(CMDS): setup-dirs dep
+ $(GOBUILD) "$(CMDPKG)/$@" | tee "$(RPTDIR)/build-$@.out"
+install: $(INSTALL_TARGETS)
+$(INSTALL_TARGETS):
+ $(GOINSTALL) "$(CMDPKG)/$(subst install-,,$@)"
+
+dist: clean build
+ for docfile in $(DOC); do \
+ for dir in "$(DISTDIR)"/*; do \
+ cp "$(PKGDIR)/$$docfile" "$$dir/"; \
+ done; \
+ done
+ cd "$(DISTDIR)"; for dir in ./*linux*; do $(GZCMD) "$(basename "$$dir").tar.gz" "$$dir"; done
+ cd "$(DISTDIR)"; for dir in ./*windows*; do $(ZIPCMD) "$(basename "$$dir").zip" "$$dir"; done
+ cd "$(DISTDIR)"; for dir in ./*darwin*; do $(GZCMD) "$(basename "$$dir").tar.gz" "$$dir"; done
+ cd "$(DISTDIR)"; find . -maxdepth 1 -type f -printf "$(SHACMD) %P | tee \"./%P.sha\"\n" | sh
+ $(info "Built v$(VERSION), build $(COMMIT_ID)")
+```
+
+Because this isn't a makefile tutorial, I'm going to just hit the high notes and explain why this isn't working. Given the parameters at the top, it looks in `cmd/` for directories and passes them to `go build` with `-ldflags` thrown in.
+
+Here we have the machinery behind `make bump`, github link below. `bump` is a tool that'll automatically create semantic versioning tags in a git repo based on existing tags. You can `bump {patch,minor,major}` and it'll create the next tag in the versioning sequence for you.
+```Makefile
+setup-bump:
+ go install github.com/guilhem/bump@latest
+
+bump-major: setup-bump
+ bump major
+
+bump-minor: setup-bump
+ bump minor
+
+bump-patch: setup-bump
+ bump patch
+```
+
+## Why does it work?
+Automation is a great thing. This makefile inspired me to start actually using semantic versioning diligently. It didn't hurt that I was working on a lot Drone pipelines at the time and was starting to get incredibly frustrated debugging `:latest` images and never being certain what code was running.
+
+Working with bash is never...pleasant, but it definitely gets the job done. I'm no stranger to shell scripts and the minor modifications needed to get `bump` integrated and other miscellany I've legitimately fully forgotten by now ( document your code for your own sake ) posed no real burden.
+
+This makefile helped me rapidly iterate on code and release it in a way that was easily consumable, including docker images pushed to my self-hosted registry on Gitea. The pipeline that handles this blog post is using a docker image tagged by the makefile components described above, in fact.
+
+## Why doesn't it work?
+The real kink in the hose ended up being gox. Gox worked great until I tried to generate alpine builds. It was possible, but I'd have to start changing the makefile pretty significantly, write bash helper functions, and more. I decided that wasn't worth the maintenance overhead pretty quickly and started looking in
+
+it's not "smart". The solutions for cross-compilation ended up being clunky to compose with Docker builds
+## What are the options?
+The only real solution is a smarter build system. I had to choose between hand-rolling something with a bunch of switch statements in bash, or I could look into more modern toolkits. I looked into three:
+- meson
+- bazel
+- scons
+## The contenders
+Bazel looked like it had the most to offer:
+- hermetic builds
+- reproducible builds
+- aggressive, fine-grained caching
+- extensible
+
+All of these fit the bill for what I needed. In particular, it has pretty decent go support through [rules_go](https://github.com/bazelbuild/rules_go) and [gazelle](https://github.com/bazelbuild/bazel-gazelle), which we'll look at in more depth later.
+
+There's not a lot to say here, I knew nothing about any of the three candidates and when I started I wasn't certain I'd stick with bazel all the way. Sometimes you just have to try stuff and see how it feels.
+
+### Caution
+bazel seems to be going through an ecosystem shift from the WORKSPACE paradigm to bzlmod. Documentation does exist, but it might not be in the README yet. I've tested the code here and it works in this narrow case. Caveat emptor.
+
+## Getting Going with Gazelle
+With that, here is how a modern bzlmod enabled go repo is born.
+
+### Building Go code
+The first step is, in no particular order, init your git repository and init your go module. The former is helpful for keeping track of when you broke something and the latter is required for gazelle to do its job.
+- `go mod init`
+- `git init`
+
+Write your go code. The simplest hello world will work for demonstration purposes.
+
+Create your `MODULE.bazel` file.
+``` {title="MODULE.bazel"}
+module(
+ name = "obsidian-markdown", # set this manually
+ repo_name = "code.ndumas.com_ndumas_obsidian-markdown", # this is the name of your go module, with /'s replaces with _'s
+)
+
+bazel_dep(name = "gazelle", version = "0.32.0")
+bazel_dep(name = "rules_go", version = "0.41.0")
+
+go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
+go_deps.from_file(go_mod = "//:go.mod")
+
+```
+`module()` is how you declare a top-level bazel project. Everything is namedspaced under this module.
+
+`bazel_dep` tells bazel to retrieve modules from the [bazel registry](https://registry.bazel.build/).
+
+`use_extension` imports functions from bazel modules; here we're importing `go_deps` because it'll read out `go.mod` file and help bazel automatically calculate direct and transitive dependencies.
+
+
+and `BUILD.bazel`
+``` {title="BUILD.bazel"}
+load("@gazelle//:def.bzl", "gazelle")
+
+gazelle(name = "gazelle")
+
+gazelle(
+ name = "gazelle-update-repos",
+ args = [
+ "-from_file=go.mod",
+ "-to_macro=deps.bzl%go_dependencies",
+ "-prune",
+ ],
+ command = "update-repos",
+)
+```
+
+This is straight from the gazelle README. You `load()` the gazelle module and declare two build targets: `gazelle` and `gazelle-update-repos`. After the rest of the setup, these targets are what will do the work of actually generating build/test targets for all your code.
+
+Next, `.bazelrc`
+``` {title=".bazelrc"}
+common --experimental_enable_bzlmod
+
+# Disable lockfiles until it works properly.
+# https://github.com/bazelbuild/bazel/issues/19068
+common --lockfile_mode=off
+
+###############################
+# Directory structure #
+###############################
+
+# Artifacts are typically placed in a directory called "dist"
+# Be aware that this setup will still create a bazel-out symlink in
+# your project directory, which you must exclude from version control and your
+# editor's search path.
+build --symlink_prefix=dist/
+
+###############################
+# Output #
+###############################
+
+# A more useful default output mode for bazel query, which
+# prints "ng_module rule //foo:bar" instead of just "//foo:bar".
+query --output=label_kind
+
+# By default, failing tests don't print any output, it's logged to a
+# file instead.
+test --test_output=errors
+```
+
+Only the first line is required; the rest are just conveniences. I do **strongly** recommend the `query` setting though, extremely nice for debugging.
+
+Finally, a `.gitignore` to mask out generated artifacts.
+``` {title=".gitignore"}
+dist/*
+reports/*
+bazel-*
+*.bazel.lock
+```
+
+Run `bazel build //:gazelle`. This will auto-generate a lot of scaffolding, and probably emit a `buildozer` command that will modify something. This is the build system (specifically gazelle ) automatically detecting dependencies that are declared in `go.mod` but not in your bazel code.
+```bash
+$ bazel run //:gazelle
+WARNING: /home/ndumas/work/gomud/MODULE.bazel:8:24: The module extension go_deps defined in @gazelle//:extensions.bzl reported incorrect imports of repositorie
+s via use_repo():
+
+Not imported, but reported as direct dependencies by the extension (may cause the build to fail):
+ com_github_therealfakemoot_go_telnet
+
+ ** You can use the following buildozer command(s) to fix these issues:
+
+buildozer 'use_repo_add @gazelle//:extensions.bzl go_deps com_github_therealfakemoot_go_telnet' //MODULE.bazel:all
+INFO: Analyzed target //:gazelle (0 packages loaded, 0 targets configured).
+INFO: Found 1 target...
+Target //:gazelle up-to-date:
+ dist/bin/gazelle-runner.bash
+ dist/bin/gazelle
+INFO: Elapsed time: 0.473s, Critical Path: 0.01s
+INFO: 1 process: 1 internal.
+INFO: Build completed successfully, 1 total action
+INFO: Running command line: dist/bin/gazelle
+$ git st
+## dev
+?? .bazelrc
+?? .gitignore
+?? BUILD
+?? MODULE.bazel
+?? cmd/BUILD.bazel
+?? protocol/BUILD.bazel
+$
+```
+
+Running the `buildozer` command and then `git diff` shows its work:
+```bash
+$ buildozer 'use_repo_add @gazelle//:extensions.bzl go_deps com_github_therealfakemoot_go_telnet' //MODULE.bazel:all
+fixed /home/ndumas/work/gomud/MODULE.bazel
+$ git st
+## dev
+ M MODULE.bazel
+$ git diff
+diff --git a/MODULE.bazel b/MODULE.bazel
+index b482f31..8e82690 100644
+--- a/MODULE.bazel
++++ b/MODULE.bazel
+@@ -7,3 +7,4 @@ bazel_dep(name = "gazelle", version = "0.32.0")
+
+ go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
+ go_deps.from_file(go_mod = "//:go.mod")
++use_repo(go_deps, "com_github_therealfakemoot_go_telnet")
+$
+```
+This diff shows how bazel references external dependencies. gazelle's `go_deps` tool acts as a provider for these lookups and offers information bazel needs to verify its build graphs. Yours may look different depending on what you've imported, if anything.
+
+Examining the produced `BUILD.bazel` file should yield something like this for a `main` package.
+``` {title="cmd/echo/BUILD.bazel"}
+load("@rules_go//go:def.bzl", "go_binary", "go_library")
+
+go_library(
+ name = "echo_lib",
+ srcs = ["server.go"],
+ importpath = "code.ndumas.com/ndumas/gomud/cmd/echo",
+ visibility = ["//visibility:private"],
+)
+
+go_binary(
+ name = "echo",
+ embed = [":echo_lib"],
+ visibility = ["//visibility:public"],
+)
+```
+
+
+If the package is importable, you'll see something like this:
+``` {ttile="protocol/BUILD.bazel"}
+load("@rules_go//go:def.bzl", "go_library")
+
+go_library(
+ name = "protocol",
+ srcs = ["telnet.go"],
+ importpath = "code.ndumas.com/ndumas/gomud/protocol",
+ visibility = ["//visibility:public"],
+)
+```
+These are examples of `rules_go` build targets. These do a bunch of magic to invoke Go toolchains and in theory let bazel cache builds at a pretty granular level. I'm hoping this is true, I've got a few pipelines that are starting to run way longer than I like.
+
+### OCI Images
+For ease of use, I like to build docker images containing my packages. This is particularly important for Drone pipelines.
+
+We're gonna amend our `MODULE.bazel` to add some new tools.
+``` {title="MODULE.bazel"}
+bazel_dep(name = "rules_oci", version = "1.3.1") # gives us ways to interact with OCI images and repositories
+bazel_dep(name = "rules_pkg", version = "0.9.1") # exposes a way to tar our app, which is necessary for packing with rules_oci
+
+
+oci = use_extension("@rules_oci//oci:extensions.bzl", "oci")
+oci.pull(
+ name = "distroless_base",
+ image = "gcr.io/distroless/base",
+ tag = "latest", # This is temporary. For reproducible builds, you'll want to use digest hashes.
+)
+
+use_repo(oci, "distroless_base")
+```
+
+`pull()` does more or less what it says: it creates a target that represents an OCI image pulled from a registry, and another `use_repo()` call tells bazel that we're *using* our image.
+
+And add this to the `BUILD.bazel` file for the binary you want built into an OCI image
+``` {title="cmd/echo/BUILD.bazel"}
+load("@rules_pkg//:pkg.bzl", "pkg_tar")
+
+pkg_tar(
+ name = "tar",
+ srcs = [":echo"],
+)
+
+load("@rules_oci//oci:defs.bzl", "oci_image")
+
+oci_image(
+ name = "image",
+ base = "@distroless_base",
+ entrypoint = ["/echo"],
+ tars = [":tar"],
+)
+```
+
+`oci_image` requires that whatever you package into the image it creates be contained in a tar file, which seems pretty reasonable. `rules_pkg` handles that for us.
+
+Run `bazel build //cmd/echo:image` and you'll see another `buildozer` command and a lot of errors. This is to be expected, bazel wants builds to be reproducible and because we haven't specified a version or a hash it can't do that. It helpfully emits the `buildozer` command that'll set the proper digest hash and platforms bazel needs to resolve its builds.
+```
+bazel build //cmd/echo:image
+WARNING: fetching from https://gcr.io/v2/distroless/base/manifests/latest without an integrity hash. The result will not be cached.
+WARNING: for reproducible builds, a digest is recommended.
+Either set 'reproducible = False' to silence this warning,
+or run the following command to change oci.pull to use a digest:
+(make sure you use a recent buildozer release with MODULE.bazel support)
+
+buildozer 'set digest "sha256:73deaaf6a207c1a33850257ba74e0f196bc418636cada9943a03d7abea980d6d"' 'remove tag' 'remove platforms' 'add platforms "linux/amd64" "
+linux/arm64" "linux/arm" "linux/s390x" "linux/ppc64le"' MODULE.bazel:distroless_base
+
+WARNING: fetching from https://gcr.io/v2/distroless/base/manifests/latest without an integrity hash. The result will not be cached.
+INFO: Repository rules_oci~1.3.1~oci~distroless_base_single instantiated at:
+ callstack not available
+Repository rule oci_pull defined at:
+ /home/ndumas/.cache/bazel/_bazel_ndumas/482ba52ed14b5c036eb1d379e90911a8/external/rules_oci~1.3.1/oci/private/pull.bzl:437:27: in {{ i18n "interactive_graph" }}: {{ .Title }}
+ {{ .Content }} + {{with .Params.summary}} +{{.}}
+ {{end}} + {{partial "page-list.html" .Paginator.Pages}} + {{ template "_internal/pagination.html" . }} +
+
+
+{{- end -}}
+```
+
+`notice--info` just pulls a color from the base definitions. It ads a little visual pop.
+```css {title="asset/styles/custom.scss"}
+...
+.notice--info {
+ @include notice(var(--primary));
+}
+...
+```
+
+
+{{< figure src="series-insert-example.png" alt="Screenshot of text on a website describing an article and its membership in a series called 'blogging-with-qurtz' " caption="You can even click the name to take you to a list of the rest of the posts in the series">}}
+
+## Webdev is tedious
+I'd love to be able to test this locally. It only takes approximately thirty seconds from pushing a change to having a fresh build of the site, but that's still hella slow when you're trying to rapidly iterate on CSS and stuff.
+
+I'm really happy with how this looks, though, and I'm excited to keep tweaking things. I've got 30 tabs open with Hugo templates and toolkits that I'm gonna rifle through and try to find inspiration in.
\ No newline at end of file
diff --git a/content/posts/series-and-navigation/prev-next-links-example.png b/content/posts/series-and-navigation/prev-next-links-example.png
new file mode 100644
index 0000000..173c1ec
--- /dev/null
+++ b/content/posts/series-and-navigation/prev-next-links-example.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:0622ed56d2a4dc78452fe0a39eabcaff76950134757c311ae9fd6202e11fc8a9
+size 25519
diff --git a/content/posts/series-and-navigation/series-insert-example.png b/content/posts/series-and-navigation/series-insert-example.png
new file mode 100644
index 0000000..05c76f8
--- /dev/null
+++ b/content/posts/series-and-navigation/series-insert-example.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3728ae5890e41376a943d05a09bfeef2d6bcf3e968c02a792bb4d970144cf29c
+size 48573
diff --git a/content/posts/stamping-builds-with-bazel/index.md b/content/posts/stamping-builds-with-bazel/index.md
new file mode 100644
index 0000000..e52cd6a
--- /dev/null
+++ b/content/posts/stamping-builds-with-bazel/index.md
@@ -0,0 +1,105 @@
+---
+draft: false
+title: "Stamping Builds with Bazel"
+aliases: ["Stamping Builds with Bazel"]
+series: ["building-with-bazel"]
+series_order: 3
+date: "2024-05-15"
+author: "Nick Dumas"
+cover: ""
+keywords: ["", ""]
+summary: "Versioning is a critical part of delivering software to users. With bazel, you can derive per-build values and inject them anywhere in your build process."
+summary: "Versioning is a critical part of delivering software to users. With bazel, you can derive per-build values and inject them anywhere in your build process."
+showFullContent: false
+tags:
+- bazel
+- golang
+---
+
+## What am I Doing?
+In my [last post](/2024/09/the-joy-of-versioning/) I spent some time talking about how more rigorous versioning helped reduce wasted time debugging and upgrading code as it started getting broken into lots of little pieces.
+
+That post was pretty light on direct `bazel` usage but I promise, it'll pay off. Here, we're going to cover how to use these tags *in* your builds to tag docker images or inject build information into compiled binaries.
+
+I'm assuming that you've read the [first bazel post](/2023/08/beautiful-builds-with-bazel/) in this series, or that you've already got your bazel + bzlmod setup going.
+
+## Stamping and you
+Bazel includes functionality that it calls "stamping". Bazel has to separate this into its own conceptual space because one of the core design principles is build reproducibility: for bazel's caching to work, inputs have to be deterministic and ideally change infrequently between runs.
+
+Bazel's [documentation](https://bazel.build/docs/user-manual#workspace-status) covers the bare essentials, with a small caveat. Stamping requires a script , the "workplace status" script, that emits space-separated key-value pairs, e.g. `STABLE_KEY_NAME VALUE`. An example script is included below.
+
+```bash {title="tools/workspace_status.sh"}
+#! /usr/bin/env bash
+
+set -o errexit
+set -o nounset
+set -o pipefail
+
+echo "STABLE_STAMP_VERSION $(git describe --tags --dirty=-dev)"
+echo "STABLE_STAMP_COMMIT $(git rev-parse HEAD)"
+echo "STABLE_STAMP_BRANCH $(git rev-parse --abbrev-ref HEAD)"
+```
+
+One important detail that the documentation doesn't cover is that your workspace status script **cannot** live in the root of your bazel project. You have two options:
+- Place the status script somewhere in your `$PATH`
+- Place the status script in a subdirectory
+
+Still not sure why, but if you simply do `bazel --workplace_status_command=status.sh`, `bazel` will *only* look for it in your `$PATH`.
+
+## Build Injection
+Using the variables created by your workspace status script ends up being incredibly simple, if you're using `rules_go`. the `x_defs` parameter lets you override values at compile-time, exactly for cases like this.
+
+```
+x_defs = {
+ "Version": "{STABLE_STAMP_VERSION}",
+ "Build": "{STABLE_STAMP_COMMIT}",
+ },
+```
+
+This is equivalent to the Go build flag `-ldflags "-X PACKAGENAME.Version=whatever -X PACKAGENAME.BUILD=whatever"`. It's important to note that the raw Go flags require a fully qualified package name be specified. Bazel is smart enough to derive the necessary package name on its own, all you have to do is tell it which variable needs to be overriden with what value.
+
+## Putting it all together
+The final, full invocation for stamping your builds should look something like this.
+
+```
+wikilink-obsidian-resolver on main [⇡] via 🐹 v1.22.2
+❯ bazel run --stamp --workspace_status_command=tools/workspace_status.sh //cmd/version
+INFO: Analyzed target //cmd/version:version (0 packages loaded, 0 targets configured).
+INFO: Found 1 target...
+Target //cmd/version:version up-to-date:
+dist/bin/cmd/version/version_/version
+INFO: Elapsed time: 1.262s, Critical Path: 1.10s
+INFO: 2 processes: 1 internal, 1 darwin-sandbox.
+INFO: Build completed successfully, 2 total actions
+INFO: Running command line: dist/bin/cmd/version/version_/version
+Version: v0.1.4-1-g5792d62
+Build: 5792d623fc9fc1852aeb09dd008eabb640cb6711
+```
+Bazel runs your binary, injects variables generated by your workspace_status script, and it all finally comes together.
+
+The stamping also works for builds:
+```
+
+wikilink-obsidian-resolver on main [⇡] via 🐹 v1.22.2
+❯ bazel build --stamp --workspace_status_command=tools/workspace_status.sh //cmd/version
+INFO: Analyzed target //cmd/version:version (0 packages loaded, 0 targets configured).
+INFO: Found 1 target...
+Target //cmd/version:version up-to-date:
+dist/bin/cmd/version/version_/version
+INFO: Elapsed time: 0.246s, Critical Path: 0.06s
+INFO: 1 process: 1 internal.
+INFO: Build completed successfully, 1 total action
+
+wikilink-obsidian-resolver on main [⇡] via 🐹 v1.22.2
+❯ ./dist/bin/cmd/version/version_/version
+Version: v0.1.4-1-g5792d62
+Build: 5792d623fc9fc1852aeb09dd008eabb640cb6711
+```
+
+## What next?
+Stamping is not going to accomplish any of my goals on its own, but it was an important part of preparing my toolkit. If I'm going to release software for other people to consume, I need versioning. Injecting a git tag into a Go binary is a trivial proof of concept; I'll be using this to automatically tag and push OCI images and probably other stuff I haven't come up with yet.
+
+## Notes, Warnings, Caveats
+- Important: the `workspace-status-script` *cannot* live in the root of the bazel project. It has to be in a subdirectory for some reason.
+- If you're defining `x_defs` on a `rules_go` `go_library`, you cannot fully qualify the variable names.
+- To find where bazel places artifacts, use `bazel cquery --output=files`
diff --git a/content/posts/standing-up-gogs/index.md b/content/posts/standing-up-gogs/index.md
new file mode 100644
index 0000000..036ffc8
--- /dev/null
+++ b/content/posts/standing-up-gogs/index.md
@@ -0,0 +1,43 @@
+---
+draft: false
+title: "Standing up Gogs and fighting with SELinux"
+aliases: ["Standing up Gogs and fighting with SELinux"]
+author: "Nick Dumas"
+series: []
+cover: ""
+summary: "SELinux like all security tools end up getting in the way of users who know what they're doing."
+showFullContent: false
+date: "2018-02-20"
+tags:
+- nginx
+- gogs
+- selinux
+---
+
+# The Reveal
+
+It took me way longer than I'd like to admit but I finally discovered why I was not able to properly reverse proxy a subdomain ( [git.ndumas.com](http://git.ndumas.com) ). As it turns out, SELinux was the culprit. I wanted to write a short post about this partly to reinforce my own memory and maybe to make this sort of thing easier to find for others encountering 'mysterious' issues when operating on SELinux Fedora installations like Digital Ocean droplets.
+
+# Symptoms
+
+SELinux interference with nginx doing its business will generally manifest as a variation on "permission denied". Here's one such error message:
+
+```
+2018/02/20 23:32:51 [crit] 4679#0: *1 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: git.ndumas.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:3000/favicon.ico", host: "git.ndumas.com", referrer: "http://git.ndumas.com/"
+```
+
+# Solution
+
+Resolving this requires whitelisting whatever action/context SELinux is restricting. There's a useful tool, `audit2allow`, that will build a module for you automatically. You can invoke it like this:
+
+```
+sudo cat /var/log/audit.log|grep nginx|grep denied|audit2allow -M filename
+```
+
+Once you've done this, you'll have a file named `filename.pp`. All you have to do next is:
+
+```
+semodule -i filename.pp
+```
+
+SELinux will revise its policies and any restrictions nginx encountered will be whitelisted.
diff --git a/content/posts/the-joy-of-versioning/index.md b/content/posts/the-joy-of-versioning/index.md
new file mode 100644
index 0000000..1f800ec
--- /dev/null
+++ b/content/posts/the-joy-of-versioning/index.md
@@ -0,0 +1,66 @@
+---
+draft: false
+title: The Joy of Versioning
+aliases:
+ - The Joy of Versioning
+series:
+ - building-with-bazel
+series_order: 2
+date: "2023-09-02"
+author: Nick Dumas
+cover: ""
+keywords: []
+summary: "Investing in tooling makes adhering to good practices almost easy enough to be joyful."
+showFullContent: false
+tags:
+ - bazel
+ - golang
+---
+
+## 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 tagging
+- all development happened on main
+- 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.
+
+Drone pipelines tend to be structured as a series of docker images operating on a mount that gets injected into all of them so they can share their work. This is fine, docker images are an easy fire-and-forget solution for deploying tools.
+
+As things grew more complex, my sloppy coding practices put me in a lot of unnecessary tight spots.
+- Some parts of the pipeline were idempotent, others weren't.
+- Some parts of the pipeline were affected by each other's work. For example, one step scans files for attachments and copies them into Hugo-appropriate directories, and the next transforms links from Obsidian to Hugo layouts.
+- I frequently wanted to implement multiple features/fixes simultaneously but when this took longer than planned, rolling back to a known-good version was impossible because my docker images are only tagged with `latest`.
+
+All of this added up to things breaking for far longer than they needed to, more often than they needed to. Eventually, enough was enough. I drew a line in the sand and decided that I wasn't going to live like this anymore.
+
+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.
+
+## Why does it work?
+My current solution relies on a few pieces: `bump` and my Makefile invoking some git commands.
+```Makefile {title="Makefile"}
+VERSION ?= $(shell git -C "$(MD)" describe --tags --dirty=-dev)
+COMMIT_ID := $(shell git -C "$(MD)" rev-parse HEAD | head -c8)
+
+setup-bump:
+ go install github.com/therealfakemoot/bump@latest
+
+bump-major: setup-bump
+ bump major
+
+bump-minor: setup-bump
+ bump minor
+
+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.
+
+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?
+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.
diff --git a/content/posts/validating-yaml-frontmatter-with-jsonschema/index.md b/content/posts/validating-yaml-frontmatter-with-jsonschema/index.md
new file mode 100644
index 0000000..43bc442
--- /dev/null
+++ b/content/posts/validating-yaml-frontmatter-with-jsonschema/index.md
@@ -0,0 +1,146 @@
+---
+draft: false
+title: "Validating YAML frontmatter with JSONSchema"
+aliases: ["Validating YAML frontmatter with JSONSchema"]
+series: []
+date: "2023-06-01"
+author: "Nick Dumas"
+cover: ""
+keywords: ["", ""]
+summary: "As a collection of Markdown documents grows organically, maintaining consistency is important. JSONSchema offers a way to automatically ensure frontmatter stays up to spec."
+showFullContent: false
+tags:
+- yaml
+- jsonschema
+- golang
+- obsidian
+-
+---
+## Consistency is hard
+Over my time using Obsidian, I've independently authored around 400 notes. Over time I've had a relatively consistent schema for my tags and frontmatter attributes:
+```markdown
+---
+publish: false
+summary: ""
+aliases: []
+title: ""
+source: []
+tags:
+
+- Status/New
+---
+```
+
+Getting too deep into what all of these mean is outside the scope of this post. For now, it's enough to know that for any Obsidian note, these properties must be present in order for my pipelines to do their job.
+
+## Manually Managed Metadata
+Until now, I managed my note frontmatter by hand, or with `sed`/`grep`. I've got a bit of experience using these tools to manipulate text files, so it's been relatively comfortable but extremely manual.
+
+## Configuration Drift
+The problem is that over time, humans get sloppy, forget things, decide to do things differently. In practice, this doesn't impact the usage of my vault in Obsidian; I access most of my notes via the Quick Switcher so filenames and aliases are the things I really focus on.
+
+A place where consistency does matter is when you're automating tasks. Tools that work with Markdown like static site generators care a lot about frontmatter metadata.
+
+For these tools to work the way I expect and need them to, I need to **guarantee** that my notes are configured correctly.
+
+## What are the options?
+This is a project I've been meditating on for a long time. The specific problem I had is that most markdown frontmatter is YAML. I'd done cursory searching and come up with no satisfying results for a "YAML schema engine", something to formally validate the structure and content of a YAML document.
+
+I was a fool. For years I'd know that YAML was a superset of JSON, and I'd assume that the superset part meant that no tool that expects JSON could ever be guaranteed work on YAML and that's not acceptable for automation.
+
+The detail that matters is that only the *syntax* is a superset of JSON. The underlying data types: null, bool, integer, string, array, and object, still map onto JSON 1 to 1. With that revelation, my work could finally begin.
+## golang and jsonschema
+My implementation language of choice is Go, naturally. Speed, type-safety, and cross-compilation all make for a great pipeline.
+
+```go
+import (
+ "fmt"
+ "io"
+
+ "github.com/santhosh-tekuri/jsonschema/v5"
+ _ "github.com/santhosh-tekuri/jsonschema/v5/httploader"
+ "gopkg.in/yaml.v3"
+)
+
+func Validate(schemaURL string, r io.Reader) error {
+ var m interface{}
+
+ dec := yaml.NewDecoder(r)
+ err := dec.Decode(&m)
+ if err != nil {
+ return fmt.Errorf("error decoding YAML: %w", err)
+ }
+
+ compiler := jsonschema.NewCompiler()
+ schema, err := compiler.Compile(schemaURL)
+ if err != nil {
+ return fmt.Errorf("error compiling schema: %w", err)
+ }
+ if err := schema.Validate(m); err != nil {
+ return fmt.Errorf("error validating target: %w", err)
+ }
+
+ return nil
+}
+```
+
+`Validate()` is basically all you need in terms of Go code. The [full code repo](https://code.ndumas.com/ndumas/obsidian-pipeline) has a bit more complexity because I'm wiring things through Cobra and stuff, but here's some sample output:
+
+```
+go run cmd/obp/*.go validate -s https://schemas.ndumas.com/obsidian/note.schema.json -t Resources/blog/published/
+2023/06/01 10:31:27 scanning "mapping-aardwolf.md"
+2023/06/01 10:31:27 scanning "schema-bad.md"
+2023/06/01 10:31:27 validation error: &fmt.wrapError{msg:"error validating target: jsonschema: '' does not validate with https://schemas.ndumas.com/obsidian/note.schema.json#/required: missing properties: 'title', 'summary', 'tags'", err:(*jsonschema.ValidationError)(0xc0000b3740)}
+2023/06/01 10:31:27 error count for "schema-bad.md": 1
+2023/06/01 10:31:27 scanning "schema-good.md"
+```
+
+You get a relatively detailed summary of why validation failed and a non-zero exit code, exactly what you need to prevent malformed data from entering your pipeline.
+
+### how to schema library?
+You might notice that when I specify a schema, it's hosted at `schemas.ndumas.com`. [Here](https://code.ndumas.com/ndumas/json-schemas) you can find the repository powering that domain.
+
+It's pretty simple, just a handful of folders and the following Drone pipeline:
+```yaml
+kind: pipeline
+name: publish-schemas
+
+clone:
+ depth: 1
+
+
+steps:
+- name: publish
+ image: drillster/drone-rsync
+ settings:
+ key:
+ from_secret: BLOG_DEPLOY_KEY
+ user: blog
+ port: 22
+ delete: true
+ recursive: true
+ hosts: ["schemas.ndumas.com"]
+ source: /drone/src/
+ target: /var/www/schemas.ndumas.com/
+ include: ["*.schema.json"]
+ exclude: ["**.*"]
+```
+
+and this Caddy configuration block:
+```caddy
+schemas.ndumas.com {
+ encode gzip
+ file_server {
+ browse
+ }
+ root * /var/www/schemas.ndumas.com
+}
+```
+
+Feel free to browse around the [schema site](https://schemas.ndumas.com).
+
+## Success Story???
+At time of writing, I haven't folded this into any pipelines. This code is basically my proof-of-concept for only a small small part of a larger rewrite of my pipeline.
+
+### Future Use Cases
+The one use-case that seemed really relevant was for users of the Breadcrumbs plugin. That one uses YAML metadata extensively to create complex hierarchies and relationships. Perfect candidate for a schema validation tool.
\ No newline at end of file
diff --git a/content/series/aardwolf-adventures/_index.md b/content/series/aardwolf-adventures/_index.md
new file mode 100644
index 0000000..45768ef
--- /dev/null
+++ b/content/series/aardwolf-adventures/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Trying to break Aardwolf"
+summary: "A game of life and death and stockpiling pocket portals"
+---
+In a friendly competitive sense, of course. The game at its core is about speed and finding shortcuts, usually through space.
\ No newline at end of file
diff --git a/content/series/blogging-with-quartz/_index.md b/content/series/blogging-with-quartz/_index.md
new file mode 100644
index 0000000..8f05b75
--- /dev/null
+++ b/content/series/blogging-with-quartz/_index.md
@@ -0,0 +1,8 @@
+---
+title: "Authoring a blog in Markdown"
+summary: "Blogging for fun and posterity (myself)"
+---
+
+The core thesis of this project is using [Obsidian](https://obsidian.md) for authoring my blog posts. I'm a big fan of Markdown for authoring and Obsidian's already where I keep my notes. It's gone through a lot of iterations, but the current version uses Gitea, Drone, and a few Docker images I've built that do various types of sanitizations/transformations.
+## A Confession
+I'm not using quartz anymore. Oops. This series has been in the works for a long time and I ended up committing more firmly to Hugo than to Quartz in particular. For a few reasons I'd rather not do a bunch of renaming, I'm just going to preserve the name as-is. Apologies for any confusion.
\ No newline at end of file
diff --git a/content/series/building-with-bazel/_index.md b/content/series/building-with-bazel/_index.md
new file mode 100644
index 0000000..82ecf50
--- /dev/null
+++ b/content/series/building-with-bazel/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Building with Bazel"
+summary: "Bazel is an extremely opinionated but powerful build system"
+---
+Bazel is a build system with a lower profile than stuff like cmake or gradle, and it's more esoteric by a significant margin. In particular, the ecosystem is going through a migration between different ways to handle dependencies and it seems to be going about as smoothly as the Go 1.11 transition.
\ No newline at end of file
diff --git a/content/series/genesis-development/_index.md b/content/series/genesis-development/_index.md
new file mode 100644
index 0000000..92ae32e
--- /dev/null
+++ b/content/series/genesis-development/_index.md
@@ -0,0 +1,3 @@
+---
+title: "Genesis Development"
+---
diff --git a/content/series/path-of-market/_index.md b/content/series/path-of-market/_index.md
new file mode 100644
index 0000000..3f2d37a
--- /dev/null
+++ b/content/series/path-of-market/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Path of Market"
+---
+A brief foray into market manipulation in an ARPG. I wanted to learn Prometheus and make a bit of walking-money on the side.
\ No newline at end of file
diff --git a/layouts/partials/extend-head.html b/layouts/partials/extend-head.html
index 3130418..60e0cc0 100644
--- a/layouts/partials/extend-head.html
+++ b/layouts/partials/extend-head.html
@@ -1 +1,2 @@
-
+{{ $trimmedURL := trim (index (split (urls.AbsURL "") "://") 1) "/" }}
+
This post is part of the {{ .LinkTitle }} series.
+ + {{- end -}} + {{- $series := where .Site.RegularPages.ByDate ".Params.series" "intersect" .Params.series -}} + {{- with $series -}} +-
+ {{- range . -}}
+
- + {{- if eq .File.UniqueID $.File.UniqueID -}} + {{ .Title }} + {{- else -}} + {{ .Title }} + {{- end -}} + + {{- end -}} +