Coverage on New Code presumably wrong due to offset by 1 for covered lines

[joha (Jochen Handels)]

Versions used:

• Sonarqube: 8.5.1.38104 (Developer Edition)
  • jacoco Plugin: 1.1.0.898
• JDK + Maven: Docker image maven:3-jdk-8
  • org.sonarsource.scanner.maven:sonar-maven-plugin 3.7.0.1746
  • org.jacoco:jacoco-maven-plugin 0.8.5

Context:

• Coverage import from JaCoCo during Analysis of Java Projects based on Maven
• Execution environment: GitLab CI/CD

Observations:

• The positions of covered lines in the code view are offet by 1 in comparison with the report provided by JaCoCo (observation based on the HTML page provided, not on the XML)
• Computation of Coverage on New Code is therefore presumably wrong, since lines for New Code are correctly determined

Steps to reproduce:

• Assumption: Maven Project using the JaCoCo and Sonar-Scanner Plugins is available

1. Verify Maven Project and safe the generated HTML report for comparison

   mvn verify
   

2. Perform SonarQube analysis

   mvn -Dsonar.qualitygate.wait=true sonar:sonar
   

3. Compare presentation of covered lines in JaCoCo HTML report and the code view in SonarQube

[Antoine]

Hello @joha,

So it appears everything is fine to generate JaCoCo reports, but once loaded in SQ every files are offset by one line, so then JaCoCo info does not match anymore? Interesting!

It doesn’t make sense to reproduce the steps you mentioned as most projects will be ok, I mean this usually works! The issue is likely related to something specific in your context:

• are you sure about files encoding? I’m referring to the source code here, not the report
• is there one or several weird characters somewhere in each of your files that could mess with how the file is read?
• are issues reported on the right line or are they also suffering from this problem?

Cheers

[joha (Jochen Handels)]

Hello @Antoine,

Thank you for your response and sorry for the late reaction from my behalf!

I actually shared your ipmression when I created this discussion and I was more or less “hoping” this could be an actual bug and some reaction of other users would be provoked in this case to reveal the bug. But it really seems to have been a thing in our local setup.

Around the time when I created this discussion this was a reproducible behaviour concerning a particuar GitLab Merge Request. Things have changed, however. The behavior is now as expected with our latest and unfortunatelly we haven’t actively observed the change in our code base which may be accountable for this. The attempt to back track was not possible anymore, because house keeping has done its job.

So maybe this was just a temporary hiccup which doesn’t affect any body else out there. Thank you non the less for taking notice and investing some thoughts!