How to determine xccoverage (or DerivedData) location?



We’re trying to use xcov in Danger to enforce a minimal coverage percentage in our pull requests. Xcov analyses the *.xccoverage files that are in the DerivedData/AppNam-somerandomstring/Logs/Test/ directory. The problem is, it cannot determine this location automatically when run on
By default, xcov gets this location using the grandparent directory of SYMROOT from the Xcode build settings (xcodebuild -showBuildSettings). However, this setting seems to change after the Xcode Test step, causing xcov to fail.
We could set the location in the Danger config, but there’s no way to find it using the available environment variables. For now our only option seems to be getting the location by scanning /Users/vagrant/Library/Developer/Xcode/DerivedData/ in a custom Script step.

Do you have any advice on how to get xcov working automatically? Or any better way to find the exact DerivedData location?

Update: I was able to get the correct DerivedData location by using the OBJROOT value from the xcodebuild -showBuildSettings in a custom script step. This is an ugly workaround, so I’d still appreciate some help here.



Hi @jcopini,

Unfortunately that’s exactly how you can get the DerivedData AFAIK, as the DD path is generated by xcodebuild and is a hashed value of some parameters of the project, including the path, and the .app etc. pathes inside the DD dir also depend on e.g. the Scheme/Config you build (so it can be different for e.g. Test and Archive actions / builds).

An alternative might be to specify the path of the DerivedData folder, which can be done via an additional param for xcodebuild:

$ xcodebuild -help


-derivedDataPath PATH                                    specifies the directory where build products and other derived data will go


(See e.g: )

Keep in mind, depending on your Xcode project configs changing the derived data dir might cause issues. It usually does not, but we did see issues which did not happen when DD path was not modified.

In case of the Xcode Archive step you can use the Additional options for xcodebuild call (Debug category) (xcodebuild_options - input to set additional, custom xcodebuild options.

If you’d have any questions just let us know! :slight_smile:



Great, we can work with that :wink:
Thanks for helping!

1 Like


Hi @jcopini,

how did you manage to get the .xcactivitylog in the end? I’ve tried numerous tweaks, scripts and changes and I still can’t manage to find the .xcactivitylog files for using xcov and xcprofiler in Danger.

I can get the DerivedData location but the log is not present there (it works locally), just not on Bitrise.

Thanks in advance.



you could try running mdfind -name .xcactivitylog to find where this file is actually, and/or set up a script that parses it to an env var immediately that you can use later :upside_down_face:



Both I’ve tried and without success :frowning: I’m currently looking into if the Build for simulator Bitrise step is not deleting the files somehow and instead building the project using a custom script.

EDIT: It is! So it seems the Bitrise Build for simulator step automatically deletes all build data. Using a custom script works fine now.

1 Like


Glad you found a solution, I just checked and there is indeed a cleanup functionality. :upside_down_face:



Hi @doha,

Glad you found a solution already! In case you’re still interested, I’ll share our solution as well. It’s not pretty, but it works for us :grin:
We solved it by adding some lines of bash scripting before the Danger call to add the derived data path to the environment variables:

DERIVED_DATA_PATH=`xcodebuild -project "xxxx.xcodeproj" -scheme "xxxx" -showBuildSettings | grep OBJROOT | cut -d "=" -f 2 - | sed 's/^ *//'`
echo "Found derived data path: $DERIVED_DATA_PATH"
envman add --key DERIVED_DATA_PATH --value "$DERIVED_DATA_PATH"

That works with the following in our Dangerfile:
   scheme: "xxxx",
   project: "xxxx.xcodeproj",
   derived_data_path: ENV['DERIVED_DATA_PATH'],

I’m pretty sure there’s easier ways of doing this though :grin:

We did have to stay on Xcode Test step version 2.0.0, as 2.1.0 breaks this solution. See also



Thanks for sharing @jcopini! :slight_smile: