Enhance `nogo` to provide warnings and export diagnostics

[moisesvega]

Description

Currently, nogo in rules_go does not provide warnings or export complete diagnostics per analyzer. This makes it difficult to collect meaningful insights and enforce best practices without failing the build.

Problem

• nogo strictly fails on errors, which prevents collecting non-blocking diagnostics.
• There is no built-in way to aggregate and export detailed diagnostics per analyzer.
• Developers lack visibility into potential issues without breaking the build process.

Proposed Idea

Instead of failing immediately, we could introduce a mechanism to:

1. Swallow Errors: Allow nogo to collect and log issues instead of immediately failing.
2. Collect Metrics: Aggregate diagnostics from all analyzers and export them in a structured format.
3. Configurable Behavior: Allow warnings vs. errors to be configurable per analyzer.

Questions for Discussion

• Would it make sense to introduce a warning mode in nogo?
• Should this be built into rules_go, or would an external tool be better suited for post-processing?

[fmeum]

Have you tried running a build with --keep_going? That gives you all findings without failing the build immediately. Given how often warnings end up being ignored and just add to log spam, I would prefer not to add an explicit mode for this.

Structured output could be toggled via a flag or output group, which would be quite unintrusive. What kind of output are you looking for?

[moisesvega]

Have you tried running a build with --keep_going?

Yes, I usually do that. The challenge with a large codebase is that I want to start blocking only new instances of the X analyzer rather than fixing everything at once, allowing for a gradual transition to a blocking state. This particular feature could potentially be implemented through other systems rather than rules_go, as it would require access to the repository's previous state.

What kind of output are you looking for?

I believe I proposed a structure a while back in #3388. However, if we're open to making it a part of nogo itself, I can create a formal proposal.

[linzhp]

#3388 was to export the suggested fixes, which is already done in #4102. So I guess the remaining information you need is analyzer name, location of violation and message?

[moisesvega]

I guess the remaining information you need is analyzer name, location of violation and message?

Correct, now this only makes sense if it doesn’t block the build. #4102 already covers blocking linters, and I believe this is enough for most blocking linters. The real reason to expose diagnostic information is for post-build actions like collecting metrics and blocking new instances of issues in the same package, which would need rules_go to provide this info after the build without blocking the build.