Excessive "did not find extension point…" output slows script execution time

[StephenDowns]

As reported by many users in issue #63, execution time of the script is extremely slow when run using the .xcresult bundle format introduced in Xcode 11. Each time any xccov command is run, there is a delay followed by the following output:

Requested but did not find extension point with identifier Xcode.IDEFoundation.IDEResultKitSerializationConverter

[qw1024]

Having exact the same issue on our CI env, takes ~ 8min to generate the report and tons of error output like this.

[akoller-vs]

I was having the same issue upon upgrading our project to Xcode 11.0. I was unable to determine the cause of this error, but was able to figure out a workaround that works for us.

Leveraging xcparse, you can convert the Xcode 11 .xcresult bundles back to the Xcode 10 format. You can then run xccov-to-sonarqube-generic.sh as normal on those output .xccovarchive directories to get the old performance.

$ xcparse codecov Build/Logs/Test/MyApp.xcresult
$ xccov-to-sonarqube-generic.sh Build/Logs/Test/action.xccovarchive/ > sonarqube-generic-coverage.xml

Our project can produce multiple .xcresult outputs in 1 run, so you may have to loop and rename the output action.xccovarchive directory as I don't see any option to change that.

I did also look into merging .xcresult bundles using xcresulttool merge to avoid the loop and rename problem, but I found that the resulting action.xccovarchive produced from the merged .xcresult bundle only reports the coverage from just one of the .xcresult bundle parameters. The merged bundle looks fine when inspected with xcresulttool, so I believe it may be a problem with xcparse working with merged .xcresult bundles

[wtimme]

Thanks a lot, @akoller-vs! For us, in first tests, utilizing xcparse brought down the build time from 20 minutes to 12 minutes. 👍🏼

[radutacatalin]

If you need to save some time, there's this tool that speeds up the process from 25 to 4 minutes for us. 🚀

[inforeqd512]

Thanks so much, @akoller-vs. This solution has reduced the build time considerably. As a further step, we're also looking at optimising the script by excluding all file and folder patterns that we provide in the sonar exclusions. We'll inform if this has significant benefits. 👍🏼

[softreigns]

My solution to this warning and slowness. I developed this xslt to get the generic report from cobertura xml, instead of using the xcov and xccov-to-sonarqube-generic.sh

https://github.com/softreigns/coverage-report-cobertura-to-sonar-generic

[silverhammermba]

There's no need for additional tools. It's pretty easy to script the process. First run

xcrun xcresulttool get --format json --path Foobar.xcresult

That gives you all the test information in a big JSON dump. You can parse that and then grab the xccovarchive ID with this keypath:

xcresultObject['actions']['_values'][0]['actionResult']['coverage']['archiveRef']['id']['_value']

That will be a big gibberish string like v79U1TE0pwleCkEioB. Then you pass that to

xcrun xcresulttool export --type directory --path Foobar.xcresult --id v79U1TE0pwleCkEioB --output-path Foobar.xccovarchive

That creates the xccovarchive directory. Run the sonar conversion script on that directory and it will run about 10x faster than running it on the xcresult.

[sylvain-combe-sonarsource]

Hello @silverhammermba
I implemented your suggestion with #121
Your comments are welcome!

[silverhammermba]

That change looks good to me. I'm fine with closing this, though I wasn't involved in the original report

[sylvain-combe-sonarsource]

Going ahead and closing this thread after the merge of #121 yesterday
Thanks to all for your inputs.