I have renamed a Jenkins Job from the Jenkins GUI. I changed the Project name in the Configure menu and hitting Save afterwards.
However the workspace name for this Jenkins job has not been changed. What I am finding is upon the job execution a new workspace is getting created with this given new name and none of the contents of the old workspace is getting copied.
So the issue is contents of the old workspace is not copied to the new workspace.
What should I do instead?
I know there are several questions in SO in this area. However those do not answer my question.
Renaming job in jenkins/hudson
Rename a job in Jenkins
So please check this before marking this question as a duplicate.
I was able to workaround this is issue using the Use custom workspace option.
To change this location, I need to choose configure job and click on the Advanced button in the Advanced Project Options section.
After opening the settings, you will find some more configuration options for your job. Look for the Use custom workspace option on the right hand side and check the box.
Reference: Jenkins: Change Workspaces and Build Directory Locations
Workspaces are volatile by nature and may reside on a build node which has gone offline, therefore your build job should not rely on files being present in the workspace. However sometimes you will benefit from a speed-up by reusing unchanged files existing in workspace and decide not to clean them.
When you start a build, a new workspace is (as you noted) created, this is the correct behaviour, you should not need to store files in your workspace between builds but set up your system to load all sources from your vcs. This way you will always be able to make a fresh build from source, there are also a few options available to clear the workspace from old files.
If you do not want to populate the workspace from a source code addon you can always use the custom shell script feature to run a few shell commands to copy the needed files.
Related
I am implementing Jenkins into already established Perforce workflow.
Each of the workspaces we have in Perforce(and there is a lot of them) is using the Drive letter( for example D:\ ) as the root directory for the workspace.
I am using p4Plugin in Jenkins to sync the code before running the actual scripts. And Jenkins has it's own workspace which is being used every time I start to sync the code.
I tried using the Spec file, for workspace behavior in P4 Plugin, where I would specify the root to be D:\ but whenever it loads it will still create jenkins workspace root.
I also tried using the Static workspace behavior, and that will work, but the problem is that in order for that workflow to work, the person needs to create a workspace manually on the worker of jenkins setup, and then create the job, which is then defeating the purpose of using jenkins at first. Plus we need a workspace per job.
Which made me think, if I use an already existing workspace with D:\ being the root, and use a Temp workspace behavior in jenkins, that it will copy the root settings as well as other ones. But unfortunatelly it also sets the sync to be to the jenkins workspace.
In short, all I want is to be able to use the D:\ drive to sync all the code instead of putting them into the jenkins root directory and syncing the code to the project folders inside.(ex C:\JenkinsData\syncProject...)
That's the design of the p4 plugin. It puts the workspace where jenkins asks us to.
See property jenkins.model.Jenkins.workspacesDir here: https://wiki.jenkins.io/display/JENKINS/Features+controlled+by+system+properties
I don't think the default in that wiki is correct.
On all your master and slaves, you can try to change that to just D:\
That assumes your client view definitions (right hand side) will not overlap.
Otherwise:
A "form-in client" trigger script can alter the root. The script should only change jenkins relevant clients, so you'll need to pass something to the script in the trigger definition to signify that it is for a jenkins job. Examples could be a client naming convention and/or the clientip.
Your Perforce Admin, if that's not you, will have to assist.
I have three builds.
Build A
Build B (cloned from A)
Build C (cloned from B)
Build A builds our entire environment, Builds B and C were cloned, but then stripped to only build specific parts and from different branches. Since doing this, we've seen the build time on Build A triple. It is running tf vc workspace /delete on every build.
Build C also deletes it's workspace, but build B does NOT. On the repository tab, all three have Clean set to false.
Is there anywhere to view/set options for the Get Sources task? What would cause one build not to do this and the other two to do it?
There are only three TFVC options in get source step of TFS build pipeline.
No any other extra option to control the get source task.
First suggest you check whether you set Clean = true in Visual Studio Build task, you need to uncheck it here.
If you do not check Clean option and the build always refreshed workspace on local build server and build agent always cleans TFVC Repository. Try this solution: completely wipe the agent directory and start again, this may fix the problem. Another way is reconfigure your build agent and trigger the build again.
Besides, you could also disable the default get source steps in the build definition. And use your own script to do the get source/pull files to bypass workspace mapping issue. How to, please follow: Is it able to ignore/disable the first step Get source in vNext Build?
I found my answer. By adding the System.debug = true I was able to get a view of the actual mappings in the workspace. Then I matched that up against a list of all the mappings in the repository of the build. What I found was that when we map a folder and one of its sub-folders as well, only the parent folder mapping is created in the workspace definition.
When Get Sources runs, it looks for a workspace name that matches and then first does a simple count check. When the number of mappings in the repository doesn't match the number of mappings in the workspace it fails out and immediately deletes and rebuilds the workspace.
By removing the sub-folder mappings, my Get Sources task dropped from 11+ minutes to seconds.
I have our Solution on CI build. That works.
When dev's check in changes, the solution builds, but only for changes to that solution.
How do I get the build definition to build on changes to OTHER folder changes outside of the solution?
Yes, I can add a workspace in the workspace sources tab. But that means all that code is downloaded on every build.
Our solution has over a dozen dependencies. I would like to trigger a build if any of those dependencies change. We don't need the dependency source code to download into the build workspace at all. That's just pointless.
Yes, we have a folder in TFS for our Nuget Packages. We check them in automatically on build (Thank you TFS).
I could just add the NugetPackage workspace to the solution's workspace list, BUT that would result in every version of every dependency getting downloaded into the build workspace.
How can I trigger a build on a change that I do NOT list in the workspaces list of the build definition?
Btw, we are using TFS 2012
I was hoping the Cloaking feature would allow for this, but if it's cloaked, the automated build does not trigger. The automated build only fires if the workspace folder is set to active. Which also means download every NugetPackage in that same folder!
It's not able to trigger a CI build on a change which not list in the workspaces list of the build definition.
A few other things to know
Make sure the folders you include in your trigger are also included in your mappings on the Repository tab(the same to
workspace mappings).
Source Link
As a workaround you could set clean workspace to false, which will not get other unchanged files every time.
If your build process does not require a clean workspace or
repository, you can significantly reduce the time that is required to
run the build setting this parameter value to False.
I am just starting with Jenkins 1.487 and wanted to integrate Jenkins in my Ant project. But while configuring it, I can't find any way to make Jenkins re-use an already checked out codebase, instead of downloading a fresh copy relative to its workspace root. Is there a way to do that ?
I tried to specify a custom workspace manually (where my codebase was already checked out), and clicked on 'Build now'. The result was that it wiped out my current checked out code saying
"Checking out a fresh workspace because there's no workspace at /home/daud/Work
Cleaning local Directory ."
Not even a warning..
If you really want to build from an existing checkout somewhere on the file system, then do not use "Source Code Management" section of Jenkins. Leave it as "none"
Go straight to the "Build" section
Click "Add Build Step"
Select Invoke Ant"
Click Advanced
And under "Build File", provide a full path to the ant build file on your file system. You would have to include the drive letter (if on Windows) or a leading / (if on Linux) to break from the Workspace (by default, this path is relative to Workspace). Or use a lot of ../../../.. if needed.
But like others have said, this is not the way a CI system is supposed to be used
The idea behind Jenkins and CI is that it works on a fresh copy of the codebase. Every build done by Jenkins should not depend on any external preconditions and it should be reproducible.
You might want to try using the Clone Workspace SCM Plugin for Jenkins. It will allow you to zip up the workspace from one job and use it to create the workspace for another one. I've used this for downstream jobs that need to act on the work from a previous job.
This is also helpful if you're using something like Git for source control and want to avoid a second Git clone (or SVN checkout). Furthermore, you can limit the content of zip file that is used to recreate the workspace, for example to avoid carrying unnecesary files (e.g. the .git or .svn directories) downstream.
I'm already finishing my project build automation :) with Hudson and Nant.
My project structure is something like
$/Project
build.scripts
script1.build
script2.build
build.properties.xml
Code
Project1
Project2
So Hudson downloads from the root $/Project to the workspace folder.
And everything is ok since the build.scripts are in the workspace, I run them very easily, however what is bugging me is the fact that since the build scripts are inside the workspace, then I can't program Hudson to run automatically either based on time or changes because it will always detect changes to the files (note build.properties.xml which I check out and check in at build time to store some stats).
Where do you recommend these files to go in and still get the advantage of having them source-controlled?
What I ended up doing is to NOT check-in changes to those files. I changed my CI workflow to create another file (local to the workspace only) where the changes are written to.
This way, I still get the last build info written somewhere to pick it up, and avoid the issue of Jenkins detecting the change.
PS: I changed from Hudson to Jenkins since I saw that most plugins ran away from the former. The transition was too smooth to be true.