Sorry, for the confusing title. I am totally new to Jenkins and have been handed over Jenkins to maintain which was set-up by someone else.
This is Jenkins Master slave config. I have 1 Master and 3 Slaves.
When I create a new job by "copying an existing" job, the new job works fine and no issues.
QUESTION: I see that in Jenkins workspace, this new job is creating a folder with the name of the original job that it was copied from. Why it is not creating a folder with the name of the new job instead?
Now, this is certainly not a show stopper for me, but it seems that Jenkins is creating a folder in workspace for each job that is run. And hence this particular folder is causing some confusion (although notional it is).
Hence, could you help me find out why the new job is creating a workspace folder with the name of original job it was copied from.
BTW, above issue was seen on the Jenkins slave.
It can be solved by configuring the correct building workspace in jenkins job.
General > Advanced > custom workspace > "give your correct workspace"
I had the same problem:
copied some jenkins project and wondered about hard coded workspace paths
Console output of the copied project. Job failed due to missing D: drive.
12:30:44 java.io.IOException: Failed to mkdirs: D:\TEAMS\WORKSPACE\RELEASE_1_1
The problem i had: the 'Advanced project options' were not expanded and the configure GUI had an enormous width, that i didn´t see the button to expand and show the 'advanced' settings.
In fact (thanks to sti): the original project had some hard coded workspace path.
One possibility is that you accidentally triggered the wrong job. You could change the job to print the directory where it executes by adding something like:
echo "XXX $JOB_NAME running in directory $WORKSPACE"
into the build step script. Then look for XXX in the build console log.
Second possibility is that you found an old workspace of the original job. Jenkins leaves workspaces lying around just in case it needs them again so it does not have to make them from scratch.
Third possibility is the original job is configured to use a hard-coded path as workspace. (Custom workspace). If you clone such a job, it would be a good idea to change the hard-coded path. An even better idea would be to let Jenkins manage the workspace and it's naming.
And finally, if all the other possibilities have been checked, you may have found a bug. You could look for it in https://issues.jenkins-ci.org/ and create a bug report if it is a new one.
Related
I am confused on how to move the "Build Record Root Directory". Right now this is my configuration:
So on disk, for a multibranch pipline it looks like this:
Workspace:
Jobs:
So for my job "WindToolsService" the configuration ${ITEM_ROOTDIR}/builds results in the following path:
C:\Jenkins\jobs\WindToolsService\branches\develop\builds
Now I want to move the entire C:\Jenkins\jobs directory to a new disk, what is the correct setting to use?
We have tried the following but it didn't work, the C:\Jenkins\jobs folder was recreated when I tried a build a job.
Copy the contents of “C:\Jenkins\jobs” to “E:\builds”
Rename “C:\Jenkins\jobs” to “C:\Jenkins\jobs_temp” to make sure new setting works
Restart Jenkins
What am I missing here?
Update
Ok - this is not really possible, at least the way I want to do it.
The original path structure is : C:\Jenkins\jobs\JOBNAME\branches\BRANCHNAME\builds but the new path is E:\builds\JOBNAME\BRANCHNAME\builds. This mean I cant just change the setting and cut and paste the contents of the jobs folder, the directory structure is different. Also the jobs folder contains other job information apart from the build records.
I would be cleaner and easier just to move the entire jenkins installation
The jobs folder contains some other information besides the build history, for example it contains the actual job definition (more info here). Additionally the option Build Record Root Directory only affects the builds located in the job folder. So, you will need to keep the jobs folder and all the sub-folders for the jobs (but not the builds folder in all the job folders).
Apparently Jenkins expands the variables ITEM_FULL_NAME and ITEM_ROOTDIR differently. This means that it's not a simple matter of copying the jobs folder to the new location, especially when you use multibranch pipelines, matrix jobs, organisation folders or normal folders. For more info see discussion in comments
Anyway, with that in mind, here is an updated answer (old one is below):
Since it isn't straight forward as copying a folder, the folder structure needs to be transformed, this means that it is best to let Jenkins do the move. The following groovy script will move the builds folders to the correct place by expanding the different macros. The script is executed in the Script Console (Manage Jenkins -> Script Console). Change the newRootBuildsFolder to what ever location you need to move to.
newRootBuildsFolder = new File("E:\builds")
def visitJob(job) {
if (job instanceof Job) {
def oldBuildsFolder = job.getBuildDir()
def newBuildsFolder = new File(newRootBuildsFolder, Jenkins.expandVariablesForDirectory('${ITEM_FULL_NAME}', job.getFullName(), job.getRootDir().getPath()))
new FilePath(oldBuildsFolder).copyRecursiveTo("**", new FilePath(newBuildsFolder))
}
if (job instanceof ItemGroup) {
for (item in job.getItems()) {
visitJob(item)
}
}
}
visitJob(Jenkins.instance)
println "Done"
Please note that this may take several minutes or hours if the instance is big with loads with build history. You can monitor the progress of the script through the file system, i.e. go to the new builds folder and check which jobs has been moved.
After this script has been executed, the builds folder will need to be update in the Jenkins configuration;
Go to Manage Jenkins -> Configure System and change Build Record Root Directory to E:\builds\${ITEM_FULL_NAME}\builds
Restart Jenkins
OLD ANSWER:
Now, with that in mind, the following should work:
Wait until no builds are ongoing, and prevent new builds from starting during the remainder of these procedures.
Copy the contents of C:\jenkins\jobs to E:\builds.
Go to Manage Jenkins -> Configure System and change Build Record Root Directory to E:\builds\${ITEM_FULL_NAME}\builds
Restart Jenkins
Start a new build and ensure that the new build information is written to the folder under E:\builds\. E.g. if we have the job X and previous build was 123, then when we start a new build for X, build 124, then the folder E:\builds\X\builds\124 should be created, and the folder C:\jenkins\jobs\X\builds\124 should not be created.
Later on, when you see that all is working when, then you can delete the old builds folders under C:\jenkins\jobs\**\.
I wonder if it is possible to remove only one build (including artifacts) from job workspace.
I tried to "Delete Build" in Build History but all it does is remove build reference from Build History table. I know I can ssh to a server and delete files from the command line but I am looking for a way to do it from Jenkins web interface.
After installing Workspace Cleanup Plugin I am able to wipe out current workspace but I want to keep my other builds in the workspace.
In your Jenkins instance, to be able to have folder/per build - set flag "Use custom workspace" in your job's settings. Here is a brief help info from the setting description:
For each job on Jenkins, Jenkins allocates a unique "workspace directory."
This is the directory where the code is checked out and builds happen.
Normally you should let Jenkins allocate and clean up workspace directories,
but in several situations this is problematic, and in such case, this option
lets you specify the workspace location manually.
One such situation is where paths are hard-coded and the code needs to be
built on a specific location. While there's no doubt that such a build is
not ideal, this option allows you to get going in such a situation.
...
And your custom directory path would look like this:
workspace\$JOB_NAME\$BUILD_NUMBER ~> workspace\my-job-name\123
where $JOB_NAME will be "my-job-name" and $BUILD_NUMBER is the build number, eq. "123".
There is one nasty problem with this approach and this is why I wouldn't recommend to use it - Jenkins will not be able to reclaim disk space for outdated builds. You would have to handle cleanup of outdated builds manually and it is a lot of hassle.
Alternative approach, that gives you more control, tools and is able to keep disk space usage under control (without your supervision) is to use default workspace settings and archive your build output (files, original source code, libraries and etc.) as a post-build action. Very-very handy and gives you access to a whole bunch of great tools like, Copy Artifact Plugin or ArtifactDeployer Plugin in other jobs.
Hope that info helps you make a decision that fits your needs best.
I also use "General/Advanced/Use custom workspace" (as in #pabloduo's answer) on a Windows machine with something like:
C:\${JOB_NAME}\${BUILD_NUMBER}
Just wanted to add a solution for getting rid of the build job's workspaces.
I use Groovy Events Listener Plugin for this.
Using the plug-in's standard configuration I just use the following Groovy script:
if (event == Event.JOB_DELETED){
new File(env.WORKSPACE).deleteDir()
}
And now the custom workspace is deleted when the build job is deleted.
Just be aware that this would also delete non-custom workspaces (because the event is triggered for all jobs on your Jenkins server).
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'm using Jenkins to do nightly build of an iOS static framework. The output that I care about is in this directory:
ios/build/Release-iphoneuniversal/MySpecialProject.framework
I'd like to use the "Archive the artifacts" action to archive "MySpecialProject.framework", but when I do this, it creates a whole archive with the entire leading directory structure. The docs say to look at how Ant does this. I'm not familiar with Ant, so I'm at a loss here.
The main point of this is to make the "MySpecialProject.framework" available as as artifact to other projects being built with Jenkins. So, thinking that I could use the "Copy Artifact" plugin to do that. But I can't really get past this thing where it creates a full directory structure here. I just wan "MySpecialProject.framework" to be the top-level artifact.
Thanks in advance.
I fixed my own problem, by putting in an "Execute Shell" command:
mv ios/build/Release-iphoneuniversal/MySpecialProject.framework .
Then in the post-build action, "Archive the artifacts", I was able to just archive "MySpecialProject.framework/**"
This seems to work quite well. Since each time Jenkins runs the job, it creates a new workspace, I don't have to worry about issues with "mv". Works fine.
I am new to Jenkins and just started configuring it. This is what i have done till now:
Installed and configured Jenkins to display the home page. Added PMD plugin.
Set the HUDSON_HOME to a specific directory > C:\Work\Jenkins
Configured a test build to run a simple do-nothing ant script. It runs successfully
Written an independent pmdbuild.xml to run checks on a set of files in C:\myview (I am using clearcase). This xml also copies the output pmd_results.xml to the workspace directory in $HUDSON_HOME/[job-name]/workspace
Now I added the pmdbuild.xml as a step in my primary build. So my build has 2 steps:
a. Run a simple script, do-nothing.
b. Run pmdbuild.xml which generate pmd_results.xml and place it in $HUDSON_HOME/[job-name]/workspace (HARD-CODED as Jenkins PMD plugin expects the file there)
Jenkins picks up the pmd_results.xml automatically with the plugin and displays warnings and everything.
Now the problem:
If I click on a filename in the PMD results, it gives a filenotfound exception as it is looking for the source file in $HUDSON_HOME/[job-name]/workspace.
My java code files are placed in C:\myview (a clearcase snapshot view)
My question is, do I need all my code files to be present inside $HUDSON_HOME/[job-name]/workspace ?? Meaning can't I tell Jenkins to look for the PMD input files in C:\myview or any other directory instead of $HUDSON_HOME/[job-name]/workspace ??
Sorry for the extremely long description.
Jenkins expects that all the code is in the workspace. Usually Jenkins is used to check out a copy of the code into the workspace, and then runs all build steps on the Sources in the Workspace.
Might seem restraining at first, but it saves you a lot of trouble if you need to move Jenkins to another server, or create a slave instance.
So I would suggest you let Jenkins check out your code (there should be a clearcase plugin) into the workspace, and run the analysis on the checked out code.
If there are compelling reasons why your code has to stay where it is (C:\myview in your case) you can still set the workspace of your build to that directory (find this in the job configuration page, you need to click on the 'extended' button to see the option).