We Keep Coding

Gradle - Test tasks results not cached

"Test" tasks in my multi-module build are not being cached by Gradle. Incremental build works fine and reports everything as up-to-date, but if I perform clean build tests are always executed.
I am seeing this message Non-cacheable because 'Task outputs cacheable' not satisfied [ENABLE_CONDITION_NOT_SATISFIED] for all the test tasks if org.gradle.caching.debug parameter set to true. All fingerprints are identical between executions.
Any ideas what does it mean and/or how to fix it?
P.S. Using Gradle 6.7 with Junit 5 and JaCoCo. Disabling JaCoCo does not change anything.

Run all JUnit tests with Gradle

I have a Java application which uses Gradle as build system. This is multi-project built (several Java projects).
When I run gradlew test and some of the tests are failing I've noticed not all tests actually run.
If I add the following code to build.gradle it does run all tests but of course, the built always complete successfully:
test {
ignoreFailures = true
}
I have two questions:
Does gradle stop executing tests after the first failure?
Is there a way to run all tests (even when some fail) and still have the built fail if some of them failed?

Gradle offers the --continue parameter gradlew build --continue which executes all tasks regardless of their success. However, if any executed task failed the whole build is marked as failed.
I think you are looking for that switch.

Make sure you are running tests from the root of you project.
The test task is part of Java Plugin for Gradle. As from the official documentation:
Projects with large test suites can take a long time to execute even though a failure occurred early on leading to unnecessary wait times (especially on CI). To short circuit this behavior, the Test.getFailFast() property allows you to cause the test task to fail after the first test failure instead of running all tests. When this property is true, the resulting output will only show the results of tests that have completed up to and including the failure. To enable this fail fast behavior in your build file, set the failFast property to true:
test {
failFast = true
}
The --fail-fast command line option enables the behavior from the command line. An invocation looks like:
gradle test --fail-fast
The default value for the failFast property is false.
Official documentation can be found here.
So to answer your questions:
By default, Gradle does not stop executing tests after the first failure. This behaviour can be modified using failFast property.
Default behaviour should do the trick. By running gradle test all tests will be run. If any of them fail, the build will fail. Since you have a multi-project build, make sure you are running Gradle from your root project.

Profiling Maven Compilation for a multi-module project

I have a multi module maven project which is taking a little too much time. Can some one let me know if there is a way it is possible for me to see which step in maven compilation is taking how much time. Also is it possible to see which steps are getting executed in parallel relative to which step?
I am executing maven like below:-
mvn clean install -T 4
Maven Version 3.5.0

Unit Tests Fails in Build Service But Not Locally

Two tests fail in my build service that will not fail when ran locally.
What I've discovered is that when I execute mvn clean test locally the sort order of my test classes are alphabetical (package and class), but when ran in the build service they're seemingly random.
It is not my intention of needing a specific "order" so I'm definitely concerned that one test prior to another is hinting at an isolation issue. However, I don't think I can just tell maven to run classes in a certain order.
What can I do to try to reproduce?
EDIT
I cloned my build plan, but pointed at a forked repo (same code) and it ran successfully with no failed tests...

You should try to execute mvn -Dsurefire.runOrder=random clean test for random order locally.
But even if your build fails locally, random order is not the best option to reproduce failures because of test order. If the tests are all green when run in alphabetical order, you might be able to make your build consistently fail with mvn -Dsurefire.runOrder=reversealphabetical clean test
There are also a couple of more options -- see runOrder documentation

How to avoid double compilation and testing with cobertura:check?

I'm using maven-cobertura-plugin in order to calculate code coverage in my project. As I understand, this plugin starts a new/forked build cycle in order to compile and test the code base. When it's done the plugin calculates code coverage. As I understand, this is the only approach the plugin can use, and it's fine for me.
The problem is that before cobertura plugin my code base is compiled and tested already. Thus, I'm experiencing duplicated compilation and testing. Is it possible to avoid compilation and testing before cobertura? Or maybe there is some other workaround?

Is it possible to avoid compilation and testing before cobertura? Or maybe there is some other workaround?
There are several issues about this (see MCOBERTURA-83, MCOBERTURA-76) but AFAIK, there is no perfect workaround (due to the way the life cycle is constructed - things might be improved in Maven 3).
The only one I'm aware of (works with CI servers) would be to run:
mvn clean install -Dmaven.test.skip=true
and then
mvn cobertura:check
Instead of binding cobertura:check on the build lifecycle.
Note that compiling twice shouldn't be an issue as all classes should be up to date.

As far as I know, cobertura needs to do bytecode weaving on your code to be able to work.

The only way I was able to work around that was to instrument the byte code as part of my build (by binding the cobertura:instrument goal to the verify phase and also bind the default-test execution from maven-surefire-plugin to the verify phase so it doesn't get executed as part of the test phase on every cobertura goal execution.