Testing Mastodon publish

.drone.yml

@@ -14,6 +14,37 @@ platform:
 
 
 steps:
+  # TODO - parse the file itself to a) extract title, and b) not post if it's a draft post
+  - name: mastodon_post
+    image: alpine
+    environment:
+      MASTODON_TOKEN:
+        from_secret: mastodon_access_token
+    commands:
+      - apk add curl git perl
+      - env | grep "MASTODON"
+      - echo "$${MASTODON_TOKEN}"
+      - echo $MASTODON_TOKEN
+      - "git show --name-status --pretty=format: HEAD"
+      - "git show --name-status --pretty=format: HEAD | grep '^A'"
+      - "git show --name-status --pretty=format: HEAD | grep '^A' | awk '{print $2}'"
+      - "ADDED_FILES=$(git show --name-status --pretty=format: HEAD | grep '^A' | awk '{print $2}')"
+      - if [[ "$( echo -n $ADDED_FILES | grep -c '^')" -ne 1 ]]; then
+      -   echo "Non-single file added"
+      - "  echo \"(DEBUG: $ADDED_FILES)\""
+      -   return
+      - fi
+      - NEW_FILE=$(echo $ADDED_FILES | head -n1)
+      - echo "New File is $NEW_FILE"
+      - if ! [[ "$NEW_FILE" =~ ^blog/content/posts/.*  ]]; then
+      -   echo "Sole added file was not a blog post";
+      -   return;
+      - fi
+      # TODO - parameterize hostname
+      - BLOG_URL=$(echo "$NEW_FILE" | perl -pe 's|blog/content|https://blog.scubbo.org|' | perl -pe 's/\.md$//')
+      - echo "Would post to $BLOG_URL"
+      - return 1 # End early so we don't _actually_ publish until confirmed working!
+      #- "curl https://fosstodon.org/api/v1/statuses -H 'Authorization: Bearer $MASTODON_TOKEN' -F 'status=I just blogged! Check it out at $BLOG_URL"
   - name: block-posts-containing-tk
     image: busybox
     commands:
@@ -101,12 +132,3 @@ steps:
         from_secret: telegram_token
       to:
         from_secret: telegram_convo_id
-  - name: mastodon_post
-    image: curlimages/curl
-    environment:
-      MASTODON_TOKEN:
-        from_secret: mastodon_access_token
-    commands:
-      - "env | grep 'MASTODON'"
-      - echo "$${MASTODON_TOKEN}"
-      - echo $MASTODON_TOKEN

blog/content/posts/auto-announce-on-mastodon.md

@@ -0,0 +1,43 @@
+---
+title: "Auto Announce on Mastodon"
+date: 2024-06-03T07:37:28-07:00
+draft: true
+tags:
+  - 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.
+<!--more-->
+The Mastodon API for posting is pretty easy, per [this guide](https://dev.to/bitsrfr/getting-started-with-the-mastodon-api-41jj). 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 Extension](https://docs.drone.io/runner/extensions/kube/)[^can-access-directly], which was [fairly easy]() TK link. I [already had Vault->Kubernetes Secret integration set up](https://gitea.scubbo.org/scubbo/helm-charts/commit/4c82c014f83020bad95cb81bc34767fef2c232c1), so plumbing the secret in was [easy](https://gitea.scubbo.org/scubbo/helm-charts/commit/4cc1c531e270e6fbfd2af0219a0bf2eaa799a75c).
+
+Actually fetching the secret from Kubernetes into Drone required installation of the [Kubernetes Secret Extension](https://docs.drone.io/runner/extensions/kube/), 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](https://github.com/drone/charts/tree/master/charts/drone-kubernetes-secrets))
+
+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](https://github.com/drone/charts/tree/master/charts/drone-kubernetes-secrets) belies that.
+Also usage docs [here](https://docs.drone.io/runner/extensions/kube/) are missing the requirement to specify a repo (`Error: Invalid or missing repository (e.g. octocat/hello-world).`).
+And the example [here](https://docs.drone.io/runner/extensions/kube/)
+And the [docs on referencing a k8s secret](https://docs.drone.io/secret/external/kubernetes/) 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.
+
+[^can-access-directly]: Note that Drone actually has [the capability to access Vault secrets directly](https://docs.drone.io/secret/external/vault/) 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](https://github.com/drone/charts/tree/master/charts/drone-kubernetes-secrets) but the Vault Secrets Extension [doesn't](https://github.com/drone/charts/tree/master/charts)
+
+<!--
+Reminders of patterns you often forget:
+
+Images:
+![Alt-text](url "Caption")
+
+Internal links:
+[Link-text](\{\{< ref "/posts/name-of-post" >}})
+(remove the slashes - this is so that the commented-out content will not prevent a built while editing)
+-->