Slather selects doccarchive when looking for binary
esteluk opened this issue · comments
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!