4

A common problem we have at work is people committing code without having noticed that they're increasing the number of compiler warnings.

The ultimate goal is to make warnings errors, but until the count gets to zero, there's no clean way to do it.

We use Bitbucket for the pull request process, so it seems like that would be a fairly sensible place to display the warnings.

We use Jenkins for the build, and it already has a plugin which shows the compiler warnings in a report, but it isn't very visible when doing the PR.

I am also sitting on a Gradle plugin which can generate compiler warning reports without having to go to the build server, in case that will be of any use here.

Is there an integration where we can get the compiler warnings to show up on the Bitbucket PR?

(Note that SonarQube is not a valid answer to this question, as what it detects is a different subset of problems to what the compiler itself detects.)

6
  • I'll just drop a reference to the violation-comments-to-stash plugin here which I have never used myself, in the hopes that an answer to this question will note whether it is helpful for the described use case.
    – anx
    Oct 29, 2022 at 15:35
  • @anx that particular one seems to be the option if you happen to use findbugs, which is an additional layer of checking on top of compilation. In our case, we're using errorprone, which produces normal compiler warnings. I know that some amount of tooling could be used to produce a findbugs report from the compiler output, but that is, of course, work.
    – Hakanai
    Oct 30, 2022 at 6:32
  • 1
    You could do an approximation of the number of warnings with the number of lines of output from the build. Output the build console to a file, get the number of lines in that file, save that number to another file, and check that file in. (This would make for a pretty dirty history, every CI build would have an extra commit.) Then on next build you can compare numbers and see if it goes up. Dec 2, 2022 at 20:53
  • 1
    @DeniseSkidmore it'd be messy because you'd have to do that to all the PR branches as well, but it has one plus that it would automatically track branching. I think the real goal though is to get a big number in front of the reviewers' faces during a PR, though. If it's just knowing whether the number is going up, we can get that from the Jenkins Warnings Plugin (Next Generation).
    – Hakanai
    Dec 4, 2022 at 21:33
  • @Hakanai Yes, the ugliness of the "solution" is why I didn't make it an answer. Dec 5, 2022 at 1:45

0

You must log in to answer this question.

Browse other questions tagged .