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.
Categories
15 pages
cicd
Reusable GitLab CI/CD components I include rather than copy across my projects, so the pipeline lives in one place instead of drifting copy-paste in every repo.
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.
Three traps release-plz sets for a Rust workspace
Three traps release-plz sets for a Rust workspace, starting with a default tag template that collides the moment you have more than one crate.
Same config, two answers
Publishing a seventeen-crate Rust workspace to crates.io, and why the same release configuration produced two different answers.
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.
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.
