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 every change arrives verified.
Every change is proven against your running app before it 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 inside the review.
Fast, reproducible runs
Every test runs from what is already committed, 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 lands in the conversation, so reviewers read it where they already are.
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. Every step is deterministic, 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 exactly what is in the repository, 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, counted separately from the ones that passed, and the check still succeeds. Coverage should mean assertions that ran.
How do tests that need a database or a secret work?
Values come from your CI secrets, 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 the whole integration is a single step. On GitHub Actions a published action wraps that step for you.