According to Built-in cacheable tasks the gradle task "test" supports build caching. I wonder how the build cache works, if I run gradle clean between 2 gradle test executions. Since gradle clean deletes the test results (assuming these are parts of the output of gradle test in the build cache context), the cache won't work here. Is that correct?
Some background:
We've got a multi-project setup in gradle and would like to skip tests in subprojects, when there were no changes.
The build cache does not store the task outputs in the project workspace, but in a local or remote build cache. The local build cache lives in the Gradle user home.
So the cache will work, even if you run clean, since the outputs of the test task are stored in the build cache and are not removed from there by running clean.
Related
I am building a Spring Boot REST API application and using Kotlin as the language.
For the development I am using IntellJ as the IDE.
The project structure looks as follows:
Is there a way to watch changes in the folder src to trigger the gradle task ./gradlew test after files have been changed?
You can use Gradle's support for continuous builds:
./gradlew test --continuous
This will cause Gradle to watch the filesystem for changes and execute the test task and any tasks upon which it depends whenever a change is detected.
You can right click the gradle task and set it to be done e.g. after each build.
I am trying to understand how to setup an incremental build in Azure Devops using gradle as build tool.
So far, I have tried to run gradle with --build-cache and I am caching the $GRADLE_HOME/caches directory. In my understanding that should include the build cache.
It's not working however. When I run the gradle build locally, with all build directories removed, gradle is going to be able to skip about 80% of the build time by skipping 70/200 tasks when using the build cache.
When I run the same config on azure devops, however, gradle does not skip a single task, and therefore takes rather long.
I am sure, I must be missing something - but what is it? a
I'm currently trying to migrate a project from Gradle 3.5 to the latest Gradle version 4.9. and I'm running into the problem, that Gradle doesn't find the resources that it needs to execute the junit tests. These resources are generated upfront and contain some configuration files and referential data.
The project uses a combination of npm and Gradle to compile. Usually we run a npm script which executes a couple of tasks sequentially using run-s, e.g. webpack builds to generate some static resources. At the end we compile everything together using Gradle. The last Gradle task also executes the junit tests. This step fails and makes the whole build fail. The Gradle runner complains that some resources are not found, although the get properly copied to the right places.
When I execute ./gradlew test --rerun-tasks (Yes, we use the wrapper, which has been properly upgraded, too) right after the last Gradle build step failed, it executed the junit tests successfully.
I know, that the directory structure changed in Gradle 4.x, but this doesn't seem to be the problem.
My suspicion is, that it has something to do with how we normally run the whole build process. Something in the combination with npm.
At the moment I have a project, lets call it mightymouse. Mightymouse POM is a multi-module project for mightymouse-web and mightmouse-backend.
Both of the sub modules have tests. In my situation, the mightymouse-web project compiles, test, package, install, deploys first. Then then -backend project goes through, only to fail during the integration-test stage. (Yet, it still goes through to the deploy stage).
The Jenkins job is setup to execute mvn clean deploy.
Question: Is there anyway to prevent Maven from going all the way to the deploy step on any module failing it's tests?
By default, a maven multi module build also uses the fail-fast option
--fail-fast - the default behavior - whenever a module build fails, stop the overall build immediately
Moreover, by default the maven-failsafe-plugin already fails as soon as an integration test fails via the testFailureIgnore option
Set this to true to ignore a failure during testing. Its use is NOT RECOMMENDED, but quite convenient on occasion.
User Property: maven.test.failure.ignore
Default: false
Note that the maven-surefire-plugin has the same for unit testings.
Hence, by default a multi-module build should stop as soon as a test fails (unit test or integration test), no further module would be built and not further maven phase should be invoked.
However, a Maven Jenkins job (and not a freestyle Jenkins job invoking Maven) set this option to true by default and hence the build would not fail, it will keep on and deploy, while the job would be set to UNSTABLE and not SUCCESSFUL (but still deploying).
As such, you could change your maven invocation in your Jenkins job to:
mvn clean deploy -Dmaven.test.failure.ignore=false
Overriding thus Jenkins default settings and meeting your requirements.
Short version of question:
Is there a way of telling gradle not to resolve dependencies? I know I can skip single task with -x switch but resolving dependencies isn't performed though some task I guess, to I don't know how to do it.
Long version:
Right now I can run tests from gradle with simple 'gradle test' which performs gathering dependencies, building and running tests..
But I'd also like to run tests using gradle on some other machine which can't download dependencies from maven. I thought that I could just perform some packaging which would download all dependencies to some lib folder, and I could expand tests classpath (in that task) to this folder. The problem is, that gradle still tries to contact maven when I run 'gradle myTests'. Is there a way of preventing resolving dependencies for this single task?
There's the --offline flag. Alternatively, you can declare a flatDir rather than a maven repository whenever the build should be run with "local" dependencies.
For my use case, my internet is restricted so I would setup dependencies while I can still have full access. And when I'm restricted, go to Preferences, search for Gradle, and check "Offline work".
Of course I'll have to turn it back on whenever new dependencies are added.