OSS-Fuzz doesn't work with bzlmod

[tpudlik]

Expected Behavior

After migrating to bzlmod, OSS-Fuzz continues to work for my project.

Actual Behavior

I get the following error, full log:

no such package '@@[unknown repo 'rules_fuzzing_oss_fuzz' requested from @@]//': The repository '@@[unknown repo 'rules_fuzzing_oss_fuzz' requested from @@]' could not be resolved: No repository visible as '@rules_fuzzing_oss_fuzz' from main repository

This arises because bazel_build_fuzz_tests in OSSFuzz checks out my project, and then attempts to build it with bazel flags like,

--@rules_fuzzing//fuzzing:cc_engine=@rules_fuzzing_oss_fuzz//:oss_fuzz_engine

However, the name @rules_fuzzing_oss_fuzz is not exposed by my repository: this is a transitive non-module-dependency of rules_fuzzing.

In general, it seems like users of rules_fuzzing need to be able to refer to these "non-module dependencies" (to set flags like --@rules_fuzzing//fuzzing:cc_engine), so they should be exposed.

Workaround

Indeed, we can get OSSFuzz to work again by adding to our MODULE.bazel,

non_module_dependencies = use_extension("@rules_fuzzing//fuzzing/private:extensions.bzl", "non_module_dependencies")
use_repo(
    non_module_dependencies,
    "rules_fuzzing_oss_fuzz",
)

But this can't be the intended interface (since the module extension is private). Should it be public instead? Or are we holding it wrong and we should expose this name in some other manner?

cc @fmeum (who added bzlmod support in #242) @nopsledder (who reported this issue internally)

Specifications

• Version: 0.5.2
• Platform: Linux

[tpudlik]

The workaround is not very satisfactory because it requires us to add direct deps on Abseil and fuzztest (http://pwrev.dev/238471) even though these are in fact transitive deps required by rules_fuzzing_oss_fuzz.

[fmeum]

I sent #258 to give Bzlmod users a way to reference this engine without reaching into internal extensions.

We would need to update the OSS-Fuzz build scripts in lockstep or perform some kind of feature detection - not sure what's the best way to do this. As a workaround, you should be able to specify the new targets via extra build flags.