Is it possible to have a maven build write a file when it fails? - maven

I have a maven build running in a Jenkins job.
I need to do some post-processing stuff after the maven build but during the job, and so I'm running mvn with the -fn (--fail-never) option (jenkins will halt the job immediately otherwise).
The catch, of course, is that if the maven build step failed, I need to fail the job in a subsequent build step.
In the past I've done this sort of thing by writing a file to a certain location if the build failed, and then using the Ant task to fail the build. So this is the approach I'm going for.
Is it possible to get maven to write a file on build failure?

Instead of using the maven runner in Jenkin, you could execute the build as a shell script, then do something like...
mvn -q -fn clean verify || touch build_failed

I would suggest to use the configuration jenkins is capable of. Running a post-build-action in case of successful execution of the build and don't use --fail-never option.

Related

what are the proper stages for Gitlab CI/CD for a maven deploy?

I am using Gitlab CI/CD for a Java/Maven project and am confused by the many examples which show multiple stages, where each stage calls a specific Maven phase (e.g. clean, compile, test, install)
The maven documentation is very clear that each phase implicitly invokes all prior phases. So my question is, why do the examples not just invoke the last phase listed in the stages? For example, if the last non manually-invoked stage in the yml does an 'mvn install', why not just have that be the sole stage in the yml? It seems it is just a waste of CPU and time since the install will also call 'clean, compile, test, which have already all been called as part of the previous stages in the pipeline.
The "tutorials" that advice you to first call mvn compile then mvn test etc. have not understood the Maven lifecycle.
Just call one command, like mvn install for installing or mvn deploy if you want to deploy it with the help of Maven to some Maven repository.
The main reason for running different maven goals in different stages is clarity.
If a test fails and the pipeline has one job which runs mvn deploy you need to take a look at the logs why the pipeline failed.
But if a separate job exists where mvn test is executed you see at a glance that the pipeline failed because of tests.
In the example from the gitlab documentation they use cache to cache the output of mvn compile so the maven goals in the next steps don't compile from scratch but use the cache instead.

Make Jenkins Build a SUCCESS After successful Spring-boot run

I have CI system using Jenkins that automatically clones a repository,
then runs mvn clean install and then mvn spring-boot:run (using windows batch).
My problem is that the Jenkins Build does not stop even though the spring-boot:run is successful.
Is there any way to work this out?
I found a workaround for this.
I added a Build Step that executes a Windows Batch file as a child process
but before starting the batch process, I changed the BUILD_ID to something like BUILD_ID='NO_DELETE' so that Jenkins won't automatically kill it.

Using Protractor, failing test cases using maven and then maven build should fail or not?

Some of test cases are failed so due to that maven build is also failed .Just because of maven failure , Jenkins build is also failed.
So is it right or something is wrong in it?
In your Jenkins job you could run Maven with either of the following parameters:
-DskipTests=true to skip test execution entirely
-Dmaven.test.failure.ignore=true to ignore test failures
But if the tests are important (and they certainly should be :) then perhaps ignoring them (or not running them) is the wrong approach, perhaps you should instead fix the failed tests.

Maven plugin execution change Maven properties or skip build lifecycle steps

When I build my application with maven, I run mvn clean install. As a part of the install lifecycle, I run appengine:devserver_start from Google's GAE Maven plugin. This appears to be already bound to a step in the lifecycle and therefore it reruns some build steps from the beginning, even though me running mvn install did those. For example, the resources step is rerun. I had my own Java script run to download the latest resources for my build. But because of appengine:devserver_stop, I need to uselessly run this cript again because the resources step is re-executed.
I can think of two ways I can avoid this, but I'm not sure how to configure both ways. The first would be to somehow skip re-running build steps that I've already run. The other way would be to change the Maven POM properties just for the plugin execution. I have a Maven property set, either to true or false, that I can use to set the skip setting for the Java script I use during resources (because I run this script using the exec-maven-plugin). Think of this as a Maven property that can be set with the -D flag. Can I have this property changed just for the plugin?
If you are having trouble thinking about my scenario, consider what happens when you run mvn compile install. All build lifecycle steps until compile will run, then all compile steps until install will run, including compile.
A common/easy way to solve this kind of problems is to use maven profile. Just create a new profile that includes the plugin with preferred phases.
You should probably don't fight with it and just run clean appengine:devserver_start instead of clean install. Read my answer here for a more detailed explanation:
https://stackoverflow.com/a/17638442/2464295

How to conditionally run maven-release:rollback in jenkins?

I am using jenkins/hudson to make maven releases, and sometimes when the builds fails, I have no other way that manual to rollback and then start the jenkins build again. I was wondering if there is any good and configurable way of running mvn release:rollback in the end of the build dependent the result of mvn release:prepare? I mean, if the release process fails, I want to run maven release:rollback, otherwise not.
Thanks your time.
You can configure your Jenkins job to do a fresh checkout of the source code every time the job is started. So if your release fails before the creation of the release tag, you can fix the problems and just start the release again.

Resources