Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes how profdata_coverage_dir is created. #145

Merged
merged 4 commits into from
Feb 23, 2016

Conversation

guidomb
Copy link
Contributor

@guidomb guidomb commented Feb 10, 2016

Version 2.0.0 of this gem fails with the following error in my project

Slathering...
error: Failed to load coverage: No object file for requested architecture
Test Coverage: NaN%
Slathered

running with verbose flag generated the following output

Slathering...

Processing coverage file: /Users/guidomb/Library/Developer/Xcode/DerivedData/Syrmo-gaycqmnmsbrteuaehthyregbeoec/Build/Intermediates/CodeCoverage/Syrmo/Coverage.profdata
Against binary file: /Users/guidomb/Library/Developer/Xcode/DerivedData/RESideMenu-drntsirbvffjqvdnxrvriljshzty/Build/Products/Release-iphoneos/RESideMenu.framework/RESideMenu

error: Failed to load coverage: No object file for requested architecture
Test Coverage: NaN%
Slathered

As it can be seen the binary file was pointing to another project (a dependency of my project, Syrmo, to be precise). After some debugging I found that the cause of this error was related with how profdata_coverage_dir was created.

Guido Marucci Blas added 2 commits February 9, 2016 21:34
The previous implementation of this method was assuming that
the first product always has name, which doesn't always happen.

The documentation of PBXFileReference says that the 'name'
attribute is "often not present.". For more info check
https://github.com/CocoaPods/Xcodeproj/blob/master/lib/xcodeproj/project/object/file_reference.rb#L13

If the name attribute is not present the profdata_coverage_dir
created was the first child of the build directory (which by
default is the derived data directory). This is wrong.

Also the build directory was being concatenated using plain
string manipulation which led to path of the form:
"~/Library/Developer/Xcode/DerivedData//**/PRODUCT_NAME".
This is why File.join is used to join the build directory path
with '/**/PRODUCT_NAME' to comtemplate the case of build directory
already ending with '/'.
In order to mimic how xcodebuild uses the derived data directory
the project names should be appended to TEMP_DERIVED_DATA_PATH.

This fixes most of the failing tests.
@guidomb
Copy link
Contributor Author

guidomb commented Feb 10, 2016

@neonichu Coud you help me fix the remaining tests? The problems seems to be that the mocked scheme is wrong. The mocked scheme is "FixtureScheme" and should be "fixtures"

@neonichu neonichu mentioned this pull request Feb 10, 2016
@guidomb
Copy link
Contributor Author

guidomb commented Feb 19, 2016

@maintainer @neonichu Can anyone take a look at this? I can fix the failing tests if you provide me some insights about them. Also what do you guys think about this changes?

@neonichu
Copy link
Member

Thanks for the PR!

I agree with you that the mocked scheme should actually be different.

The last test is failing because the expectation wasn't updated with new path: https://travis-ci.org/SlatherOrg/slather/builds/108183974#L324

@guidomb
Copy link
Contributor Author

guidomb commented Feb 22, 2016

@neonichu Tests are passing now 😄 !!! Let me know if this is ready to be merged. In such case, Would you mind cutting a new release?

@neonichu
Copy link
Member

Nice, would you mind adding an entry to the Changelog as well?

@guidomb
Copy link
Contributor Author

guidomb commented Feb 22, 2016

@neonichu Done!

neonichu added a commit that referenced this pull request Feb 23, 2016
Fixes how profdata_coverage_dir is created.
@neonichu neonichu merged commit 3b67948 into SlatherOrg:master Feb 23, 2016
@neonichu
Copy link
Member

Thanks a lot for the contribution!

@guidomb
Copy link
Contributor Author

guidomb commented Feb 23, 2016

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants