Show DEV: I Built a Bayesian GitHub Action to Find the Commit That Broke Your C++ Project

Show DEV: I Built a Bayesian GitHub Action to Find the Commit That Broke Your C++ Build

Hey DEV community! 👋

I've been experimenting with probability theory and wanted to see whether Bayes' theorem could help identify which commit caused a failed CI build.

So I built BayesCI, an open-source GitHub Action powered by a small Bayesian engine written in C, with Python handling Git analysis and compiler diagnostics.

The problem

Imagine you've made several commits, pushed your changes, and suddenly your C++ build fails:

undefined reference to `calculate_total'
collect2: error: ld returned 1 exit status

The compiler tells you what failed, but not necessarily which commit introduced the problem.

That's what BayesCI tries to help with.

How it works

BayesCI:

• Reads GCC, Clang, linker, and CMake diagnostics.
• Examines commits since the last successful build.
• Analyzes changed files, symbols, lines, and build configuration.
• Uses Bayesian ranking to identify suspicious commits.
• Displays the results directly in GitHub Actions Summary.

No paid AI APIs or external services required.

How will it be shown in user experience

Why did I choose C for the core?

I intentionally separated the Bayesian computation engine from the log parsing logic.

The idea was to keep the mathematical core independent of any particular programming language or CI system.

Right now, Python handles compiler diagnostics and Git analysis, while C performs the Bayesian calculations.

But what if someone wants to implement their own parser? Or integrate the ranking engine into a completely different tool?

That's exactly why I chose C.

You can compile the core as a shared library (.dll on Windows or .so on Linux) and call it from another language through its C interface.

Want to write your own log parser in Rust? Go ahead.

Want to build a GUI in C#? You can reuse the same computational core.

Want to replace my Python implementation entirely? That's fine too.

The parser is replaceable. The mathematical engine is reusable.

Does it work?

I tested it on 20 synthetic failure scenarios:

• 20/20 — diagnostics successfully parsed.
• 19/20 — culprit appeared in the displayed Top 3.
• 11/20 — culprit was the unambiguous Top-1 result.

These are synthetic tests, not real-world accuracy guarantees. The reported scores are heuristic relative rankings, not calibrated probabilities.

Why I think this is useful

Especially with AI-assisted coding, it's easy to generate multiple changes before discovering that a build has broken.

BayesCI can help narrow down the investigation and provide more useful context for tools like Claude Code or Cursor.

Everyone is welcome — KISS & Install and Forget

I want BayesCI to be a genuinely community-driven open-source project.

At this early stage, I'm welcoming contributions from absolutely anyone, regardless of experience level.

Are you a high school student? A university student? A beginner who just learned their first programming language? Or an experienced developer?

I don't care about your background. If you have an idea, you're welcome here.

Fork the repository, experiment, open issues, submit pull requests, or build something completely different on top of the project.

I'm open to contributions of all kinds. My main concern during review is security, not whether you're an experienced programmer or whether your implementation matches my personal preferences.

Want to write a parser in Java? Do it.

Prefer Rust, Go, C#, JavaScript, or something else? Go for it.

Want to build a desktop GUI, web dashboard, or your own CI integration? That's awesome.

You can simply use the existing C computational engine as a shared library and build everything else however you like.

And if you're stuck, feel free to ask questions. I'll do my best to help.

The project follows two core principles:

1. KISS — Keep It Simple, Stupid.

The mathematical core should remain small, understandable, and lightweight. I don't want unnecessary abstractions, complicated dependencies, or complexity just for the sake of complexity.

2. Install and Forget.

For end users, the experience should be as simple as possible:

Install BayesCI once, configure it, and forget about it.

When a supported CI build fails, BayesCI should automatically analyze the failure and provide useful results without requiring constant manual intervention.

Freedom for contributors. Simplicity for users.

That's the philosophy I want to build this project around.

Try it out

GitHub: https://github.com/austinkilla228-art/BayesCI

Stable release: v1.0.0

The project is fully open source and open to contributions.

Feel free to fork it, experiment with the C engine, create alternative implementations, or submit your ideas.

I'm particularly interested in feedback on the Bayesian model, diagnostic accuracy, and possible integrations.

What do you think? Would this be useful in your CI workflow?