Stored source code files should use a unique path #657
Comments
|
Upon further investigation, this was actually the result of the pattern ( |
|
I'm actually going to reopen this, after additional investigation. There had indeed been an unwanted duplication of a file, which the My best guess is that this is occurring because both coverage reports contain some of the same filenames, e.g., |
|
I'm happy to supply more information, including redacted samples of the actual XML files, but don't know what would be the most useful. |
|
When there are multiple files specified for one coverage step, then the results of those files are merged. If these files use different module names, then a new tree node will be created, that contains all the modules. But if the modules have the same name, then they are merged using a file by file operation. It looks that in your case the results of different files that use the same unique ID (relative path) are merged which will cause this error. Workarounds for your XML reports:
|
|
Yes, my intent had been to have one In this context, what do you mean by "module"? That is not a label in the Cobertura XML reports, which use terms like "package", "class", "method", and "line". I'm open to different module names if it's something I can easily control. |
|
You are right, it seems that Cobertura does not provide a name for a report in its DTD. So currently I am using "-" as name for each report (and this produces a name clash if there are the same packages present). Maybe it makes more sense to use the actual report XML file name as module name. When I change that, then the exception should not be thrown anymore. However, the UI will be still not capable of showing the results per module. Currently, the UI collects the results of all reports into a single model. In your case this means that the results of different files with the same package and file name will be shown in a single page. I'm not sure what would be the best way to change that for the users. We discussed that in #236 and finally came to the solution, that in such cases the best way would be to use multiple steps. If these results are recorded in a single step we need a UI concept to select the modules. |
|
Yes, my top-level package name in this case is |
|
Which tool or languages are you using to create the reports? I think it would be helpful if all users would get better package or directory names out of the box. I'm using a package detector in my warnings plugin to identify packages for tools and languages that do not support them natively. Maybe we can use something similar for your tool/language chain. I'm not familiar with typescript and react but I would assume that they have a similar concept of modules, packages, and classes? |
|
We're running Jest via npm. This issue seems to be a similar one; in that case one of the solutions was to modify the report files via PowerShell so that the package name attributes used the folder structure, which would allow for disambiguation (in case of collisions) and better visualization regardless. |
|
We've resolved this for now like this: This is run immediately after the coverage reports are generated, and prior to any use of |
|
I see, thanks for sharing! Can those module names somehow be derived from your workspace? For Maven, Gradle, OSGi I have scanners that detect those modules automatically. Maybe I can add another one for typescript (or NPM?) projects. |
|
There are a few possibilities I can think of:
What isn't obvious is the way you would determine a simple module name (e.g., ModuleA or ModuleB) from these paths, given the things that could differ (workspace path, coverage directory). But there is at least a reliable way to see that these reports pertain to different paths, so any files within that happen to have the same names (e.g., Routes.tsx) should not be treated as if they were the same file. |
|
Following up on my ModuleA: ModuleB: These are now underneath different I imagine this is because it searched for a matching file twice (since it appears twice, across these two reports) but found the same one each time. That might not be solvable with a single invocation of |
|
This also breaks for python projects when combining coverage reports produced by test runs using different python versions - a common scenario. The workaround is to combine coverage databases beforehand instead of relying on this plugin to combine reports. [testenv]
setenv =
py{38,39}: COVERAGE_FILE = .coverage.{envname}
[testenv:report]
skip_install = true
deps = coverage
commands =
coverage combine # reads .coverage.*, outputs .coverage
coverage xml # reads .coverage, outputs coverage.xmlEDIT: but note you'll have to handle path remapping between nodes yourself. # .coveragerc
[paths]
source =
src/
*/site-packages/
*/src/ |
You are referring to the exception, aren't you? For this exception please also see #729. |
uhafner
changed the title
When multiple coverage files are merged, then the covered files might have the same name (and relative path) but use a different absolute path. The plugin currently has no way to choose the correct file.
Original issue:
Jenkins and plugins versions report
Jenkins 2.387.2
Plugins
What Operating System are you using (both controller, and any agents involved in the problem)?
Amazon Linux 2
Reproduction steps
Switched deprecated method like this:
to what I expected to be its equivalent:
Expected Results
Expected absolute line-level coverage (89%) to be reported.
Actual Results
Got an error stating this:
Anything else?
The build generates 10 different Cobertura report files that are then combined in a single publishCoverage step (which I'm aiming to replace with reportCoverage). None of the Line coverages are 100%; the only 100% coverages are for Module (by definition, I expect), and in a few cases, Package.
The text was updated successfully, but these errors were encountered: