Closed evverx closed 2 years ago
Thanks a lot! Looks good! I will wait for the fuzzer changes to be merged, then take another look at this one.
@dvdhrm now that the fuzz target is merged I think this PR should be good to go. I also rolled out the alignment check in https://github.com/google/oss-fuzz/pull/8055 just in case.
Thank you very much for going through with this! I now merged this and pushed a follow-up where I did minor coding-style adjustments (eg., we do not indent arrays in yml), and I moved it to fuzzer.yml
rather than cifuzz.yml.
I wonder whether it is worth it running this on every PR. We do not get unlimited time on the github CI, and I don't mind too much catching things a bit late on main
. But lets deal with that if CI times become an issue.
Again, thanks a lot for working on this and keeping an eye on the upstream PR!
We do not get unlimited time on the github CI
dbus-broker
is a public repository so it should receive as many free minutes as it needs. The only limit is the number of concurrent jobs but I don't think the repository should hit it very often. Things get complicated when public repositories are forked and moved to private repositories (where https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions kicks in) but this scenario is already covered by skipping CIFuzz outside of the dbus-broker repository.
We do not get unlimited time on the github CI
dbus-broker
is a public repository so it should receive as many free minutes as it needs. The only limit is the number of concurrent jobs but I don't think the repository should hit it very often.
Yes, yes, this was what I meant. The concurrency is pretty low (4?) and if you have them all occupied with 1h jobs, trivial unit-tests in other repositories needlessly have to wait for 1h. This can be a bit annoying. But lets deal with that when it becomes a problem.
The concurrency is pretty low (4?)
I think it should be 20 by default.
if you have them all occupied with 1h jobs, trivial unit-tests in other repositories needlessly have to wait for 1h. This can be a bit annoying.
Agreed. It's annoying when it happens. CIFuzz should run for 10 minutes though. Let me double-check just in case.
But lets deal with that when it becomes a problem.
Agreed.
FWIW dbus-broker
(or, more precisely, OSS-Fuzz) appears to have hit some limit somewhere but it should be addressed in https://github.com/google/oss-fuzz/issues/8067.
The concurrency is pretty low (4?)
I think it should be 20 by default.
Indeed it is 20. I had remembered 4, but that might be from the initial beta phase still. This explains why I barely saw concurrency issues. 20 seems fine for now.
if you have them all occupied with 1h jobs, trivial unit-tests in other repositories needlessly have to wait for 1h. This can be a bit annoying.
Agreed. It's annoying when it happens. CIFuzz should run for 10 minutes though. Let me double-check just in case.
Yes, they stop after 10min. That should be fine!
https://google.github.io/oss-fuzz/getting-started/continuous-integration/
Depends on https://github.com/google/oss-fuzz/pull/7870