I have the latest stable release of Jenkins 2.121.1 installed on my Windows10Pro(x64)-build machine.
Problem no 1:
I can't find the system-wide workspace settings as shown for instance in this thread:
How to change workspace and build record Root Directory on Jenkins?
Has this been removed? I only have the workspace settings available for the specific jobs, but I would like to change it on a system-wide-level.
Problem no 2:
When I configure the custom work space for a specific job like so:
It is supposed to use the name for the item that I've created. Instead it LITERALLY creates a folder with this name, like so:
Even though the jenkins documentation says I should use "${ITEM_FULL_NAME}", I've tried different variants (ITEM_FULLNAME) etc.
It looks like a bug
They mention Under the Advance Tab but I don't find it anywhere either.
Workaround
Modify the jenkins.xml directly
from
<env name="JENKINS_HOME" value="%BASE%"/>
to
<env name="JENKINS_HOME" value="newPath\Jenkins"/>
Considering the 2nd issue you can modify the config.xml
Or
You can set the env variable when you start the jenkins.war
SET JENKINS_HOME=new\Path\directory
SET ITEM_ROOTDIR=new\root\directory
java -jar jenkins.war
You will have to do this each time you start and stop the services
Related
I'm just starting with Jenkins. I'm trying to set JBoss Management Builder (unless I do not need this plugin to control deployment on WildFly?) and Jenkins do not want to accept my JBOSS_HOME dir.
My home dir is:
/home/opt/wildfly-10.1.0.Final/
I have also tried:
/home/opt/wildfly-10.1.0.Final/bin/
/home/opt/wildfly-10.1.0.Final/standalone/
/home/opt/wildfly-10.1.0.Final/standalone/configuration/
/home/opt/wildfly-10.1.0.Final/standalone/configuration/standalone.xml
All of this tries have ended with an error:
"It's not look like correct JBoss home directory"
I think it's unlikely that the JBoss Management Builder plugin will work with Wildfly.
Its latest release is from 2011 as written on the plugin page. Plus the source code where the error is coming from is looking for two folders explicitly in your JBOSS_HOME: "bin" and "server". And "server" is just not there in Wildfly.
I think you have to find other ways to interact with Wildfly.
I upgraded Jenkins today from 1.618 to 2.3. This included installing a whole bunch of plugins that it recommended (Mostly Pipeline plugins and their dependencies).
Since the upgrade, I get a new error (or, at least, a new unwanted behavior) any time a job kicks off another job. Any values passed to the child as "Predefined parameters" are ignored unless the child job already has those keys defined.
Let me illustrate: Let's say that I have a parent job and a child job.
Parent launches child through a "Trigger parameterized build on other projects" Post-build Action. In the definition of that Post-build Action, under the "Predefined parameters", I have FOO=BAR defined.
In Jenkins 1.618, when child was triggered this way, it would have FOO set as a parameter, with a value of BAR.
But in 2.3, FOO is not set on that build of child.
If I modify child so that FOO is always a parameter of that job, it will then pick up the FOO=BAR set from parent. This is an unacceptable work-around because we pass dozens of parameters this way, and defining them on both ends is too fragile and violates the "don't repeat yourself" principle.
I get the same results whether I'm triggering the child job through through the "Trigger parameterized build on other projects" Post-build Action or through a MultiJob Phase of a MultiJob project.
Is this an intended change? Was it broken before, and we were just using it incorrectly? Or is this a bug?
According to Jenkins 2 Security updates, you can bypass it by setting:
hudson.model.ParametersAction.keepUndefinedParameters=true
To validate this workaround, go to Manage Jenkins -> Script Console, and run:
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
To make it permanent, change Jenkins arguments as follow (and restart Jenkins afterwards):
On Windows edit jenkins.xml in Jenkins home directory, for example:
<arguments>
-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle
-Dhudson.model.ParametersAction.keepUndefinedParameters=true
-jar "%BASE%\jenkins.war" --httpPort=8080
</arguments>
For most of the Linux distributions, you can modify JENKINS_ARGS inside file:
/etc/default/jenkins (or jenkins-oc)
For CentOS, modify JENKINS_JAVA_OPTIONS inside file:
/etc/sysconfig/jenkins (or jenkins-oc)
Here's a list of reported plugins, that were affected by the issue, and has an open bug already:
https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170
There are some solutions
commabd line
java -Dhudson.model.ParametersAction.keepUndefinedParameters=true -jar jenkins.war
groovy
import jenkins.model.*;
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
I couldn't find a Start-to-End answer on how to set this for a linux box. After a couple hours of cross-referencing guides, this is what ended up working. There are supposed to be a couple flavors of these Jenkins configurations. I'm using the Ubuntu flavor for this answer.
Get the Groovy scripting plugin
Discern where your $JENKINS_HOME is being set. By default, it's supposed to be at ~/.jenkins, but I didn't set this server up, so I had to go digging through some configuration files. In case you do too, this is what I had to do:
Check the contents of /etc/default/jenkins with vi to grab the value of $JENKINS_HOME -- mine was /var/lib/$NAME and further up the file, $NAME was set to jenkins, so it was /etc/libs/jenkins
Change directories to the $JENKINS_HOME path
Search for a directory called init.groovy.d -- if it doesn't exist, make one and then cd into it. You might have to use sudo if needing to make it
Create a new file in the init.groovy.d directory that ends in .groovy -- I just called mine params.groovy
Enter following script code into the groovy file we just made:
import jenkins.model.*;
System.setProperty("hudson.model.ParametersAction.keepUndefinedParameters", "true")
Save and Close, then reboot your Jenkins server.
That should unblock you, if you ran into the same problem I did. Your mileage may vary :) I ultimately used a start-up script to utilize that functionality in conjunction with this solution proposed by Jenkins.
I have a number of Gradle builds that work very well from the command line, from buildship, etc.
However now I am porting them to a Jenkins system. And it is producing some very strange results. I'm pretty much a total newbie to Jenkins, so this may have an easy answer. So far I haven't found it.
I am using the Gradle Plugin for Jenkins, v.1.24 to configure my build in Jenkins. However, Jenkins (at least as I have it configured) organizes its build structure as {jenkins root}/data/jobs/{project_name}/workspace. When code is checked out of source control it is deposited in that directory, not in a directory named {project_name}.
Gradle seems to assume that the directory in which it is running names the project, and when I'm running outside of Jenkins this assumption is true. The name of the project that Gradle sees is the name of the project that was checked out from source control. Project.name is a gettable but not a settable property of a gradle Project. So in the Jenkins case, the archives that gradle builds are named workspace* rather than {project_name}*. It is also named workspace in the repositories it publishes into. I must be missing something very obvious but for the life of me I cannot figure out what it is.
Has anyone grappled with this?
UPDATE - It appears that the problem is that the people who designed my Jenkins instance knew nothing about Gradle. The {jenkins root}/data/jobs/{project_name}/workspace layout that I described above is not required by Jenkins, but apparently was felt to be useful for some reason in some other, non-Gradle context. So the question becomes, where is the project layout set up in the Jenkins configuration - OR - can Gradle be modified somehow to assume a different project layout/naming strategy.
Set Manage Jenkins → Configure System → Advanced... (the one right at the top) → Workspace Root Directory: ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}.
The inline help:
Specify where Jenkins would store job workspaces on the master node. (It has no effect on builds run on slaves.) This value can include the following variables.
${JENKINS_HOME} — Jenkins home directory.
${ITEM_ROOTDIR} — Root directory of a job for which the default workspace is allocated.
${ITEM_FULL_NAME} — '/'-separated job name, like "foo/bar".
Changing this value allows you to put workspaces on SSD, SCSI, or even ram disks. Default value is ${ITEM_ROOTDIR}/workspace.
.../jenkins/config.xml
...
<workspaceDir>${JENKINS_HOME}/workspace/${ITEM_FULLNAME}</workspaceDir>
...
Gradle seems to assume that the directory in which it is running names the project
Yes this is gradle's default behavior, but can be easily overridden. If it is just the output artifact name you're concerned about, override the jar name with:
jar{
baseName 'actualProjectName'
}
I would like Jenkins' data to be written to drive "E:" since this is the large drive on the server. Jenkins itself is installed on "C:".
How do I do that?
The default configuration that I saw is:
Workspace Root Directory: ${ITEM_ROOTDIR}/workspace
Build Record Root Directory: ${ITEM_ROOTDIR}/builds
Will the following changes help me achieve what I need?
Workspace Root Directory: E:/Jenkins/workspace
Build Record Root Directory: E:/Jenkins/builds/${ITEM_FULL_NAME}
In addition, what does "${ITEM_FULL_NAME}" mean?
I figured it out.
In order to save your Jenkins data on other drive you'll need to do the following:
Workspace Root Directory: E:\Jenkins\${ITEM_FULL_NAME}\workspace
Build Record Root Directory: E:\Jenkins\${ITEM_FULL_NAME}\builds
You can modify the path on the config.xml file in the default directory
<projectNamingStrategy class="jenkins.model.ProjectNamingStrategy$DefaultProjectNamingStrategy"/>
<workspaceDir>D:/Workspace/${ITEM_FULL_NAME}</workspaceDir>
<buildsDir>D:/Logs/${ITEM_ROOTDIR}/Build</buildsDir>
EDIT: Per other comments, the "Advanced..." button appears to have been removed in more recent versions of Jenkins. If your version doesn't have it, see knorx's answer.
I had the same problem, and even after finding this old pull request I still had trouble finding where to specify the Workspace Root Directory or Build Record Root Directory at the system level, versus specifying a custom workspace for each job.
To set these:
Navigate to Jenkins -> Manage Jenkins -> Configure System
Right at the top, under Home directory, click the Advanced... button:
Now the fields for Workspace Root Directory and Build Record Root Directory appear:
The information that appears if you click the help bubbles to the left of each option is very instructive. In particular (from the Workspace Root Directory help):
This value may include the following variables:
${JENKINS_HOME} — Absolute path of the Jenkins home directory
${ITEM_ROOTDIR} — Absolute path of the directory where Jenkins stores the configuration and related metadata for a given job
${ITEM_FULL_NAME} — The full name of a given job, which may be slash-separated, e.g. foo/bar for the job bar in folder foo
The value should normally include ${ITEM_ROOTDIR} or ${ITEM_FULL_NAME}, otherwise different jobs will end up sharing the same workspace.
The variables you need are explained here in the jenkins wiki: https://wiki.jenkins.io/display/JENKINS/Features+controlled+by+system+properties
The default variable ITEM_ROOTDIR points to a directory inside the jenkins installation. As you already found out you need:
Workspace Root Directory:
E:/myJenkinsRootFolderOnE/${ITEM_FULL_NAME}/workspace
Build Record Root Directory: E:/myJenkinsRootFolderOnE/${ITEM_FULL_NAME}/builds
You need to achieve this through config.xml nowerdays. Citing from the wiki page linked above:
This used to be a UI setting, but was removed in 2.119 as it did not
support migration of existing build records and could lead to
build-related errors until restart.
I would suggest editing the /etc/default/jenkins
vi /etc/default/jenkins
And changing the $JENKINS_HOME variable (around line 23) to
JENKINS_HOME=/home/jenkins
Then restart the Jenkins with usual
/etc/init.d/jenkins start
Cheers!
You can also edit the config.xml file in your JENKINS_HOME directory.
Use c32hedge's response as a reference and set the workspace location to whatever you want between the tags
By default, Jenkins stores all of its data in this directory on the file system.
There are a few ways to change the Jenkins home directory:
Edit the JENKINS_HOME variable in your Jenkins configuration file (e.g. /etc/sysconfig/jenkins on Red Hat Linux).
Use your web container's admin tool to set the JENKINS_HOME environment variable.
Set the environment variable JENKINS_HOME before launching your web container, or before launching Jenkins directly from the WAR file.
Set the JENKINS_HOME Java system property when launching your web container, or when launching Jenkins directly from the WAR file.
Modify web.xml in jenkins.war (or its expanded image in your web container). This is not recommended.
This value cannot be changed while Jenkins is running.
It is shown here to help you ensure that your configuration is taking effect.
If you go into Configure under Home there is a "Help" note on how to:
Home directory /var/lib/jenkins Help for feature: Home directory
By default, Jenkins stores all of its data in this directory on the file system.
There are a few ways to change the Jenkins home directory:
Edit the JENKINS_HOME variable in your Jenkins configuration file (e.g. /etc/sysconfig/jenkins on Red Hat Linux).
Use your web container's admin tool to set the JENKINS_HOME environment variable.
Set the environment variable JENKINS_HOME before launching your web container, or before launching Jenkins directly from the WAR file.
Set the JENKINS_HOME Java system property when launching your web container, or when launching Jenkins directly from the WAR file.
Modify web.xml in jenkins.war (or its expanded image in your web container). This is not recommended.
This value cannot be changed while Jenkins is running.
It is shown here to help you ensure that your configuration is taking effect.
def finder = new FileNameFinder()
def files = finder.getFileNames '\\pkg\\stage\\', '*.sln'
echo "$files"
jenkins is serching file in /var/lib/jenkins/pkg/stage
it is automatically adding /var/lib/jenkins path before
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/