I have a large java-based project, hosted on GitLab, that is built through Jenkins using ant. The jenkins machine is a windows box, and has a SonarQube scanner installed. As part of the build process the jenkins machine scans the code, and communicates with a separate SonarQube server, which is a linux box.
Currently our git repo has only windows-based line endings, since it was converted from svn. Under this configuration SonarQube can detect new issues in a code submission, but fails to detect the line numbers of the new issues. In GitLab, it attaches a general comment to the merge request, instead of making a regular in-line comment.
I ran the SonarQube analysis with extra logging and found that it was failing a string comparison between the line with the problem it detected, and an array of lines representing the rest of the file.
In particular, it looked like the string it was searching for, had a new line at the start of the string, whereas the strings in the array, had a new line at the end of the string.
On a hunch I switched all line endings in a test-branch to be unix-style line endings, and made the windows box use auto-crlf. This fixed the problem, SonarQube was able to match the strings and gave an in-line comment for the issue it detected in the GitLab merge request.
Since changing every line of every file to force Unix line endings is a bit more invasive then we would like, I'm wondering if there's some configuration option I might be missing that would allow SonarQube to recognize windows style line endings, even when running on a linux machine?
Turns out this was a known issue with the GitLab plugin, and not the SonarQube server. The issue has been fixed in the latest code base, but is not part of the current stable release.
Details here: https://github.com/gabrie-allaigre/sonar-gitlab-plugin/issues/35