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.