-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Measure code coverage in CI and use as a merge gate #1049
Comments
Like codecov? |
+1 - I would like to see something like this across Istio tbh |
My 2c:
|
Reasoning? No CI check == license to ignore, most of the time, practically speaking. A hard check would probably be less noisy and far more practical use than the current "go test nag". Note that I'm not saying that the coverage watermark % couldn't be stored in a makefile and bumped up or down in a PR, but at least that way people have to make a case for it and it has to be visible/approved - we know the coverage has gone up or down, and there's a public record of why.
👍 When developing the inpod CNI internally we used
tl;dr: I really don't want to use anything that can't work locally AND as a simple makefile target.
We do need that, but connecting that up with daily practice in the CI versus the honor system is usually simpler and more consistent. If it's something a reviewer might ask a PR author to copypaste, we should just check it implicitly in CI. |
At one point we had coverage on testgrid; can we just do that again as a first step? |
|
no stale |
Code coverage for ztunnel was audited at a point-in-time: #16
but we don't have a good ongoing sense of what chunks have poor unit test coverage, and we don't have a good ongoing sense of where adding more cheap unit tests would bring the most value, and we generally want to encourage more, cheaper, easier to debug/maintain unit tests, and fewer, expensive, harder to debug/maintain integ/e2e tests.
We should generate code coverage stats (per branch/per func) as part of PR CI, and compare it with the current high-watermark in mainline, and warn/fail the CI check if coverage drops below the current high-watermark.
(usual caveat - code coverage is not the only proof of good code coverage or useful tests, but it is the easiest to automate, and hard to casually cheat)
The text was updated successfully, but these errors were encountered: