Grails dies in the middle of Jenkins jobs after update

If you have upgraded recently and facing problem when job suddenly dies in the middle of test execution, like:

19:20:39  | Running 277 unit tests... 156 of 277
19:20:53  Build step 'Execute shell' marked build as failure
19:20:54  Description set: 

Most probably it is because since version 2.2 test-app, run-app, run-war runs in fork mode and Jenkins has some fancy zombie process detection that kills spawned processes it does not like.
Quick solution is to disable fork in test environment or you can refer my previous post about hiding such processes.

Jenkins kills Tomcat or other Java process after job ends

Recently, I was adding new application deployment to Tomcat server that was started by Jenkins. Process was starting nicely, but was stopping at the end of the job. The only clue was log record:

Service exit with a return value of 143

This issue can be easily solved by adding -Xrs to JAVA_OPTS. Option description can be found at http://docs.oracle.com/javase/6/docs/technotes/tools/windows/java.html.

Setting PATH for Jenkins slave agent

There is a lot of variables and settings available for Jenkins slave agents, but for some reason nothing worked for PATH in my case. Finally, the only configuration that did the job, was to set PATH in user's home .bashrc (.profile, profile, .bash_profile, etc. was not working) on slave node, like:

  PATH=$PATH:/opt/phantomjs-1.9.1-linux-x86_64/bin/

Run background java process from Jenkins

Jenkins is using mechanism to detect spawned processes and kill them after finishing job, so if you will just start such ad-hoc background daemon process, Jenkins will kill it with warning:

Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information

Fortunately, there is easy hack to tell Jenkins ignore such process, just create fake BUILD_ID and start your application, for example, this can be entered into Execute shell build step:

BUILD_ID=dontKillMe nohup java -jar test.jar &

Warning is still there, but process should be fine and running. There is more about it here.

How to kill Tomcat server running from standalone plugin

I have demo application which is running from Grails standalone plugin and wanted to automate deployment from Jenkins. Starting such application is well documented and easy, but there is nothing about stopping it.
After quick digging plugin's code, I found that it has undocumented feature to do it. It creates server on application server port + 1, and as soon as there is connection - shuts server. So if your server port is 8080, this command from same computer will kill server:

telnet localhost 8081

Running several Grails projects in parallel

If it is needed to run several Grails commands simultaneously (for example on Jenkins) there is big change to get exception like:

19:52:24    [groovyc] org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
19:52:24    [groovyc] /var/lib/jenkins/jobs/test/workspace/src/groovy/com/test/SomeUserDetails.groovy: 3: unable to resolve class org.codehaus.groovy.grails.plugins.springsecurity.GrailsUser

This happens because Grails stores plugin classes and other files in user home directory, so for example, parallel task cleans workspace while other task is running, latter is in trouble of not finding some plugin stuff.
Fortunately, this is easy to solve by specifying working directory for every specific command. There is special property called grails.project.work.dir which can be specified on command line, for example like:

grails -Dgrails.project.work.dir=/home/jenkins/job1/ clean --non-interactive

Resolve JIRA issue after Jenkins build using API

This summary is not available. Please click here to view the post.

Passing upstream parameters to downstream builds in Jenkins

Jenkins has cool Pipeline plugin, which helps to create build pipelines, that for example, can organize and visualize deployment process. Plugin is very cool and looks great, but lacks few basic features, like passing generated parameters or variables from upstream builds to downstream.
For example, I wanted to pass SVN revision number into downstream builds.
Fortunately it is easy to do it with little hacking. Here is what I did.

1. Add Groovy plugin.
2. Add new build step Execute system Groovy script, now it is possible to hook into Jenkins internals.
3. Then just add Groovy script there:

import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable
build.addAction(new ParametersAction(new StringParameterValue('SVN_UPSTREAM', build.getEnvVars()['SVN_REVISION'])))

What this script does it just creates new parameter and adds SVN_REVISION from environment variables there. And pipeline can pass parameters with this mechanism to downstream builds (all of them).
Easy!