Coverage build is failing because of a new fuzz target

[evverx]

It seems to be a variation on #3902. The only difference is that apart from a new fuzz target, the project itself has just been added.

https://oss-fuzz-build-logs.storage.googleapis.com/log-d8f28a49-e95e-47f7-a43b-ee20a59c3eee.txt

Step #5: Already have image (with digest): gcr.io/oss-fuzz-base/base-runner
Step #5: unzip:  cannot find or open /corpus/*.zip, /corpus/*.zip.zip or /corpus/*.zip.ZIP.
Step #5: 
Step #5: No zipfiles found.
Step #5: Failed to unpack the corpus for *. This usually means that corpus backup for a particular fuzz target does not exist. If a fuzz target was added in the last 24 hours, please wait one more day. Otherwise, something is wrong with the fuzz target or the infrastructure, and corpus pruning task does not finish successfully.
Step #5: ********************************************************************************
Step #5: Code coverage report generation failed.

[Dor1s]

Looks like the build has failed only once and it didn't raise a build failure issue in the bug tracker

#5 Jun 29, 2020 6:19 AM
#4 Jun 28, 2020 6:18 AM
#3 Jun 27, 2020 6:20 AM
failure: #2 Jun 26, 2020 6:23 AM
#1 Jun 25, 2020 3:39 PM

which is WAI, as you noted new projects / fuzz targets are creating such circumstances under certain timing conditions.

[evverx]

it didn't raise a build failure issue in the bug tracker

As I mentioned in #3902 Monorail isn't the only place where the status of coverage builds is visible. If failures like that are expected I don't think it should fail.

as you noted new projects / fuzz targets are creating such circumstances under certain timing conditions

As you might have noticed #3902 was fixed in #3903 so I think to be consistent it would probably make sense to fix this edge case.

[Dor1s]

Sorry, I was out for two months and haven't followed changes too closely during that time.

The problem here is that we can't distinguish between a new fuzz target and a broken fuzz target that doesn't have a corpus backup available for some other reason. Technically, we can engineer it, but it's not worth the effort.

The real solution would be to make the badge follow the build status logic employed by the infrastructure, because in addition to cases like this there are other flaky failures happening from time to time.

Frankly I didn't remember that status for the badges is being determined differently. I'll double check it and file another issue if that's the case.

As for #3903, I'd rather revert it for pretty much the same reason. Temporary false positives are better than permanent false negatives.