jenkinsci / code-coverage-api-plugin

Deprecated Jenkins Code Coverage Plugin
https://plugins.jenkins.io/code-coverage-api/
MIT License
111 stars 77 forks source link

Coverage reports are not merged line by line #729

Closed Kirdock closed 11 months ago

Kirdock commented 1 year ago

Jenkins and plugins versions report

Jenkins: 2.401.2 code-coverage-api: 4.7.0 git-forensics: 2.0.0

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux

Reproduction steps

Folder structure /app /shared

  1. Each folder has its own coverage report
  2. /app accesses a function in /shared, which is also tested in /shared. app should not test the whole function in shared, and shared should test more of the function than app.
  3. In the code coverage interface you will recognize that only the tested lines/branches of app are taken. app executed before shared
  4. Try changing the coverage report name, so that shared is taken before app
  5. Now You will recognize that the code coverage changed (not in terms of the calculated one but inside the changes for some reason) shared executed before app
  6. Move the function from app to shared (and the shared report is taken before the app one)
  7. Now you will see the correct coverage of shared method moved to shared

Expected Results

Not only the coverages should be merged, but also the files/functions. If a file/function is present in two coverage reports, the function coverage should be merged

Actual Results

One report overrides the coverage of a function of another one

Anything else?

Coverage report of app and shared while dateUtils.ts is inside app

app ```xml ${MY_DIRECTORY_PLACEHOLDER} ```
shared ```xml ${MY_DIRECTORY_PLACEHOLDER} ```

Coverage report of app and shared while dateUtils.ts is inside shared

app ```xml ${MY_DIRECTORY_PLACEHOLDER} ```
shared ```xml ${MY_DIRECTORY_PLACEHOLDER} ```
uhafner commented 11 months ago

After thinking about the current implementation of the merge I must admit, that I don't know if such a merging generally can be done in my post processing step. I do not have enough information in the XML files to compute the coverage in the same way as a coverage tool can do.

Maybe if makes sense to cut of the coverage information at the file level and aggregate all values in the parent levels (packages, modules) on my own. I even do not show the coverages at method or class level yet.