Looks like I’m averaging about one “weeknotes” post every two weeks. That’s actually not too bad!

Well this has already been an interesting experiment. Only one week in, and I already feel more motivated and focused to work on personal projects and the goals that I’d set. Some of that might just be the ephemeral “New System Energy” that is plentiful when you start a new organizational system or habit, but what the hey; even if it’s fleeting, I’ll gladly ride it as far as I can!

As I hoped in my last post, I’ve set up Gitea Actions on my homelab, with a view to completely replacing Drone which I’ve found to be pretty buggy and missing some core features¹. The process was reasonably smooth, but not entirely turnkey, so I’ve laid out the steps I took in the hopes that they’ll help someone else.

I’ve recently been struggling with a feeling of lack of tangible progress towards goals, or even of any idea of what those goals are or should be. Inspired both by GTD and by Simon Willison’s practice, I’ve decided to start writing “weeknotes” - records of what I’ve done each week, and what I’d like to focus on.

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

When working on my personal projects, I typically just push straight to main - opening a PR just to approve it seems entirely pointless, as if I had been able to find any issues in my own work, I wouldn’t wait to do it in a PR! However, this does mean that, if I forget to run any quality checkers (linters, tests, etc.), I won’t find out about it until on: push GitHub Action runs, and even then I might not see the failure until several commits later.

It’s fairly uncontroversial that, for a good service-deployment pipeline, there should be:

• at least one pre-production stage
• automated tests running on that stage
• a promotion blocker if those tests fail

The purpose of this testing is clear: it asserts ("verifies") certain correctness properties of the service version being deployed, such that any version which lacks those properties - which “is incorrect” - should not be deployed to customers. This allows promotion to be automated, reducing human toil and allowing developers to focus their efforts on development of new features rather than on confirmation of the correctness of new deployments.

I just added a process to my blog deployment pipeline to block the deployment of any blogs that contain the characters “T​K”.

Observant readers of this blog, refreshing every day desperate for new content, will have noticed that the last blog post - dated 2022-12-31 - actually went live in the middle of January. My k3s cluster, which had always been a bit rickety, finally gave up the ghost in late December, and two of the nodes needed to be fully reimaged before I could start it back up again.

Since leaving Amazon ~4 months ago and dedicating more time to my own personal projects (and actually trying to ship things instead of getting distracted a few days in by the next shiny project!), I’ve learned a lot more about the Open Source tools that are available to software engineers; which, in turn, has highlighted a few areas of ignorance about CI/CD Pipelines. Emulating Julia Evans, I’m writing this blog both to help lead others who might have similar questions, and to rubber-duck my own process of answering the questions.