Nick Jones

If you define 9 lockable resources (e.g., "resource1", "resource2", etc.) in the global configuration (Manage Jenkins), and give them all the same label (e.g., "resourcePool"), you should be able to...

Upon further investigation, this was actually the result of the pattern (`**/*cobertura*.xml`) matching two copies of the same file -- we use ReportGenerator to merge separate reports, and had overlooked...

I'm actually going to reopen this, after additional investigation. There had indeed been an unwanted duplication of a file, which the `**/*cobertura*.xml` pattern was finding, but after eliminating that duplicate,...

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.

Yes, my intent had been to have one `recordCoverage` step that consumes data from a set of different Cobertura XML files, just as I previously had one `publishCoverage` step (now...

Yes, my top-level package name in this case is `src` -- reflecting the "src" folder that exists under each of the two projects that are experiencing this phenomenon. I will...

We're running Jest via npm. [This issue](https://github.com/nrwl/nx/issues/14021) seems to be a similar one; in that case one of the solutions was to modify the report files via PowerShell so that...

We've resolved this for now like this: ``` sed -e 's/package name="src/package name="MyModuleName/g' -i coverage/cobertura-coverage.xml ``` This is run immediately after the coverage reports are generated, and prior to any...

There are a few possibilities I can think of: - The `cobertura_coverage.xml` files have `` elements with different absolute paths, e.g., `/JenkinsWorkspaceRoot/ModuleA/client` and `/JenkinsWorkspaceRoot/ModuleB/client`. Even though both files have a...

Following up on my `sed` approach above; this is sufficient to avoid the exception described at the start of this issue, as the package names themselves in the files are...