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.
- Report 01
A summary on the job
What passed, what failed and what was skipped, with a table of everything that failed.
- Report 02
Failures on the diff
Each failing scenario annotated on the pull request, with what it checked and what changed.
- Report 03
Findings in the pull request
The result lands in the conversation, so reviewers read it where they already are.
- Report 04
JUnit for your own tools
A standard report your existing dashboards and reporters already know how to read.
01What 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.
02Does 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.
03Does 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.
04What 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.
05How 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.
06Does 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.
07Which 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.