CI/CD, and getting things released

Pipelines you include rather than copy, a toolchain baked into one image, and a release that is just another merge request. Plus the jobs that silently never ran, and the component that fired on every schedule.

14 posts

Start here

The two ideas the rest of this rests on: stop copying pipelines, and stop reinstalling the same tools.

  1. CI you include, not copyCopied .gitlab-ci.yml files drift out of sync. How GitLab CI/CD Components let a repo include and version-pin a shared pipeline instead. Pioneering
  2. Stop installing the same tools on every pipeline jobNearly every CI job began by fetching and compiling the same tools. Baking them into one image instead, and what that saved per pipeline. Pioneering
  3. One image for the whole toolchainBaking OpenTofu, tflint and trivy into a single version-pinned CI image, and publishing the scanned tarball with crane to avoid a kaniko rebuild. Pioneering

Releases

Making a release a reviewable change rather than a side effect of merging.

  1. A release is just another merge requestMoving 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. Pioneering
  2. Same config, two answersPublishing a seventeen-crate Rust workspace to crates.io, and why the same release configuration produced two different answers. Pioneering
  3. Three traps release-plz sets for a Rust workspaceThree traps release-plz sets for a Rust workspace, starting with a default tag template that collides the moment you have more than one crate. Pioneering
  4. The version pin you can't lowerA standard-library security fix forced a Go version bump, and then the release failed because the build image shipped an older toolchain. Pioneering

Gates worth having

When an advisory job earns the right to block a merge, and what happens when one never runs at all.

  1. From allow_failure to blockingTurning three advisory CI jobs into real gates once they were trustworthy enough to block a merge, and how to tell when they are. Pioneering
  2. The build gate these sites never hadThree 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. Pioneering
  3. Two bugs that taught me the rulesTwo CI and infrastructure bugs with one shape: a GitLab job with no rules block skips merge requests, and an import block runs only once. Pioneering
  4. The component that fired on every scheduleA CI component gated on the default branch fired on every Renovate schedule too, because a scheduled run is also on the default branch. Pioneering

Where it runs

The platform decision, and the credentials the pipeline does not hold.

  1. Why go-tool-base left GitHub for GitLabAn accidental major version bump was the last straw after months of unreliability. Why a Go framework moved off GitHub, and what moved with it. Pioneering
  2. No access keys in CIReplacing long-lived AWS access keys in CI with OIDC federation, so the pipeline mints a short-lived token instead of holding a secret. Pioneering
  3. The secret that wasn't on my branchA secret scanner failed a merge request over a test key and a documentation PEM that the change did not contain. Scoping a scan properly. Pioneering

Where to next

Everything, newest first →