I'm trying to run a build task with Gradle on Jenkins, but Gradle fails to run.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Parameter -Xmx2048m is apparently used in Java to run Gradle process.
If this parameter is the problem, where should I change it? (Jenkins is configured for -Xmx1024m). I'm running it on device with 1GB RAM (about 700 - 500MB free before running the task).
Full log: http://pastebin.com/BBsjp5pZ
I had to modify gradle.properties file in project folder
Original settings:
org.gradle.jvmargs=-Xmx2048m
New settings:
org.gradle.jvmargs=-Xmx512m -Xms100m
References:
Where should I put gradle.properties in Jenkins
https://docs.gradle.org/current/userguide/build_environment.html
The Jenkins manual talks about "GRADLE_OPTS".
Gradle build steps You can set the -Xmx or -XX:MaxPermSize by adding a
GRADLE_OPTS global environment variable in the Jenkins global
configuration. To do this, click Manage Jenkins, then Configure
System. In the Global properties section, click the Environment
Variables checkbox, then add a new environment variable called
GRADLE_OPTS with the value set appropriately, similar to the screen
shot above regarding MAVEN_OPTS
Related
I try to scan Jhipster generated code with Sonarqube during a Jenkins build.
My configuration is the following:
Gitlab as Docker Container
Jenkins 2 as Docker Container
Sonarqube 5.4 (higher is not permitted with MariaDB; right?) as Docker Container
This is a fresh install and all systems are communicating together.
When running builds, Jenkins is alerting about duplicates references in the 'bower_components' repository.
WARN: Too many duplication references on file
[moduleKey=Challenge1:0.1-HENDRIX,
relative=src/main/webapp/bower_components/angular-i18n/angular-locale_vun-tz.js,
basedir=/var/jenkins_home/workspace/Challenge-1] for block at line 20.
Keep only the first 100 references.
My problem is that I do not get the reasons why is alerting about it since few exclusions have been set at different levels:
1) Within pom.xml
<sonar.exclusions>src/main/webapp/content/**/*.*, src/main/webapp/bower_components/**/*.*, target/www/**/*.*</sonar.exclusions>
2) Within Jenkinsfile
node {
...
stage 'scan'
sh "${sonarqubeScannerHome}/bin/sonar-scanner -e -Dsonar.host.url=http://sonarqube:9000 -Dsonar.projectKey=Challenge1:'0.1-HENDRIX' -Dsonar.projectName='Challenge 1' -Dsonar.projectVersion='0.1-HENDRIX' -Dsonar.sources='src/' -Dsonar.coverage.exclusions=**/bower_components/**"
}
3) On sonarqube customizing itself (Analysis Scope).
EDIT:
This "non-exclusion" was originally leading to a memory dump that I could solved by extending the memory on sonarqube (sonar.properties).
sonar.web.javaOpts=-Xmx2048m -Xms512m -XX:MaxPermSize=160m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
However, I a still am afraid that extending memory isn't the appropriate solution and I must be able to exclude some parts of code. What should I do to remove bower components from the scan analysis? (I probably made something wrong).
My mistake: I was using -Dsonar.coverage.exclusions instead of -Dsonar.global.exclusions
We have a Code Composer Studio (Eclipse) project that uses CMAKE to generate makefiles and build. The project compiles as expected when the project is manually imported onto the Jenkins slave (Win10 x64) and executed from the command line but fails when the build is handled by Jenkins. The failure always follows the same pattern: a singular letter is dropped from the path of an object file. For example, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir becomes [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir and linking fails because it cannot find the referenced object file.
I made sure that there are no differences between the account environment variables and the system environment variables and have also configured the Jenkins Service to use the admin account on the slave instead of SYSTEM in order to get rid of as many differences between Jenkins and the command line as possible.
The project will build successfully using one of our other Jenkins slaves (also Win10 x64), so we know that it's not a Windows 10 issue or a problem with our Jenkins configuration. Since I can't find any differences between the configuration of the two slave machines, I was hoping that someone might be able to suggest somewhere to look for this path issue.
I never found out why the paths to object files were being mangled, but I did get the project to build successfully on the slave via Jenkins. All I did was change all of my system environment variables into user environment variables. I copy-pasted, so I know that the variables themselves did not change.
I have no idea why this corrected this issue as I had inserted a whoami call at the beginning of the build to confirm that Jenkins is indeed running as a user and not System. I guess from this point on all of my environment variables will be specific to a user and not SYSTEM...
EDIT: The problem has returned. I have made no further progress in tracking down the cause behind this issue, but I have found that I do not see this symptom when running the scripts in a bash environment instead of a Windows command prompt. Fortunately for me the scripts have all been written in such a way that they can be run in both environments, so I have had my coworkers use bash instead for them.
Hi I need some help in overriding the user.home property of ant from Jenkins. I created a simple job on jenkins that runs a build script on a slave machine of the master. One of the tasks of the scripts is to use the user.home property of ant and access certain files. The problem is that when I try to echo this property from the command line of the slave machine, I see C:\Users\Administrator but when I run the exact the same script from the Jenkins server I see C:\ . This difference is causing the build to fail on Jenkins. Can anyone please tell me what is the reason for this difference? Is there any way I can override this?
I tried having a property called user.home in the config file of my job but it doesn't seem to pick it up. Another interesting point is that when I changed the user.home value to some gibberish in the config file and run ant from command line on the slave, it still picks it up as C:\Users\Administrator
I am using ant 1.7.1 and Jenkins 1.598
You likely have jenkins running as a different ID than Administrator. Which is a good thing.
Properties in ant are immutable so you can specify those properties from the ant plugin in jenkins and they'll override any other values. (click advanced under the invoke ant buildstep to see the properties text box).
I'd recommend you not override user.home but rather refactor your ant so there is a config.location property that defaults to user.home but can be overidden to whatever you want from jenkins. It just seems unnatural to ovrride user.home
How can I change the location where jenkins store temp data in its slaves. Currently, it shuts down the connection to my slaves because it complains about the following
Disk space is too low. Only 0.119GB left on /tmp.
I want to move the tmpdir location to something like /var/tmp/ instead of /tmp. How can I do that?
Just add "-Djava.io.tmpdir=/path/to/tmp" to the java command line options (you don't need any extra service wrapper).
Depending on your installation there might be an existing startup script and/or config file this can go into. On my fedora system, I can add the option to the /etc/sysconfig/jenkins file:
## Type: string
## Default: "-Djava.awt.headless=true"
## ServiceRestart: jenkins
#
# Options to pass to java when running Jenkins.
#
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djava.io.tmpdir=/var/tmp"
On a debian/ubuntu machine, add the following to the file /etc/default/jenkins:
# use a different tmpdir for jenkins
JAVA_ARGS="$JAVA_ARGS -Djava.io.tmpdir=/var/tmp/"
If using "SSH Slaves Plugin", you can set JVM Options in "Advanced settings" and add:
-Djava.io.tmpdir=/my/temp
You can use Java Service Wrapper.
And config your wrapper(look example)
wrapper.java.additional.2=-Djava.io.tmpdir=../tmp
Or you can create symbolic link /var/tmp folder and put on home jenkins daemon.
On a Windows agent, assuming you have set it up as a Windows service wrapping a call to Java Web start, you should see a jenkins-slave.xml file in the agent's target folder.
You can edit this file and add -Djava.io.tmpdir=D:\Whatever\folder\ in the <arguments> tag to configure the temporary folder.
E.g.
<arguments>-Xrs -Djava.io.tmpdir=D:\Temp\ -jar "%BASE%\slave.jar" -jnlpUrl http://jenkins-master-whatever/slave-agent.jnlp -secret 999999999999999999999999999999999999999999999999999999999999</arguments>
You'll need to restart the service to see your modifications at work.
Running on FreeBSD, you can configure the temp directory by adding this line to your /etc/rc.conf:
jenkins_java_opts="-Djava.io.tmpdir=/var/tmp"
When jenkins is wrapped, e.g. bootstrapped as a windows service, add the configuration to the %JENKINS_HOME%\jenkins.xml <arguments> element
or on a slave, %JENKINS_HOME%\jenkins-slave.xml
Same information as other answers but official support article from CloudBees regading JNA error on Jenkins Master (although the same applies for Jenkins Nodes):
https://support.cloudbees.com/hc/en-us/articles/215281717-Jenkins-fails-to-start-with-JNA-error
To change the temporary directory that Jenkins uses, you need to:
append -Djava.io.tmpdir=$JENKINS_HOME/tmp into JENKINS_JAVA_OPTIONS variable in either /etc/sysconfig/jenkins or /etc/default/jenkins file depending on your OS
create /var/lib/jenkins/tmp using the Unix user that runs the Jenkins process
On modern Jenkins you can use UI option in the Jenkins Configuration which is called "Override temporary dir location"
On a slave you can just add it to the slaves advanced parameter in Jenkins -Djava.io.tmpdir=/var/tmp/
I am trying to use Jenkins to compile my MSBuild project created with Delphi. I have the MSBuild plugin installed into Jenkins and configured. I'm choosing the specific configuration for my build job.
I have set all the environmental variables in Jenkins that are required by the Delphi compiler (from rsvars.bat for you Delphi types.)
The project compiles just fine on the command line. If I do it on the command line, MSBuild reports a nice big fat PATH (the correct one) as part of the command line it uses to call the Delphi compiler.
However, when I try to use it with Jenkins, the result is quite different:
C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\dcc32.exe -$D- -$L- -$Y- --no-config -B -Q -AWinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE -DRELEASE -K00400000 HTMLWriterTestApp.dpr
Embarcadero Delphi for Win32 compiler version 22.0
Copyright (c) 1983,2010 Embarcadero Technologies, Inc.
Noet the complete lack of a path, or any other information about were to find what the compiler needs. This information is there when I run from the command line.
Can anyone think of any reason why Jenkins is failing to get the correct PATH information?
Depending on how you run Jenkins, it may not have the full path line that you are used to seeing. For example, if you run Jenkins as a Windows Service and have your USERS PATH variable populated, you won't necessarily have it populated for the SYSTEM user. In this case, modify the Logon Account used by the Service to be your account, rather than a system one.
I have Jenkins running on a server inside Glassfish, running as the local system account, as it was installed, by using a derivation of this blog post, and I was able to get it to work by setting property variables in the "system configuration" (Jenkins Environment Injector Plug-in) in Jenkins. (BDS, BDSCOMMONDIR, FrameworkDir, FrameworkSDKDir etc...)
Then the trick for Delphi to pick up the appropriate path is to send the command line parameter "Win32LibraryPath" to MSBuild. Make sure to escape your double quotes in this parameter in Jenkins or else you will pull out your hair.
I had Jenkins started as windows service and it could not find an SVN command even if I had SVN\bin in my PATH variable for the System user.
It seems that the service uses only the environment variables available at start up time.
So if later on you add some more environment varibales to the Windows System user, they will not be available to the service.
All you have to do is restart the window service and it will pick the new environment variables !
Anything with git pull/ where git commands, which are not executing from Jenkins is because of the path issue in the environmental variables in Windows.
Check the PATH in Environment variables.
Check the same command executes from windows command prompt or not.
If it is executing & Windows is running as slave service, then restart the slave service from services.msc.
Log out and login back to Jenkins.