You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
esteluk
changed the title
Slather selects doccarchive when looking for Binary
Slather selects doccarchive when looking for binary
Jul 25, 2022
A minor one:
If we have
RUN_DOCUMENTATION_COMPILER = YES
within our target, the target'sdoccarchive
gets generated alongside the built target.But it's possible for
find_binary_file
to confuse the output within thedoccarchive
for the target module, because they share the same name. eg. this error:We're able to work around this by specifying
binary_file
instead ofbinary_basename
directly in our configuration, but obviously it would be preferable, and more portable, ifbinary_basename
continued to work.There's already explicit filtering of
.dsym
andswiftmodule
files withinfind_binary_files
, so one solution might also be to skip thedoccarchive
here as well.Happy to suggest a PR, just wanted to try and raise an issue first!
The text was updated successfully, but these errors were encountered: