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.
Related
I have a gradle build which consists of near a thirty included builds. Recently I encounter a hung with this build. I have taken a thread dump and saw there are were more than a five hundred waiting threads. Their names make me think that for each included build gradle creates a worker thread per cpu core. So if I have 30 included builds and 12 cores there will be 30x12 worker threads.
I tried to use org.gradle.workers.max property to resolve my problem but this didn't work.
Is there a best practice how to use gradle included builds the right way?
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.
We need to setup a snapshot dependency in TeamCity that runs just before the dependant build starts.
Currently we have the problem that the snapshot maybe taken 30 minutes before the build starts. (The build starts later due to other factors). Ideally we want the snapshot to be taken and then the dependant build to immediately start.
Is this possible in TeamCity? Is there another way to achieve a similar thing.
Reading between the lines I'm guessing the problem here is that the dependent build isn't always run immediately when it's snapshot dependency finishes because an agent isn't always available. If that's the case then my suggestion would be to merge the two builds into a single build configuration as that will ensure that all the steps occur with no delay in between.
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.