SlatherOrg / slather

Generate test coverage reports for Xcode projects & hook it into CI.
MIT License
1.55k stars 233 forks source link

Slather selects doccarchive when looking for binary #519

Open esteluk opened 1 year ago

esteluk commented 1 year ago

A minor one:

If we have RUN_DOCUMENTATION_COMPILER = YES within our target, the target's doccarchive gets generated alongside the built target.

But it's possible for find_binary_file to confuse the output within the doccarchive for the target module, because they share the same name. eg. this error:

bundler: failed to load command: fastlane (/Users/vagrant/.rbenv/versions/2.6.5/bin/fastlane)
/Users/vagrant/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/fastlane-2.204.3/fastlane_core/lib/fastlane_core/ui/interface.rb:153:in `shell_error!': [!] Exit status of command 'slather coverage --sonarqube-xml --build-directory /Users/vagrant/git/derivedData --output-directory ./sonar-reports --input-format profdata --scheme AProduct --workspace AProduct.xcworkspace AProduct.xcodeproj' was 1 instead of 0. (FastlaneCore::Interface::FastlaneShellError)
Slathering...
error: /Users/vagrant/git/derivedData/Build/Products/Debug-iphonesimulator/AFramework.doccarchive/data/documentation/AFramework: Failed to load coverage: Is a directory
error: Could not load coverage information

We're able to work around this by specifying binary_file instead of binary_basename directly in our configuration, but obviously it would be preferable, and more portable, if binary_basename continued to work.

There's already explicit filtering of .dsym and swiftmodule files within find_binary_files, so one solution might also be to skip the doccarchive here as well.

Happy to suggest a PR, just wanted to try and raise an issue first!