Open Radar

 
Summary:
Finally in Xcode 7 we can specify the output for our test results and code coverage files. This is a great stride forward in enabling more stable tooling to be build on top of Xcode. However, one of the new file formats that it outputs is not parseable. When the code coverage file, .xccoverage, is generated, it is a private class so therefore 3rd party tools cannot use that file and instead we have to dig around in the (undocumented) DerivedData file structure for something to parse.

If -resultBundlePath is going to output files, they need to be parseable by 3rd party tools. It is unreasonable to expect every iOS developer to use Xcode Server as their continuous integration system.

I'm fully aware that DT does not like documenting these things for valid reasons, including the ability to change them whenever is needed. We need documentation for these things so we don't have to rely on undocumented behaviors or hack around.

The industry has a need for more tools covering more use cases than Apple can build for. Apple needs to start working with us.

This is solvable in 2 ways. Either .xccoverage can be documented or the .profdata used to create that file should be added to the output of -resultBundlePath

Steps to Reproduce:
1. Unzip and run parse.sh on a non-special-internal-apple-configured computer (aka what everyone else in the world has to use), passing in a .xccoverage file
2. Crash

Expected Results:
I expect the code coverage output from -resultBundlePath to be documented or parseable by 3rd party tools

Actual Results:
It is an archived file of a private class and is therefore useless when not using Xcode.app or Xcode Server to build.

Version:
Xcode 7.1 & OS X 10.10.5

Notes:


Configuration:


Attachments:
'parse.zip' and 'parse_output.txt' were successfully uploaded.