Absolute source entries within workspace should not require an approval

theKBro commented 1 year ago

Jenkins and plugins versions report

Environment

```text Jenkins: 2.387.2 OS: Linux - 4.18.0-425.19.2.el8_7.x86_64 Java: 11.0.19 - Red Hat, Inc. (OpenJDK 64-Bit Server VM) --- cobertura:1.17 code-coverage-api:4.2.0 ```

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

agent is running windows

Reproduction steps

cobertura coverage result file contains absolute paths to source directories within the projects workspace e.g. workspace is: C:\J\workspace\ProjectName\ws

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<coverage branch-rate="NaN" branches-covered="NaN" branches-valid="NaN" complexity="NaN" line-rate="0.78624" lines-covered="320" lines-valid="407" timestamp="1684225798.4794" version="">
  <sources>
    <source>C:\J\workspace\ProjectName\ws\src\</source>
  </sources>
  <packages>
   ...

Expected Results

should be handeld just like a relative path inside of the workspace e.g.

<source>src\</source>

and no error should be reported

Actual Results

an error is reported

[Cobertura] Successfully processed file 'code-coverage\coverage.xml'
[Coverage] [-ERROR-] Errors while resolving source files on agent:
[Coverage] [-ERROR-] Removing source directory 'C:/J/workspace/ProjectName/ws/src' - it has not been approved in Jenkins' global configuration.
[Coverage] [-ERROR-] - Source file 'subdir/srcFileName.ext' not found

Anything else?

I run into this problem multiple times now with different tools generating cobertura coverage results.

uhafner commented 1 year ago

It seems that I forgot at one place to normalize the path names to the same format (Windows, Unix).

As a workaround you can add the source folder src for now.

theKBro commented 1 year ago

As far as I remember I also tried it with forward slashes instead of backslashes without success.

jenkinsci / code-coverage-api-plugin