While trying to improve performance of my Gradle Android builds, I stumbled across the Gradle Daemon, and have been using it with great success for local builds.
However, when running under Jenkins on Ubuntu 14.04, builds are intermittently failing with:
Starting process 'Gradle Test Executor 2'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /data/var/lib/jenkins/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 2'
Successfully started process 'Gradle Test Executor 2'
Daemon vm is shutting down... The daemon has exited normally or was terminated in response to a user interrupt.
Starting process 'Gradle Test Executor 3'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /[...]/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 3'
----- End of the daemon log -----
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.
Error: Failed to run test (./gradlew --console=plain --info test -p myproject).
FAILURE: Build failed with an exception.
Multiple builds may be running in parallel. If I run a build manually when no other builds are running, I haven't been able to reproduce it. Someone else had this problem, but the recommended solution was just to disable the Gradle Daemon, which I don't want to do. I would think that a large, concurrent build environment would be exactly what Gradle Daemon was intended to optimize.
Or, if I can't make the Gradle Daemon work reliably under Jenkins, why not? Thanks!
The Gradle Daemon is enabled by default since version 3.0. However, the official documentation until 4.2.1 stated that you shouldn't use the daemon in continuous integration servers.
It is recommended that the Daemon is used in all developer environments. It is recommend to disable the Daemon for Continuous Integration and build server environments.
The Daemon enables faster builds, which is particularly important when a human is sitting in front of the build. For CI builds, stability and predictability is of utmost importance. Using a fresh runtime (i.e. process) for each build is more reliable as the runtime is completely isolated from previous builds.
This recommendations has changed since then, see Disabling the Daemon
Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.
Related
i'm looking for some assistance in execution of Jmeter distributed test runs using Jenkins hosted on Windows platform.
I need to know how to
Start Jmeter master/slave agents (jmeter-server.bat) from Jenkins machine.
how to stop the above process once the test run completes.
A hint: if you don't "stop the above process once the test run completes" you won't have to "start" them.
If you want to control everything from Jenkins you need to install Jenkins agent process on each machine you intend to use as JMeter slave, see Step by step guide to set up master and agent machines on Windows Jenkins wiki page for more details.
Once done you can create a job which will start JMeter processes using simple "Execute windows batch command" step on the agent machines
With regards to your point 2 - it's sufficient to set server.exitaftertest JMeter property to true on slave machines in any convenient way, i.e. by adding -J command-line argument like:
jmeter-server.bat -Jserver.exitaftertest=true
For any Distributed Load Run via Jmeter, the pre-requisite is to get the Jmeter-server.bat running to support and enable master-slave communications by Jmeter between Load agents. Initially i had a struggle how to get this executed as first step in Jenkins and then followed execution of Jmeter commands for load test using Remote distributed run. Hence instead of running the pre-requisite condition of running Jmeter-server.bat from jenkins i made it as a Windows service (as load agents are windows machines) which is running all time and whenever Load test starts from Jenkins, the Jmeter-server running in background which will allow distributed run to go.
I'm running a java test suite on a windows jenkins agent with gradle
When it's running, the jenkins master is reporting this
Starting a Gradle Daemon, 84 busy and 2 stopped Daemons could not be reused, use --status for details
Here's the command it's running
cmd.exe /C "C:\development\jenkins\apppath\gradlew.bat -DenvName=testserver -DenvDriver=ie -PenvName=testserver -PenvDriver=ie regression && exit %%ERRORLEVEL%%"
The number of busy gradle daemons keeps increasing, and I think is affecting the performance of the tests, they keep taking longer and longer.
If I go onto the windows slave and run
C:\development\jenkins\apppath\gradlew.bat --status
It shows as 0 gradle daemons running or busy.
I need to be able to stop all those busy daemons.
Anyone got any ideas how to achieve this?
I've tried restarting the jenkins agent and the master, to no avail.
I've also tried running the following command on the windows agent, still no luck
WMIC PROCESS where "Name like 'java%' AND CommandLine like '%GradleDaemon%'" Call Terminate
I was able to install and run jenkins on my linux subsystem in Windows 10.
It listens on 8082.
But unfortunately, for an unknown reason, it hangs up infinitely after a few minutes (or to be precise after a I've made a change in a job config and execute a build).
Then, I checked in the terminal:
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
root#jup1t3r /h/navds# service jenkins stop
Correct java version found
* Stopping Jenkins Automation Server jenkins
...done.
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
So there is no way to stop Jenkins. How can I restart it ?
The session logging we have in {{/etc/profile}} can interfere with services that launch sub-shells as new users - specifically, it always launches an interactive terminal, regardless of the context, which can cause certain key processes (e.g. Jenkins) from being able to perform critical tasks.
We had a Jenkins version upgrade and after hte upgrade, Jenkins seems to not be able to restart. Here’s what’s happening
```ubuntu#hoatname:~$ sudo service jenkins status
Correct java version found
Jenkins Automation Server is not running
ubuntu#hostname:~$ sudo service jenkins start
Correct java version found
Starting Jenkins Automation Server jenkins jenkins#hostname:~$
jenkins#hostname:~$
jenkins#hostname:~$ sudo service jenkins status
[sudo] password for jenkins:
jenkins#hostname:~$ exit
exit
[fail]
ubuntu#hostname:~$
```
Essentially, it seems that “service jenkins start” is somehow causing a session to be created, which dumps it into a script. I suspect this is due to how /etc/profile contains a script-based session logger, and i suspect that Jenkins is attempting to execute this script when it su’s into its own jenkins user
What should I do to alleviate this?
How can I auto-deploy Play Framework (2.4) application with Jenkins locally on the same server Jenkins is running? At some point we're going to set up a proper production environment separately and will probably implement test environment(s) in the same way but at this point I'd like to check out whether it is possible to set up a simple test environment to the same server Jenkins is running.
I have a Jenkins job running tests and it seems to work OK. Basically "Execute shell" running activator commands (that could be combined to one line).
./activator clean
./activator test
With Play 1 I've used play start & play stop for similar things. Trying activator start on my dev env, I get the message:
The start command is deprecated, and will be removed in a future version of Play.
To run Play in production mode, run 'stage' instead, and then execute the generated start script in target/universal/stage/bin.
To test your application using production mode, run 'testProd' instead.
So I evaluated two (incomplete) alternatives with "Execute shell" & stage:
Stage & run with nohup:
./activator clean
./activator stage
nohup target/universal/stage/bin/my-app -Dplay.evolutions.db.default.autoApply=true
-> application started OK but the Jenkins task did not stop.
Stage & run with nohup on background:
./activator clean
./activator stage
nohup target/universal/stage/bin/my-app -Dplay.evolutions.db.default.autoApply=true &
-> application seems to have started to some point but did not keep on running?
What would be the preferred (or even only working) way here?
For the particular case I ended up using Docker:
Installed Docker to the server
Created a Dockerfile based on play-docker-ci
Configured Jenkins to
build Docker image
stop existing container if running, remove existing container if exists
run Docker image
and this seems to work pretty nicely so far.
Jenkins kills all its child processes when build finishes to avoid memory leaks, thus there is no app running. The easiest way to setup jenkins with Playframework 2.4 is to use sbt tasks and sbt plugin. If you want to perform a release from jenkins, the best way would be to build debian package and install it using jenkins shell - no process would be killed. See release plugin.
I set this up by having Team City generate a startup.sh script that contains the command to start up the Play server as a background process:
nohup /pathToApp/bin/app_name -Dhttp.port=8180 &
Then the next build step just runs this shell script and starts it up. The nohup and & make this run as a background process and when the build server disconnects it will keep running. I cut out a lot of extra stuff from the startup script for clarity sake, but you can just add whatever startup parameters you want to use for your application.