-
Notifications
You must be signed in to change notification settings - Fork 66
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
CI job for verifying coverage increase #166
Comments
DrahtBot can (manually triggered) create html coverage reports. See https://github.com/maflcko/DrahtBot/blob/main/coverage_fuzz/src/main.rs#L151 and https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/004367dba8a3e852/428a2e7b0def5102/fuzz.coverage/index.html libFuzzer could also be used by using the
|
Fixed in bitcoin/bitcoin#29329 |
I presume the plan is to use that for a new CI job here? i.e. run once for both qa-assets from main and the pr, then compare coverage summary for relevant harnesses and if the coverage does not go up fail the job |
I think for now the comparison can be done manually, but a CI task to run |
Another idea to limit the added files would be to re-create the merge step in the CI and abort if the difference in added files is larger than 30% or some magic value? |
Maybe I’m just going about it wrong, but it’s kinda annoying to do it manually. So far I’ve been doing:
Am I overlooking an automated tool or smth? |
If you don't want to spend CPU locally, and you trust the CI, you can fetch the results from:
The last step will still have to be done manually as well. |
I’ve been able to streamline the last step:
|
We could consider adding a CI job that checks that the coverage for newly added inputs actually goes up (this should be possible with
afl-showmap
). This would help with review and avoiding bloat in the corpora.(Fuzz harnesses with low stability could be annoying here)
The text was updated successfully, but these errors were encountered: