Bugzilla

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #24)

> Alternatively if we can find the changes that are most likely to trigger this to break (i.e. certain toolchains, specific build files changed, etc.) we could build the fuzzing builds then via a SCHEDULES rule (like we do for jsreftests/jittests).  Maybe :decoder has a list of conditions and we could start there.

Unfortunately this is really tricky. First of all, any code change within `#ifdef FUZZING` can cause build failures and this code can appear virtually everywhere in the codebase. Sometimes, this guard is in C/C++ code, sometimes it is in `moz.build` files. Reliably identifying this is probably going to be hard on its own.

In addition any toolchain change (esp. compiler and linker upgrades) can break the fuzzing builds. The same holds for changes in the build system itself (order of linking libraries or how things are linked together in general). So overall, this would be pretty hard to identify, definitely not possible with a simple file list.

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #24)

> Alternatively if we can find the changes that are most likely to trigger this to break (i.e. certain toolchains, specific build files changed, etc.) we could build the fuzzing builds then via a SCHEDULES rule (like we do for jsreftests/jittests).  Maybe :decoder has a list of conditions and we could start there.

Unfortunately this is really tricky. First of all, any code change within `#ifdef FUZZING` can cause build failures and this code can appear virtually everywhere in the codebase. Sometimes, this guard is in C/C++ code, sometimes it is in `moz.build` files. Reliably identifying this is probably going to be hard on its own.

In addition any toolchain change (esp. compiler and linker upgrades) can break the fuzzing builds. The same holds for changes in the build system itself (order of linking libraries or how things are linked together in general). So overall, this would be pretty hard to identify, definitely not possible with a simple file list.

Edit: Oh and I forgot to mention: Fuzzing builds can also break when APIs are changed that are used in compiled targets. You might not see these in your statistics as fixed by a commit because people do try runs and might have included this build type in their run already (and made the change).