Skip to content
This repository has been archived by the owner on Sep 19, 2018. It is now read-only.

Enable code coverage setting only for Debug builds - Xcode 9 issue #262

Closed
deepumukundan opened this issue Sep 18, 2017 · 0 comments
Closed

Enable code coverage setting only for Debug builds - Xcode 9 issue #262

deepumukundan opened this issue Sep 18, 2017 · 0 comments
Assignees
@davidahouse

Comments

@deepumukundan
Copy link

deepumukundan commented Sep 18, 2017 •
edited by jeremy-w
Loading

grep -R "codeCoverageEnabled" Carthage (Freddy integrated via Carthage) returns

Freddy/Freddy.xcodeproj/xcshareddata/xcschemes/Freddy.xcscheme:      codeCoverageEnabled = "YES">
Freddy/Freddy.xcodeproj/xcshareddata/xcschemes/MobileFreddy.xcscheme:      codeCoverageEnabled = "YES">
Freddy/Freddy.xcodeproj/xcshareddata/xcschemes/TVFreddy.xcscheme:      codeCoverageEnabled = "YES">

Several other libraries are turning off code coverage for release builds as iTunesConnect is rejecting builds with Code coverage on in archives:

Hopefully Carthage adds this capability in it without having to change each library, but meanwhile,
can we turn off code coverage for release build for Freddy?
@davidahouse davidahouse mentioned this issue Oct 15, 2017
Closed
@davidahouse davidahouse self-assigned this Oct 15, 2017
@davidahouse davidahouse mentioned this issue Oct 18, 2017
Merged
davidahouse added a commit that referenced this issue Oct 18, 2017
@davidahouse
Disable code coverage for release builds fixes #262
b08a03b
jeremy-w added a commit that referenced this issue Oct 18, 2017
@jeremy-w
Merge pull request #269 from bignerdranch/house/disable-code-coverage…
bb0b76a 
…-for-release-builds

Disable code coverage for release builds

This PR Fixes #262 

We have not run into this issue yet, but I see no harm in turning this off for Release builds. There is some chatter online about this:

http://blog.carlossless.io/xcode-9-and-carthage-coverage-data

Seems related to how Carthage builds frameworks, although I suspect something else is going on here. Again I don't see any harm in changing this flag for Release builds as it shouldn't be relevant anyway. Frankly I'm not sure why the default is `Yes` for `Release` anyway.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@davidahouse davidahouse

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@davidahouse @deepumukundan