Static Code Analysis and Quality Gates

[philliplbryant]

@Col-E, how do you feel about modifying the GitHub workflows to include static code analysis?

For background, I added analysis steps for SonarQube Cloud, Qodana, and CodeQL in the persistence fork, and they've been very helpful in pointing out potential bugs, potential NPEs, gaps in test coverage, etc. I've already fixed the issues discovered in the persistence modules, but there are still issues in the core module. Analysis in the fork is configured to ignore the core and demos/basic modules, so porting the configuration shouldn't break anything. Those modules can be included as findings in them are resolved. I'd be happy to open issues for them and implement most as separate PRs.

Adopting the changes would require creating a SonarQube Cloud account and generating an access token. Codecov and Qodana Cloud accounts would be needed as well, each with its own token. So we'd likely want to coordinate closely to avoid downtime. I don't want to "move any cheese," but I'm willing to port them over if it's something you actually want. Let me know if you're interested.

[Col-E]

I already have a Codecov account for coverage reporting on Recaf. Adding a badge for coverage amount is an easy add 👍

I think there's no real strong reason for SonarQube if the same effect can be achieved by passing a recent frontier model over local changes and asking it to do a review (Maybe multiple passes dedicated to categories of issues)

[philliplbryant]

My experience using Claude/Opus 5 for reviews, which has been echoed by others on our team, is that it finds something every time it's run and it's different when run back to back. I've had similar results with Codex and GPT-5.6 Sol. And both missed vulnerabilities reported by Sonar and Qodana. It's a cheap addition and easy to remove if it gets in the way. Your call.

[philliplbryant]

@Col-E, this is the other half of enhancement/BENTO-35-update. It lives on enhancement/issue-43, branched off it so the diff is analysis config only: CodeQL, Qodana, SonarQube Cloud, Codecov, and a Dependabot config.

Same caveat as on #13: I'm not trying to change your workflow. What this adds is repeatable checks that find things a model pass over a diff doesn't: the same SonarQube findings every run, dataflow across files, published dependency advisories, and whether coverage just went down.

Nothing in it asks you to write tests, and nothing fails on the existing backlog. If you're interested, I can provide additional details as to why I think it's better than running models against code and what you'd need to do to start using it, which comes down to a few access tokens and a couple of one-time settings.

On the other hand, if you don't want it, say the word, close the issue as won't do, and I won't mention it again. I can keep using it in my fork and resolve merge conflicts as I apply your updates.

No worries either way.

Thanks