Support fuzz_targets property in clusterfuzz_manifest.json#5305
Conversation
828343c to
a4fc5d3
Compare
a4fc5d3 to
2647ce6
Compare
letitz
left a comment
There was a problem hiding this comment.
LGTM % understanding build_prefix.
| # selected fuzz targets. | ||
| list_fuzz_target_start_time = time.time() | ||
| self._fuzz_targets = list(build.list_fuzz_targets()) | ||
| _emit_job_build_retrieval_metric(list_fuzz_target_start_time, |
There was a problem hiding this comment.
This is convenient, we'll have a metric to look at when this rolls out that should show us this step taking a lot less time.
letitz
left a comment
There was a problem hiding this comment.
I expect clusterfuzz maintainers will want to see evidence of this working in dev before they land this. Can you try to test it in dev?
|
Have it running on dev and it seems to be working fine on variant tasks (uploaded testcases) and |
|
@vitaliset friendly nudge to review. thanks! |
There was a problem hiding this comment.
LGTM
Thank you for working on this improvement!
For the record, this also directly affects (and fixes) b/509600495, as the issue stems from those huge builds causing Windows jobs to terminate prematurely due to lack of space.
Adds support for
fuzz_targetsproperty inclusterfuzz_manifest.json. This allows coverage-guided fuzzing jobs withChromeBuildArchives to skip the unpacking and fuzz target discovery phases.Problem:
Currently, ClusterFuzz wastes time unpacking complete archives to then traverse the directory to discover fuzz targets. Furthermore, on certain large build types, this unpacking process frequently triggers out-of-disk-space errors due to the massive size of the zip files.
Solution:
By introducing
fuzz_targets— a list of fuzz target paths relative toclusterfuzz_manifest.json— we can bypass the discovery step entirely. ClusterFuzz will now map this list so that each fuzz target has a normalized name (key) and its corresponding path (value).More Info: crbug.com/508214240