Hi — I’m Stefan. I’m 48, and I wrote my first line of code in May 2025.
Eight months later I’m shipping my first serious open-source devtool and I’d love feedback from people who use GitHub Actions in real projects.
The problem: CI/workflow drift
Once you maintain more than one repo, things slowly break:
workflows get copied and tweaked “just for this repo”
pinned versions and configs diverge quietly
a PR merges even though CI policy got weakened
I hit this repeatedly while working on multiple repos, so I built a guardrail.
Cerber Core — a CI “contract guard” for GitHub Actions
Cerber Core enforces a single source of truth for CI. It detects workflow/config drift before merge and fails the PR if required checks, pinned versions, or CI rules drift from the contract.
Repo: https://github.com/Agaslez/cerber-core
Discord (feedback): https://discord.gg/V8G5qw5D
Quick start
npx cerber doctor
Reusable workflow (minimal example)
jobs:
quality-gate:
uses: Agaslez/cerber-core/.github/workflows/cerber.yml@v1
Feedback wanted (3 questions)
Scope: what should a CI “contract” validate first — workflows only, pinned versions/env, repo structure, security checks?
UX: is npx cerber doctor the right entry point? what output would make you trust this tool?
Adoption: what would make you try it in a real repo — 1-minute setup, zero config, drop-in reusable workflow, something else?
If you’ve ever had CI drift bite you (PR passed but production broke), I’d love to hear the story.
How to help in 60 seconds:
run npx cerber doctor
paste the output (redact secrets) or share a CI run link
tell me what you expected vs what happened
Thanks
Top comments (0)