Fuzzing workflow is not friendly to rebuild and incremental changes.

[ericstj]

I noticed that the fuzzing workflow runs as a self-contained app, which means that it requires a full repo build and will have incremental build challenges since self-contained apps rely on restoring nuget packages.

I see that as a result of this, the fuzzing infrastructure defines it's own NuGet.config with a local packages cache and pointers to the output packages. That means any time someone rebuilds they need to delete that cache and rebuild the entire repo to produce those packages.

Can you make it a framework dependent app instead, similar to how all our regular tests work, and use the test shared framework?

That's optimized for local builds and incremental changes - rebuilding libraries will update the test sharedframework without any extra steps.

@MihaZupan

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[julealgon]

...the fuzzing workflow...

@ericstj could you please clarify what exactly do you mean by this "fuzzing workflow"? I've not heard that term before so I'm honestly curious now. I have no idea what mechanism you are talking about here.

Is it some internal thing only used inside of this runtime repo?

[ericstj]

These steps: https://github.com/dotnet/runtime/blob/main/src/libraries/Fuzzing/README.md

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.