February 22, 2026
Every CI pipeline faces the same tension: run enough tests to catch bugs before they merge, but not so many that developers wait twenty minutes for feedback on a one-line change. The answer is not running everything everywhere. It is running the right tests at the right time.
Tests divide into three tiers based on execution speed, failure signal quality, and infrastructure requirements.
February 21, 2026
A container build that takes eight minutes in CI is not just slow – it compounds across every push, every developer, every day. The difference between a naive Dockerfile and an optimized one is often the difference between a two-minute build and a twelve-minute build. The techniques here are not theoretical. They are the specific changes that eliminate wasted time.
BuildKit is the modern Docker build engine and the default since Docker 23.0. If you are running an older version, enable it explicitly with DOCKER_BUILDKIT=1. BuildKit provides several capabilities the legacy builder lacks.
February 21, 2026
Once you move past single-file workflows that run npm test on every push, GitHub Actions becomes a platform for building serious CI/CD infrastructure. The features covered here – reusable workflows, composite actions, matrix strategies, OIDC authentication, and caching – are what separate a working pipeline from a production-grade one.
A reusable workflow is a complete workflow file that other workflows can call like a function. Define it with the workflow_call trigger:
February 21, 2026
ARM64 is no longer optional infrastructure. AWS Graviton instances, Apple Silicon developer machines, and Ampere cloud hosts all run ARM64 natively. If your CI pipeline only builds and tests on x86, you are shipping untested binaries to a growing share of your deployment targets.
GitHub offers native ARM64 runners. For public repositories, these have been available since late 2024. Private repositories gained access in 2025. Use them with:
Minikube gives you a real Kubernetes cluster wherever you need one – on a developer laptop, in a GitHub Actions runner, or in any CI environment that has Docker. The patterns differ between local development and CI, but the underlying approach is the same: stand up a cluster, deploy your workload and its dependencies, test against it, tear it down.