I have a Jenkins multi-configuration project that I want to build on two slaves (Slave-1 and Slave-2) which are located on two different VM's. I am having a problem with how Jenkins attempts to create different workspaces for each slave. I want to use the same workspace path on each VM.
I am getting my project files from Perforce and want to put them in the directory c:\workspace on both VM's. However when I run a build, I look on the VM that has Slave-1 and it stores the project files under:
c:\workspace\label\Slave-1
On the other VM the project files is under:
c:\workspace\label\Slave-2
The folder 'label' under c:\workspace was the slave name I input for the configuration matrix.
How do I override Jenkins to put my project files under c:\workspace on each VM (without the \label\Slave_name folders)? I understand Jenkins does this to avoid confusion but my workspaces are on completely different VM's that won't interact with each other in any way. I have to use the c:\workspace directory in order to build properly.
You can start Jenkins with extra params:
-Dhudson.model.Slave.workspaceRoot=c:\workspace
Taken from here:
https://issues.jenkins-ci.org/browse/JENKINS-12667
Terms:
UnifiedDir: the target dir that you want to use that is the same on both VMs
Workspace: the dir that Jenkins creates that is unique to each VM
To get around the workspace isolation and unique naming, your build script should copy the entire workspace (or what you need from it) into the target unified directory. Then a Second call in your "Workspace\Build SCript" should call the "UnifiedDir\Build Script"
Now you have a unified workspace between build nodes. Just make sure you nuke the contents of this UnifiedDir BEFORE you copy the WORKSPACE contents over.
Related
I want to scan file stored in my Jenkins project workspace.
for example, when I make a project named my_project, I will get report pattern from Jenkins like **/report.xml. and to find report.xml file, I will explore in my own plugin.
since when I print pwd on jenkins console, it prints where my plugin written, not jenkins workspace. so I need to know how to explore jenkins workspace in my plugin.
thanks!
If you're asking where your jenkins workspace is, it is in the workspace folder where you can find all your projects. It should be relative to your plugin folder: ../workspace. You can try to change directory using the relative path. Hope this helps.
Jenkins is creating separate workspace when running parallel nodes, but those temporary workspaces don't have all the files as original workspace. I want to use the file in the workspace. Is there any workaround for this?
Just before calling parallel deploy save the workspace in a variable something like this:
def workspace = sh(script:'pwd', returnStdout:true).trim()
Now you can access all the file present in the original workspace.
NOTE: This is just a workaround for this.
Is it possible to get current build's workspace path using jenkins remote api? I can get a build details based on build number with api/json, but it doesn't return the workspace details.
curl http://jenkinsServer:8080/job/testing/1/api/json
As far as I know you can't do that using Jenkins remote API. However, you can probably infer the workspace from your project name. If, say, Jenkins base workspace is /var/lib/jenkins/workspace (which is the case with default install on Unix), the workspace for your project should simply be :
/var/lib/jenkins/workspace/your-project
That could be sufficient for your needs, but workspace may vary, in particular if you are checking out some other repo inside your pipeline (or loading some other pipeline script from your base script), you could notice folders such as :
/var/lib/jenkins/workspace/your-project#tmp
/var/lib/jenkins/workspace/your-project#script
Im trying to setup jenkins in my company and Ive got some problems.
Im using this commands to build the project:
SET MSBuild="C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe"
SET BUILDS=C:\Program Files (x86)\Jenkins\jobs\xxx\builds\
SET OUTPUT_PATH="%BUILDS%%BUILD_NUMBER%"
SET RSVARS="C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
CALL %RSVARS%
SET PATH=%PATH%;D:\komponenty\DXE3\ADSI
%MSBuild% xxx.dproj /t:Build /p:Config=Debug;Platform=Win32;DCC_ExeOutput=%OUTPUT_PATH% /maxcpucount:4
It works fine when i type this in cmd but. I gave administrive privileges to jenkins service. When I try to build project with jenkins i receive error like this:
F1026: File not found: 'ADSI.dcu
this is a component for Delphi and i have this component on second partition. Jenkins has access for many components on this partition but not for this one.
The difference between the two will be your current directory.
Jenkins will start you off in a specific working folder for the job (possibly C:\Users\<User-ID>\.jenkins\jobs\<Job-Name>\workspace).
Add the following to your Jenkins commands to see where you're doing the build from:
echo Current Folder: %cd%
A simple "solution" would be to just add a command in Jenkins to change directory to the same folder you're in when you test from the command-line.
However, I suggest you rather do the following:
Ensure Jenkins gets the latest source from your source repository into its working folder. (There are various plugins depending on what particular tool you use.)
Ensure you cd (change directory) to the correct folder within the workspace folder.
I have set my workspace directory to C:\jenkins_builds\workspace and I want to build ProjA and ProjB, each having a local workfolder (same as project name).
When fetching the source code from my repository, the first two things the TFS plugin does are:
tf workspace -new %workspace-name-A%;%user-name% -server:%my-server%
tf workfold -map $%branch% ProjA -workspace:%workspace-name-A% -server:%my-server%
Which goes fine when building ProjA. The problem is, the first command maps the root directory from the repository directly to my C:\jenkins_builds\workspace directory. The second command does what I actually want, i.e. mapping %branch% to the ProjA subfolder. Later on, when building ProjB, the first command fails (and consequently the build) with the following error message:
The path C:\jenkins_builds\workspace is already mapped in workspace %workspace-name-A%;%user-name%.
OK, it seems like a bad idea to map the root directory to the work directory. But why does this automatically happen when the TFS plugin runs the workspace new line? Currently I have to clean things up between building ProjA and ProjB by running the -unmap command.
My team is using Team Foundation 3.0.
We have the same situation and there are 2 ways to solve this:
use different workspace-root-directories for the two builds
This results in the need for two checkouts => double the space and slower, but better isolation between the two builds
"hardcode" the workspace name to the same for both builds
By default jenkins creates a workspace containing the build name, which can be changed in the "advanced" section of the TFS config, and then you can use the same workspace-/workfolder-mapping for several builds - in our case we called them ProjectName_${NODE_NAME} so it even works on several nodes