The quality gate for your backend team.
Kerno verifies the blast radius of every change and drops the report on the pull request, so reviews move faster and nothing slips through.
Every change is proven against your running app, so nothing broken reaches main.
Every change verified before merge
The gate runs on every pull request against your running app, so a change that breaks something cannot merge.
Findings land on the pull request
The result arrives with the diff, so a reviewer sees what the change touched without leaving the review.
Fast, reproducible runs
Nothing is generated at run time, so a run is fast and the same commit always returns the same verdict.
Every run reports on the pull request, so reviewers read the result next to the change.
A summary on the job
What passed, what failed and what was skipped, with a table of everything that failed.
Failures on the diff
Each failing scenario annotated on the pull request, with what it checked and what changed.
Findings in the pull request
The result posted into the conversation, so reviewers see it without opening the run.
JUnit for your own tools
A standard report your existing dashboards and reporters already know how to read.
FAQs
Got any extra questions? Reach out on our community channel and we'll be happy to help.
What runs in CI?
One public image that replays the tests already committed in your repository. Nothing calls a language model, so the same commit always gives the same verdict.
Does CI write or change any tests?
No. Tests are authored on your machine, in your coding session, where you review them before committing. CI replays what is already in the repository and nothing else, and mounts your checkout read-only.
Does Kerno start my app in CI?
No. You start your app in the workflow and pass the URL it answers on. Kerno connects to what you are already running.
What happens to blocked and not-implemented tests?
They come back as skipped and never fail the check, and they are counted separately from the ones that passed. A suite that asserts nothing should not look like coverage.
How do tests that need a database or a secret work?
Values come from your CI rather than from the repository, and you pass them in on the step that runs the tests. The guide covers how.
Does it work across a monorepo?
Yes. Point it at the repository and it covers every service that has committed tests, or name the services and the URLs they answer on. The counts are summed, so one failing test anywhere fails the check.
Which CI providers does this work with?
Any CI that can run a container. One docker run replays your committed tests and exits with the result, so there is nothing else to orchestrate. On GitHub Actions a published action wraps that step for you.