For some reason, during the build, Intellij is getting hung on the "saving caches..." part and can take hours before it finishes. These are extremely light programs that should build and compile in milliseconds. This makes it very hard to debug my code. I have tried reinstalling IntelliJ and the JDK. I have found a little trick where I run the code first then turn off build before run then run it through coverage or debug and it runs in a reasonable amount of time.
Compile Time
Related
I have a large project with quite a few Gradle modules (around 90+) and we're seeing some strange build behaviour - especially after migrating to a Java 11 build (from Java 8).
Specifically our test execution times are... wonky.
Running the test target for the entire project this module takes 4min 55s to executes the tests.
Running the test target for a single module on its own it merely takes 1min 15s for the exact same tests with the same results.
Note: Before these both Gradle tests a clean on the entire project had been executed. These times are reproducible with minor time differences.
As a reference: running the tests for the module in IntelliJ I'm at 1min 18s.
I have played around with maxParallelForks and forkEvery, but I did not notice any significant changes.
I'm at a loss to what I could try and would appreciate any ideas and suggestions.
Teamcity builds are taking forever to complete because on every build, it's downloading all the dependencies (and sub-sub-sub dependencies) which is quiet pointless. I've been facing build time outs after waiting for 20-30 minutes which is extremely frustrating and annoying.
I'm wondering if there is a configuration which can let us choose when to re-download all the dependencies and when not to.
Here are the configurations:
I'm suspecting it's because of the -Pgenerate-dependencies flag. Not able to find much about it though.
I have TeamCity set up to build some Visual Studio solutions and package them into an artifact. This works just fine most of the time.
However, once in a while (maybe 1 in 100 builds), the files built from TeamCity does not run. We use a lot of dependency injection in our code and some times our application refuses to start because it can't find the correct dependencies in the files. There are no missing files in the artifact, though.
We then force TeamCity to build everything once more (by adding a new line to a file and commiting it), and suddenly our application starts again.
It is then obvious to me that there is something TeamCity has not built correctly, though I'm unable to discover what it is, as all the build logs report no errors or warnings of any kind.
What can cause this strange behavior, and what can I do to prevent it from happening in the future (or what can I turn on to get more extensive logging to try to find out what happens when it fails)?
Check the errors when Team City does not run. Does it say why it cannot run? Sometimes have Team City fail a build simply because the version control system had a hiccup. Based on the error in Team City's log it can be obvious that it was only because of that. If you do not do clean builds try doing that and seeing if it makes the intermittent problems go away.
I've tried building it:
parallel (helps a bit)
daemon=true
preDexLibraries true/false ( no big difference )
incremental true
offline
It takes >40s EVERY time. It doesn't matter if I change anything or not. Building it after "gradle clean" takes >50s.
I hope that I'm doing something wrong. Eclipse/ant could build consecutive builds WITH CHANGES in <10s.
Any help how to bring this <10s appreciated.
Yes, we have a lot of modules, some jar libraries, some maven dependancies. Still don't get why would it take >40s for two consecutive builds with no changes.
Gradle used: 2.2.1
Android studio: not really relevant, usually building it only with Gradle.
EDIT: adding some profiling logs.
:app:dexProjDebug 22.541s
:app:shrinkProjDebugMultiDexComponents 4.279s
:app:compileProjDebugJava 3.478s
:app:packageProjDebug 2.591s
:app:processProjDebugResources 2.590s
:app:packageAllProjDebugClassesForMultiDex 2.536s
:app:createProjDebugMainDexClassList 2.126s
You need to properly define inputs and outputs even for library projects with source code. (Gradle Documentation). Do you get UP-TO-DATE message when you rebuild second time onwards?
If you have no changes to the other modules, you can build the app itself using gradlew :app:build. This will eliminate the time Gradle spends on building the other modules. You can build any module separately like this as well, using gradlew :moduledirectoryname:build. If you need to build one module and the app, you can execute both tasks at once to avoid going through Gradle's configuration stage twice: gradlew :app:build :moduledirectoryname:build
If possible, update to Gradle 2.4. It's significantly faster (claiming 20-40%).
One of the most significant build time reducers is the preDex task. Check whether preDex is running in your build. It increases build time the first time you run it, but dramatically reduces build times in subsequent builds, as most of your SDKs and libraries will already be dexed. Note however that it won't run under some conditions, e.g. if you use multidex.
Btw Google are well aware of build times with Gradle and Android Studio and are going to introduce significant improvements in upcoming releases, including Jack and Jill which will allow compiling from source code directly to dex. You can already try to experiment with them - see here: http://tools.android.com/tech-docs/jackandjill.
Also worth watching this video from recent Google I/O: https://youtu.be/f7ihSQ44WO0?t=327
Download Genymotion emulator. It is very fast and good to run android apps. It will save you a lot of time.
Here is the link - GenyMotionDownload
Okay, Emma is killing me. I spent two days on this already.
There two issues with Emma now
It crashes partly through unit testing
It complaints about class stamp mismatch. : com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] runtime version of class xxx in the coverage data is not consistent with the version of this class in the metadata, possibly because stale metadata is being used for report generation.
While I can live with the crashes, it only often but I don't intent to fix it,
INSTRUMENTATION_RESULT: shortMsg=Process crashed.
[exec] INSTRUMENTATION_CODE: 0
However, I do like to see my coverage result.
I have tried:
clean the device
wiped out entire workspace (in Jenkins)
using the command prompt (bypass jenkins, ant clean, ant emma debug install test)
My understanding of this error is the apk installed and under unit test contains different binaries and hence its metadata info is out of date with the coverage.em generated.
I can confirm this is IMPOSSIBLE in my case, as I clead, ant clean and even wiped out entire work space and the phone memory. It just doesn't make any sense to me now.
Please HELP~
I am using Android sdk r16, NDK 5c, and the default settings from Ant and Emma.
I'm seeing the exact same problem with my Android project (which uses a native code third-party library via JNI). It turns out that the EMMA error message is slightly misleading in this case. It's triggered because the statically generated coverage meta-data on the host (coverage.em) does not match the coverage data collected during run-time of the application on the device (coverage.ec). In fact, it's not only a "mismatch", but the coverage.ec is completely missing. This is due to the crash in native code: On Android, a crash in native code will shut down the associated Java process, too, and in fact even restart the VM. This means EMMA is killed, too, and it does not have chance to flush the coverage.ec file to disk any more, which is why it's missing.
I've wondered whether it would make sense to make EMMA flush the coverage.ec file more often before the crash, but then again it's questionable how valuable an incomplete coverage info would be as
the file format probably is just not build in a way that makes sense to be parsed incrementally,
a partial coverage.ec still would mismatch a complete coverage.em,
coverage generated from a partial coverage.ec would report the wrong coverage with respect to all your tests in the suite.
So, long story short, the best way to address this is to fix your native code to not crash.
I met with this problem too when using EMMA for android. It's because the coverage.ec you pull from sdcard is not consistent with coverage.em. Try rebuild the instrumented version of the project.
Try the following steps:
ant clean release
ant instrument
ant installi
adb pull /mnt/sdcard/coverage.ec
use the coverage.em ( newly generated under the bin folder of the project through step 2 ) and coverage.ec to generate the coverage report
You can refer to EMMA for Android for detailed information.