Hi On Thu, Aug 21, 2025 at 06:03:12PM +0200, Kacper Michajlow via ffmpeg-devel wrote: [...] > Also on the topic of CI, I suspect we might add more jobs as needed. > Probably depends on priorities, to not overload existing runners > capacity. > > I was wondering about integrating CIFuzz. Which basically runs fuzzers > based on coverage data that are affected by the PR changes. And runs > fuzzing for N minutes. This would allow it to catch trivial issues, > quickly and without the need for turnaround until the issue is > reported in the oss-fuzz infra. It uses existing corpus to seed the > fuzzing, so it should be good at catching things that are not "hidden" > too deep. Though this brings challenges, because it likely would need > a separate pool of workers to not starve and build jobs. And not sure > how well it would work in practice. For example if change touches too > many fuzzers, it wouldn't manage to run them in the time limit of say > 20-30 minutes, which is probably the reasonable target. Though all > ffmpeg fuzers are specialized for codes, so codec specific code should > be fine to test. This is burning CI minutes, but if we have some to > spare, say from GH workers, it could help to weed out issues quickly. > Thoughts?
immedeate fuzzing for pr, approved thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
