Codecov components were configured. Five components, clean breakdown by package.
Codecov dashboard: "No report uploaded" for all components.
Coverage uploaded successfully. Components showed zero coverage.
The paths looked correct.
secrets: inheritCODECOV_TOKEN worked perfectly in ci.yml.
Called ci.yml from release.yml as a reusable workflow. Codecov failed:
Same token. Same workflow. Different result.
The deployment worked in dev. Unit tests passed. Code review approved. Merged to main.
Production exploded.
The config used a dev secret. Migration locked tables at scale. Feature flag on in staging. Off in prod.
Environmental differences killed us.
The CVE dropped. The container was in production. CRITICAL severity. Remote code execution. Tagged latest.
Nobody knew which deployments used it. Scanning happened post-push. The flaw lived in production six hours.
This is the pattern that stops CVEs before they reach the registry.
The From 5 Seconds to 5 Milliseconds post showed how caching eliminated cluster scans. But that was only half the story. The real magic happens in how events flow through the system.
This is that story.
The email arrived on a Monday. "SOC 2 audit in 30 days. Need evidence of secure development practices."
We had policies. Documentation. Training slides. None of it mattered.
Auditors don't want to hear what you say you do. They want to see what the system forces you to do.
A few days ago I wrote about why release-please PRs don't trigger builds and proposed a dual-trigger pattern as the fix. Today I discovered that pattern is a workaround with side effects. Here's the actual solution.
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.
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.