Don't upload unstable builds.

[oliverchang]

We shouldn't upload builds if it's detected to be unstable.

[inferno-chromium]

If we do this, we will avoid fires like https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=%22Attempting+free%22&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids. On internal clusterfuzz, we had this notion of bad build. But for libfuzzer it didn't work, so either we rely on jenkins to not upload such build (and they are bad anyway) or need to add some bad build detection clusterfuzz side.

[inferno-chromium]

If we enable this now, we will stop uploading builds for libreoffice, gnutls. Or basically any project which has a ton of fuzzers and atleast one fuzzer is crashing (commonly with like leaks, etc).

Maybe we should mark unstable if all of the fuzzers are broken and only then don't upload. Thoughts. @kcc ?

[kcc]

Can we do this per-target, not per project?

[inferno-chromium]

@kcc - we create one build archive for the whole project, so either we build all targets or none.

[mikea]

Couple thoughts:

• in the lld case builds were stable (i.e. fuzzers didn't crash on jenkins). It wouldn't have helped.

• we specifically upload unstable fuzzers so that CF files and verifies bugs.

[inferno-chromium]

This is heavily needed see also #232 (comment).

[inferno-chromium]

We need to think more on this. Some day we can break all project with a bad llvm change.

[oliverchang]

This (using fuzzer crashes to determine llvm breakage) might be hard. The last time this broke (lld change), I think we only saw this for certain fuzzers that hit the required code paths.

The right place to find out bad llvm changes might be when we build base-images. Maybe we should run libFuzzer tests there (assuming they're comprehensive enough to catch issues in llvm).

[inferno-chromium]

Right, if we can run basic llvm tests on base-images builder, that should be good enough.

[oliverchang]

Closing in favour of #526