When I run
./gradlew clean assembleRelease
my binaries are built, but the unit tests do not run.
When I run
./gradlew clean build
all binaries are built and all unit tests are run, twice... once for debug and once for release.
How can I achieve what 'clean build' does but only for the release buildType?
Context: The main problem I am trying to solve is what is the proper way to configure a jenkins job to build assemble and run all unit tests for the RELEASE buildType only.
The way I have solved this for now is by adding this code block to the bottom of build.gradle in each module of my project:
project.tasks.assembleRelease.dependsOn {
project.tasks.findAll { task ->
task.name.startsWith('testRelease')
}
}
This does what I need it to do, such that when our jenkins server job runs:
clean assembleRelease
All the release unit tests are run and the artifacts are all created.
Not sure if this is the best/cleanest solution.
This worked for me:
gradlew clean check assembleRelease
This cleans and verifies (includes running tests) for all subprojects (even plain java ones) and then assembles only the release buildType, i.e. dexing and signing is only done as specified in the release closure.
I'm not sure if that's the cleanest solution, either. Still, it does not append boilerplate to build.gradle files and its is faster than running the clean build tasks.
A good overview over gradle's anchor tasks assemble, check and build is provided by the Gradle Plugin User Guide.
Related
When I run "gradlew clean deployNodes" or "gradlew deployNodes", I get a warning on Quasar library:
QUASAR WARNING: Quasar Java Agent isn't running. If you're using another instrumentation method you can ignore this message; otherwise, please refer to the Getting
Started section in the Quasar documentation.
How can i fix this warning ?
I upgraded Corda to 4.1
you'll want to double-check the intellij settings.
Navigate to Build, Execution, Deployment -> Build Tools -> Gradle ->
Runner (or search for runner) Windows: this is in "Settings" MacOS:
this is in "Preferences" Set "Delegate IDE build/run actions to
gradle" to true Set "Run test using:" to "Gradle Test Runner" If you
would prefer to use the built in IntelliJ JUnit test runner, you can
run gradlew installQuasar which will copy your quasar JAR file to the
lib directory. You will then need to specify -javaagent:lib/quasar.jar
and set the run directory to the project root directory for each test.
As mentioned in the comments from manish, make sure to try cleaning the gradle cache as well: ./gradlew clean build deployNodes.
Joel has a good answer for a similar quasar issue on this StackOverflow question: Error when running Corda flow tests from IntelliJ
Upgraded to IntelliJ 14.0.1 One of the big new features I was looking for:
"If you run tests via a Gradle task, the IDE offers you the standard Test Runner instead of the console output." (Source: https://www.jetbrains.com/idea/whatsnew/#buildTools)
I right click on the Gradle Task to run our Integration Tests:
However, I see the results of the test still going to console output, not to the Test Runner:
Has anyone been able to get this new feature in IntelliJ IDEA 14 to work?
Thank you in advance,
Philip
Looks like IntelliJ looks for a task named "test" rather than a task of type Test.
https://github.com/JetBrains/intellij-community/blob/master/plugins/gradle/src/org/jetbrains/plugins/gradle/execution/test/runner/GradleTestsExecutionConsoleManager.java#L191
Rename the test task to unitTest and then create a wrapper that runs both:
// Rename test to unitTest
tasks.test.name = "unitTest"
// Wrap and run both
task test(dependsOn:['unitTest', 'integrationTest'])
If you only want to run integration tests, just overwrite it:
task test(overwrite: true, dependsOn: ['integrationTest'])
This allows me to run the integration tests in the test runner successfully (at least it works in IDEA 15 EAP but it should work in 14 as well I would think).
I still get this in IntelliJ 2017.1, but specifically when running tests in the gradle buildSrc directory. After digging a while, it turns out that the Gradle API doesn’t expose the test tasks in the special buildSrc directory to Intellij, so IntelliJ doesn’t recognize it as a test.
Workaround: Open another IntellIJ project for the buildSrc directory directory instead of trying to run tests cleanly inside the root project.
Our MSBuild definitions build both Debug and Release build configurations. (This is due to the deployment system we use and can't be changed.) The problem is that since we run automated tests, they are run twice, once on each build. Is there any way for me to configure tests to be run only on release build?
We're using VS2010/TFS2010.
In the TFS build definition, under the Process tab, under Automated Tests -> Test Sources -> Test Sources Spec, can you modify the path spec to include the name of the releases folder so that the test binaries from the releases folder only are tested?
Change the spec from:
**\MyApp*Tests.dll
To read:
**\Release\**\MyApp*Tests.dll
It looks like a little tweak to Nick's answer did the trick.
..\Release\**\MyApp*Tests.dll
In maven, what does "-e" stands for in the following command.
mvn -e clean install
Moreover, what is the difference between
mvn clean install
and
mvn clean compile
As Satish stated, the "-e" switch will display execution errors in the maven output.
As to the difference in "install" vs "compile", those are different Maven lifecycle stages. See the Introduction to the Build Lifecycle documentation for help with that. The key to remember is that Maven will execute all lifecycle stages up to and including the one you specify, and then stop.
Specifically in your case, "mvn clean compile" will run Maven with two lifecycle targets, the first being "clean", and the second being "compile". The "compile" lifecycle phase will run the build up to and including the compilation of project source code. The "install" lifecycle phase will run all the way through packaging your project into it's container (jar, war, etc) and will install it to your local maven repository, which resides on your local machine. When a project is installed to your local repository, other projects you build on your machine can reference it without having to have any knowledge of where the source code or project build artifacts actually reside.
the e flag (e = errors) prints out more detailed error messages.
mvn clean install, does compilation, linking and installs (copies to app server etc)
for more maven options look at this ref card
http://www.scribd.com/doc/15778516/DZone-Refcard-55-Apache-Maven-2
or maven command list
http://cvs.peopleware.be/training/maven/maven2/mvnCommand.html
mvn clean install - First, cleans already compiled class files (probably in target/ directory). Then, it compiles the classes, generate the jar, and then install the created jar to your local m2 repository (probably located at ~/.m2/repository/).
mvn clean compile - The clean does the same thing as above. And, then, it compiles the java files in the project. And, stops there. It doesn't create the jar nor install anything to the local maven repository.
-e switch will display the stack-traces occur when your build is failed. It's a normal stack-trace that java programs produce when exceptions occur. Do note that Maven itself is a Java program.
I've created a hudson job for our maven multi-project with 5 modules to deploy the SNAPSHOT artifacts to the maven repository. That's ok, as long as it builds successfully without test failures. However, now I'd like to fulfill the following requirements:
When a module has a test failure, the build should continue bulding and test the other modules, but turn yellow. Using -Dmaven.test.failure.ignore=true accomplishes, but fails at the next requirement.
When a module has a test failure, none of the artifacts should be deployed to the maven repository. Other projects depend on the snapshots this project and those projects only want to use the latest snapshots that don't have any failing tests.
Preferably, use the hudson maven integration instead of a free script we get the hudson report pages (red/yellow/blue status per module, build log error coloring, ...). Specifically running the maven build twice (first mvn test -Dmaven.test.failure.ignore=true, than mvn deploy -DskipTests) is not a solution because it's a performance loss and it confuses the hudson report pages and it's not atomic (it updates from the repositories again in the second build).
Is there any way to accomplish this?
There is an post build option called Deploy artifacts to Maven repository. If you do not select Deploy even if the build is unstable, then that mean if test fails, it won't deploy anything. Together with the -fae in the command, thing should work in your desired way
maybe you can try use mvn -fae option with you jobs on hudson - it make maven fail only after full build
If build time isn't a problem for you, I think the better option is to create another job, just for deploying. Something like this:
Configure your original job (let's call it "build job") with "mvn -fae clean install"
Create a new job ("deploy job") with "mvn deploy", and don't configure any Build triggers for it
In the "build job", enable the Build other projects option, under Post-build actions and set it to run your "deploy job".
Maybe you can try to configure both jobs to use the same workspace, saving some time on the whole build/deploy process.
If you happen to use Artifactory as a repository manager, you can use the Hudson/Jenkins Artifactory plugin to deploy your artifacts. This plugin will only deploy your artifacts if all tests pass for all modules of a Maven build.