Well, looks like a ninja issue to me at least according to these lines: 

Failing build because ninja reported work to do.
This means that after completing a compile, another was run and
it resulted in still having work to do (that is, a no-op build
wasn't a no-op). Consult the first "ninja explain:" line for a
likely culprit.

As trooper I don't have much insight in that. +thakis who may have an idea.

"ninja explain: expected depfile 'boringssl_cert_fuzzer.seed_corpus.d' to mention 'boringssl_cert_fuzzer.options', got 'boringssl_cert_fuzzer_seed_corpus.zip'"

Looks like testing/libfuzzer/fuzzer_test.gni / testing/libfuzzer/archive_corpus.py is getting confused by the new parameter you're adding.

...I would've cc'd mmoroz who reviewed https://codereview.chromium.org/1768743002 but you filed this bug (?)

Triggered a CQ dry run on https://codereview.chromium.org/1885493002 to see whether the issue is flaky or not.

I'm 92% sure this is a real bug, not a flake.

Thanks thakis@ for pointing this out.

I'm feeling stupid, but I cannot neither find this error message nor reproduce the issue.

aizatsky@, do you understand what's going on?

Reproducing it should be easy.

Do clean, then:

$ ninja all
$ ninja all -v

If it does anything on the second step instead of saying "up-to-date" - you have reproduced it.

estaab: this isn't a trooper issue, this is a bug in testing/libfuzzer/archive_corpus.py.

(relabeling, making public)

Ok, thanks for clarifying.

To be honest, I'm still not able to reproduce.

$ ninja all
gives me huge amount of other errors like "undefined reference to %some STL classes%".

Current version of BUILD.gn file has been changed, I did rebase and clicked Dry run.

Problem has been solved. Thanks everyone.

what was the fix?

We removed depfile from build target since it seems not too important for our regular usage.