blogcontent/blog/content/posts/auto-announce-on-mastodon.md
2024-06-07 04:58:00 -07:00

3.7 KiB

title date draft tags
Auto Announce on Mastodon 2024-06-03T07:37:28-07:00 true
CI/CD
homelab
meta
vault

(TK THIS IS A DRAFT POST - you shouldn't actually be seeing this! Please let me know if you are :P )

I just set up a step in my publication pipeline to automatically post on Mastodon when I publish a new blog post.

The Mastodon API for posting is pretty easy, per this guide. I grabbed a Mastodon token and put it into Vault to be accesible (as detailed in [previous]({{< ref "/posts/vault-secrets-in-k8s" >}}) [posts]({{< ref "/posts/base-app-infrastructure" >}})) to the CD pipeline.

Accessing Kubernetes secrets in Drone pipelines required installing the Kubernetes Secrets Extension1, which was fairly easy TK link. I already had Vault->Kubernetes Secret integration set up, so plumbing the secret in was easy.

Actually fetching the secret from Kubernetes into Drone required installation of the Kubernetes Secret Extension, which has slightly misleading documentation - the docs instruct you to "[d]eploy the secret extension in the same Pod as your Kubernetes runner.", but it seems that this is unnecessary and the extension can be deployed as a standalone pod (indeed, there's a whole standalone Helm chart for it)

footnote - sketchy docs? This and https://docs.drone.io/secret/external/kubernetes/ appear to have the same intro paragraph, and extension suggests the container must be installed in the same Pod as the runner, but the existence of the chart belies that. Also usage docs here are missing the requirement to specify a repo (Error: Invalid or missing repository (e.g. octocat/hello-world).). And the example here And the docs on referencing a k8s secret don't show how to specify a namespace

TK reconsider the uselessness of OSS pipelines. Maybe they do work ok if you view the unit-of-work as an execution (start-to-finish) which terminates on a test failure, rather than the unit being a change-being-deployed (which should be "visible" and "manually promoteable"). Under this model, you can limit the "pipeline" to only having one execution running at once (i.e. there cannot be two changes "flowing" through the pipeline at once), and almost-all desired functionality then just drops out.


  1. Note that Drone actually has the capability to access Vault secrets directly without importing them into Kubernetes, but I'd rather stick with the established access method that I already know about unless there are use-cases for which it doesn't work. In particular, note that the Kubernetes Secrets Extension has an available Helm chart but the Vault Secrets Extension doesn't ↩︎