The workflow looked perfect. CONTRIBUTING.md in our central repository, automatically distributed to all 75 repositories. Any change triggers PRs across the organization.
Then release-please bumped the version from 1.4.1 to 1.4.2.
I wanted to version CONTRIBUTING.md independently from the main project. Separate changelog. Separate release cycle. Separate tags.
Release-please said no.
Every time someone pushed a container image, my Kubernetes API server winced. The workflow that was supposed to be "instant" took 5-10 seconds and hammered the cluster with requests.
This is the story of how I turned that into 5 milliseconds with zero API calls.
Update: There's a Better Way
The dual-trigger pattern described below is a workaround, not the real fix. See The Real Fix for Release-Please Triggers for the proper solution using GitHub App tokens.
The release-please PR looked perfect. Clean changelog. Proper version bump. Ready to merge.
One problem: the build pipeline never ran. Branch protection blocked the merge. No required checks had passed, because no checks had started.
This is the story of a GitHub Actions limitation that wastes hours of debugging time, and the pattern that fixes it in two lines of YAML.
Your workflow failed at step 47 of 50. Do you fix the issue and rerun from the beginning, or do you manually complete the remaining steps?
The Nervousness Test
If that question makes you nervous, your automation isn't idempotent. And that's a problem.
This post shares the journey to making reruns boring. For the full technical deep-dive, see the Idempotency Pattern Guide.
One conditional swap in a change detection script. That's all it took to unblock a file distribution workflow that had been silently failing for weeks.
The bug? git diff --quiet doesn't see untracked files. And when you're distributing files to repositories that don't have them yet, every target file is untracked.
This post dissects the bug, explains why it's so easy to miss, and shows the fix that makes change detection actually work.
Today marks a milestone. The Adaptive Enforcement Lab documentation site is live, and with it, a year's worth of battle-tested patterns for GitHub App automation finally have a proper home.
This wasn't a sprint. It was an on-and-off effort spanning twelve months, guided by a simple principle: one building block at a time. Atomic habits applied to infrastructure. Some weeks meant solving a single authentication edge case. Others meant no progress at all. The pieces accumulated slowly, each one small enough to ship, test, and trust before moving on.
Then came today. A marathon session to wire everything together. The discovery stage that had been working in isolation. The distribution logic refined over months of incremental improvements. The idempotency patterns born from countless failed reruns. Today was assembly day. I took a year of atomic improvements and built the complete content distribution system.
This post covers that journey from "let's automate some file syncing" to "we need enterprise-grade security for 40 repositories."