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.
Related
I'm in the process of migrating a Java project from Gradle 4.4 to Gradle 7.5. Most of this seems to be under control. However, there's one very serious problem:
The project has 692 unit tests (all using JUnit; we're using JUnit 4.13.2). When I run gradle test with 7.5, however, only about 500 tests run. To be specific, it's a number that fluctuates between 527 and 529 tests.
Does anyone have any suggestions about how I troubleshoot this issue? Is it some kind of version compatibility problem? I would have put in the content of the build file, screen output, etc., but honestly, with this kind of problem I simply have no idea what kinds of diagnostics from me would be helpful!
Thanks.
I have Maven project on Jenkins that runs tests. It usually takes 18 minutes to run more than 1000 tests, but now my build with 500 tests
already lasts 1 hour and it hasn't finished yet.
Anyone has suggestion?
Thanks.
It is hard to guess what is causing the delay based on the question. In general, you can improve the build time by launching it in parallel.
You can launch maven with the -T 1C flag. This will attempt to start a parallel build of at most 1 thread per core. Maven can determine based on the dependency tree structure which builds can be started parallel.
Check Maven: how to do parallel builds? for more info.
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
We are using TeamCity 6.0.2 and have a build configuration that runs SoapUI tests. The tests themselves run in approx. 45 seconds when running in command line.
To see the results of the test, we use Ant JUNit report watcher with this Report paths value:
TestSoapUI\SoapUI-testresults\TEST-*.xml
And then the tests are taking up to 15 minutes, with a CPU at 100%.
What can we do to reduce this time? Other report path? Separate the test step from the report step?
(We also filed an issue to JetBrains, if you're interested:
http://youtrack.jetbrains.net/issue/TW-16404)
The issue was solved by the JetBrains team:
http://youtrack.jetbrains.net/issue/TW-16404
Upgrade to TeamCity 6.0.3 if you have the same problem.
is there a way to improve the performance of the Grails commandline tasks. For example the test-app task is taking some time until all dependencies are checked, classes compiled etc. Even simple tasks like create-domain-class is taking some seconds to run.
You can use the "grails interactive" shell for running unit tests, generating basic artifacts and so on. This way you don't have to pay the startup cost for every simple command.
Note that this didn't really work for integration tests last time I tried.