There should be a way to turn fuzz-introspector off

[evverx]

As far as I understand fuzz-introspector is a work in progress and build failures aren't reported on Monorail and badges don't turn yellow/red so it doesn't affect projects where it isn't supported or actively maintained. Once it's rolled out globally I think it should be possible to turn it off because I think kludges like #7583 (comment) aren't exactly robust and it isn't clear how long it will take to fix them when they stop working suddenly.

[jonathanmetzman]

Agreed. @Navidem @oliverchang WDYT?

IMO fuzz introspector is qualitatively different from fuzzing and maybe even coverage. In a somewhat ideal, but not perfect world OSS-Fuzz shouldn't bother users about it unless they opt-in (the perfect scenario is opt-out but nothing ever breaks :-)

[Navidem]

Thanks @evverx for pointing this out.
Currently the introspector builds use separate images so changes like those mentioned in #7583 should not affect fuzzing or coverage builds at all. That said, I agree we can provide options to opt-out the project.

[evverx]

I think it would be better to opt-in. As far as I understand for example due to separate images it's difficult to integrate it into the OSS-Fuzz CI so when projects are integrated they can't be sure whether they are buildable with fuzz-introspector or not. I suspect it's also hard to test it locally or on GitHub using GHActions like CIFuzz so any change can break it. Though I agree as long as it doesn't affect anything it should be turned on by default to make it easier to test it.

[oliverchang]

We don't plan to turn on automated build notifications or change badge colours for fuzz introspector builds for the time being. Longer term we need to figure out a solution to minimise environment differences, but having the automatic builds is desirable for testing.

[oliverchang]

Closing since it seems there are no further objections to this?

[evverx]

I still think it should be possible to turn it off somehow eventually using project.yaml but systemd/systemd@ebd4541 should suffice for the time being probably.