A release is just another merge request
Moving off tag-on-merge releases, where a release is a side effect of merging, to a model where the release is itself a reviewable change.
Tags
13 pages
GitLab
The component that fired on every schedule
A CI component gated on the default branch fired on every Renovate schedule too, because a scheduled run is also on the default branch.
Stop installing the same tools on every pipeline job
Nearly every CI job began by fetching and compiling the same tools. Baking them into one image instead, and what that saved per pipeline.
The build gate these sites never had
Three Hugo sites each hand-rolled a near-identical deploy job that only ever ran on merge, so nothing ever checked the build before it landed.
The secret that wasn't on my branch
A secret scanner failed a merge request over a test key and a documentation PEM that the change did not contain. Scoping a scan properly.
Sign your own binaries with go-tool-base, part 3: keyless CI signing with OIDC
Let CI sign with a KMS key without storing any AWS credentials, using OIDC federation. Covers both the GitLab and the GitHub path.
From allow_failure to blocking
Turning three advisory CI jobs into real gates once they were trustworthy enough to block a merge, and how to tell when they are.
Moving this blog off Jekyll
Moving this blog from Jekyll and GitHub Pages to Hugo and GitLab Pages, and the two things I would do differently next time.
Two bugs that taught me the rules
Two CI and infrastructure bugs with one shape: a GitLab job with no rules block skips merge requests, and an import block runs only once.
Reviewed, then applied
Closing the plan-versus-apply gap in infrastructure CI by applying the saved plan artifact rather than quietly re-planning at apply time.
