idk why this link disappeared

drone-plugins/sanitize-links/tmp/blog/contents/notes/demo-post/index.md

@@ -20,7 +20,7 @@ For a long time, this has been a really uncomfortable process and is part of why
 
 I want every push to my blog repository to generate a new hugo build and publish my content somewhere. The tools I've chosen are [gitea](/posts/gitea-lfs-and-syncing-obsidian-vaults) for managed git services, [drone](https://www.drone.io/) for continuous integration/deployment, and hugo to build the site.
 
-## Hello Drone 
+## Hello Drone
 
 Standing up a working Drone instance involves a few moving pieces:
 1) configure an `ouath2` application in your hosted git service with which to authenticate your Drone instance
@@ -89,7 +89,7 @@ networks:
     name: cicd_net
 ```
 
-All of the `docker-compose` files were ripped straight from documentation so there's very little surprising going on. The most common pitfall seems to be setting `DRONE_PROTO_HOST` to a URL instead of a hostname. 
+All of the `docker-compose` files were ripped straight from documentation so there's very little surprising going on. The most common pitfall seems to be setting `DRONE_PROTO_HOST` to a URL instead of a hostname.
 
 For me, the biggest hurdle I had to vault was SELinux. Because this is a fresh Fedora install, SELinux hasn't been relaxed in any way.
 
@@ -131,11 +131,11 @@ docker-compose -f docker-compose/drone.yml up  -d
 caddy start --config caddy/drone --adapter caddyfile
 ```
 
-The startup script, `drone.sh` injects some environment variables. Most of these are boring but `DRONE_RPC_SECRET` and `DRONE_USER_CREATE` are the two most important. This script is set up to make these deterministic; this will create an admin user whose access token is the `md5` of your host machine's hostname. 
+The startup script, `drone.sh` injects some environment variables. Most of these are boring but `DRONE_RPC_SECRET` and `DRONE_USER_CREATE` are the two most important. This script is set up to make these deterministic; this will create an admin user whose access token is the `md5` of your host machine's hostname.
 
 This really saved my bacon when I realized I didn't know how to access the admin user for my drone instance when I needed it. Diving into your Drone instance's database is technically on the table, but I wouldn't advise it.
 
-## It's pipeline time 
+## It's pipeline time
 Once I had drone up and running, getting my blog publishing pipeline going was a relatively straightforward process: write a pipeline step, commit, push, check Drone for a green build. After a couple days of iterating, the complete result looks like this:
 
 ```yaml
@@ -175,13 +175,15 @@ The steps are pretty simple
 ## Green checkmarks
 At this point, I've got a fully automated publishing pipeline. As soon as a commit gets pushed to my blog repository, Drone jumps into action and runs a fresh Hugo build. The process is far from perfect, though.
 
+![[Resources/attachments/obsidian-pipeline-screenshot.png]]
+
 ![[notes/drone-and-hugo/obsidian-pipeline-screenshot.png]]
 
 You might've noticed a lack of screenshots or other media in my posts. At the moment, I'm authoring my blog posts in [Obsidian](https://obsidian.md), my preferred note-taking application, because it gives me quick access to...well, my notes. The catch is that Obsidian and Hugo use different conventions for linking between documents and referencing attachments/images.
 
-In the long term, what I want to do is probably write a script and pipeline which can 
+In the long term, what I want to do is probably write a script and pipeline which can
 1) convert Obsidian-style links and frontmatter blocks to their Hugo equivalents, so I can more easily cross-link between posts while drafting
-2) Find embedded media ( images, etc ) and pull them into the blog repository, commit and push to trigger the blog publish pipeline. 
+2) Find embedded media ( images, etc ) and pull them into the blog repository, commit and push to trigger the blog publish pipeline.
 
 ## Unsolved Mysteries
 
@@ -194,4 +196,4 @@ volumefix.te:24:ERROR 'syntax error' at token 'mlsconstrain' on line 24:
 mlsconstrain sock_file { write setattr } ((h1 dom h2 -Fail-)  or (t1 != mcs_constrained_type -Fail-) ); Constraint DENIED
 #       mlsconstrain sock_file { ioctl read getattr } ((h1 dom h2 -Fail-)  or (t1 != mcs_constrained_type -Fail-) ); Constraint DENIED
 /usr/bin/checkmodule:  error(s) encountered while parsing configuration
-```
+```