Unable to find bundle named Xcresultparser_XcresultparserLib #32

Closed MatthewTHFisher closed 3 months ago

Hey!

Around 2-4pm BST Thur 13th June, I started to consistently get an issue on my build servers where xcresultparser is called. The issue simply says that the bundle named Xcresultparser_XcresultparserLib cannot be found. We've made no updates to pipelines or CI runners, just seems to have happened out of the blue.

CI output of a GitLab job that calls xcresultparser

$ xcresultparser -o cobertura --quiet --project-root "$CI_PROJECT_PATH/" "build_report.xcresult" > "cobertura.xml"
XcresultparserLib/resource_bundle_accessor.swift:44: Fatal error: unable to find bundle named Xcresultparser_XcresultparserLib
bash: line 284: 87547 Trace/BPT trap: 5       xcresultparser -o cobertura --quiet --project-root "$CI_PROJECT_PATH/" "build_report.xcresult" > "cobertura.xml"

Unfortunately I don't have any ideas what could have caused this, any help/ideas would be appreciated!

Note: Thanks for rolling out 1.6.0 we've been using it for 2 weeks without any issues

Update

The issue is reproducible on my Macs terminal, using the following command xcresultparser -o cobertura "build_report.xcresult"

After trying it with all the output types, only one type causes the above failure and that is cobertura

This is likely the same as #21. We were never able to nail down a root cause though, and it eventually just started working again. 🫤

If it's realistic for you, building from source does work around the problem.

swift build --configuration release --disable-sandbox --arch arm64 --arch x86_64

We started having the same issue today. I will try to build from source.

Oh, I will look into the issue and see, whether I can reproduce it and then come back to you later.

What happened is that the cobertura URL for the dad changed. It used to be: "http://cobertura.sourceforge.net/xml/coverage-04.dtd". Now there is a 404. The xcresultparser tool now falls back to the file which is "built-in" with

Bundle.module.url(forResource: "coverage-04", withExtension: "dtd")

Bundle.module however fails in this situation. (because of the app being sandboxed?). I will investigate that further and release a new version with a.) corrected did url and b.) a fix for Bundle.module

Great find! Frustrating that the URL would break like that. Looks like they also host it on GitHub. Maybe that'd be more stable? https://github.com/cobertura/cobertura/tree/master/cobertura/src/site/htdocs/xml

To b.) The command line tool is not a bundle and so obviously Bunlde.module must fail... I will instead bake the dad into the code instead of using an external file.

As for the URL. I am wondering, whether we really need to get that data online. Will the dtd really change at all? It seems to be versioned. I wonder, whether any changes will not anyway go into a coverage-05.dtd, instead of changing coverage-04.dtd?

Is it worth in the first place to spend time downloading this dtd?

I will bake it into the app and not fetch it from online anymore. Seems to be over engineered. What do you guys think?

Yeah I think just baking it in seems reasonable. Looking at the git history of the file, its last update was 10 years ago. Safe to say it's not changing.

@a7ex Seems reasonable. Relying on an online resource not under your control is fragility just waiting to break again.

Should be fixed in version 1.6.2. I will close this issue now

@a7ex Is there a delay before Homebrew sees the change or some way to force that?

nvm :) brew install a7ex/formulae/xcresultparser forced the update. brew outdated, etc. wasn't picking up the change.

After updating to 1.6.2 I started seen this error: Missing package product 'SwiftLintBuildToolPlugin@11'

This seems unrelated with the change. Any idea how to fix this?

@aaadonai Just opened this issue for that. https://github.com/a7ex/xcresultparser/issues/33

Thank-you @a7ex for the super speedy fix on this issue! Will check it out ASAP!

a7ex / xcresultparser

Unable to find bundle named Xcresultparser_XcresultparserLib #32