Don't build/test debug builds of library modules.
artem-zinnatullin opened this issue · comments
Looking at CI logs I've noticed that we're building and testing debug build type of library modules and then do the same for release build type.
There is no need for that since we don't have build-type specific code, so removing debug builds should speedup CI and save us some log output lines because we're slightly more than 10k atm and Travis only renders 10k lines in its UI, otherwise you have to look at raw log output.
Heh, for some reason? Is there a way to check coverage on the release build))?
Ah damn it, so we should not build release then :D
Btw, what's wrong with measuring coverage on release build? We don't run proguard on it
It seems with jacoco classes will be compiled with debug information (line numbers) to allow for source code highlighting
should not build release then
😂
debug information (line numbers)
Is it ok to keep this meta in release?
Ahhhhhhhh daaaamn wait, I'm afraid we do that anyway!!1 jacoco-android.gradle adds coverage to all build types
It would be super cool if you could check if our release aars contain jacoco calls, that would be facepalm.jpg
We can solve this, I see couple ways, but I need to sleep now
Ah, just in case, previous releases were done manually and I usually run ./gradlew clean uploadArchives which doesn't run tests (because I trusted our CI) and doesn't add jacoco tasks to graph, so previous releases most likely don't include jacoco
Easy solution to not include jacoco calls into released jars would be to change skip_cleanup: true to false in deploy section of travis.yml or add clean to Gradle tasks in release mode