I have done the following
Create a slave Node
In the Labels field added Test
Save the node configuration
Created a new Job
Selected the options Restrict where this project can run
In the Label expression field added Test
Save the job
When i build the job, i get the error
java.io.FileNotFoundException: C:\Users\Administrator\Test\src\test\java\test\data\Project Suites.xlsx (The system cannot find the path specified)
Not Sure whats wrong, The folder does not exist in the slave machine but exist in the Master machine.
But if i run it using the master it works fine.
Hmm I dont understand the problem - you said it yourself, the file does not exist in the slave machine, and you're running jenkins on the slave. So of course its not going to find the file?
Just move the file to the slave machine and run the job on the slave?
Related
I am trying to run a pipeline job that get its' pipeline file from TFS but the mapping of the workspace and the checkout is done on the Master instead of the Slave.
I have Jenkins-master which is installed on a linux machine and I connected a windows machine as a slave to it. I created a pipeline job with 'Pipeline script from SCM' option selected for TFS.
How can I make the windows slave run that pipeline job?
The master can't run that job because it is running on linux and it fails when it is trying to map a workspace to TFS in order to download the pipeline script and run it.
Even if I create another pipeline job and select to hard-code a script to run my original pipeline job like this:
node('WIN_SLAVE') {
build job: 'My_Pipeline'
}
It doesn't work.
And I can see in the output that the initiali script (above) is in fact running on my windows slave, but when it's building the job 'My_Pipeline' it still tries to map a workspace to the Jenkins-master at it's linux machine path /var/jenkins/... and it fails.
If the initial pipeline script ran at the windows slave, why does the other pipeline script not running on the same node? Why is it trying again to checkout the pipeline file from TFS to the Jenkins-Master?
How can I make the windows slave checkout the pipeline file and run it?
Here are some things to check...
Make sure you disabled the original job, or you are completely redefining it for running on the slave, because you indicated you set up “another job” for the slave. It appears that this other job is just triggering the previous job, rather than defining its own specifications. When the job is ran on the slave, it’s just running whatever settings are in that original job.
Also, If you have the box checked to build when a change is pushed to TFS, then your original job could still be trying to run every time a change is made to TFS.
Verify the slaves Remote root directory is set properly in the slave configuration under Manage Jenkins -> Manage Nodes.
Since this slave job is triggering the other job you originally created on the master, then it will build on the master as expected.
Instead of referencing the My_Pipeline job, change the My_Pipeline job itself to run on the slave. If you are using a declarative Pipeline for the original job, then change that original job to run on the slave within the original job settings. You can do it similarly to how you have indicated above, just define the node in the original job.
If the original job is a freestyle project, there is a checkbox titled Restrict where this project can be run. Check that and include the name of the slave in the Label Expression. When you run the job, it will then be restricted to the slave.
Lastly, posting the My_Pipeline job will be helpful.
My Jenkins master is up and running. I have created a slave node, launched it successfully from the slave machine, and have done the web services installation so that the connection is established on startup of the slave machine. I have also created a "job" that builds successfully in Jenkins.
How do I tell Jenkins what to actually do on my slave machine? I want to use Jenkins to run an IntelliJ test suite (Selenium and Cucumber) on the slave machine, but haven't been able to figure out exactly how to get it to do this. Note: I've just started looking into the Seleniumhq plug-in, but I'm not sure if this is what I need or not since I'm working with a remote slave.
Limit where the jobs can run using the 'Restrict where this project can be run' to your slave node.
Distributed Builds in Jenkins
My confusion here stemmed from not having my project connected to a VCS repository. Without it, I couldn't figure out how to build-out my project's workspace in the slave environment from Jenkins. I also didn't understand the concept of adding additional build steps at the time I asked this question.
Once I had the VCS connection set-up (I had to do some finagling with Git/Visual Studio Team Services to get it connected, which is why I went with "none" as my version control option at first), my workspace was built for me on the slave machine when I built the project from Jenkins. Then, I used a combination of build steps ("execute Windows batch command" and "Invoke top-level Maven targets") to carry-out the rest of the project's functions.
I have one Jenkins master node and 2 Jenkins slave nodes. All my job builds happen in the slave node. When I configured my slaves, I set the Remote root directory as /data/home/jenkins/jenkins-slave. Also, I give the custom workspace option as DEVELOP_BRANCH in the job configuration page of the respective job.
However, at the start of job, I get the following log information:
Building remotely on linux in workspace /data/home/jenkins/jenkins-slave/workspace/DEVELOP_BRANCH
I want to start my builds in this location.
/data/home/jenkins/jenkins-slave/DEVELOP_BRANCH
Why does the extra workspace directory come into the picture? How do I remove it? I do not have access to Jenkins master node. So, if there is a workaround that can match my requirements, it would be awesome.
Note: By node, I refer to a Linux OS computer with redHat distribution.
In project configuration, under Advanced Project Options, you can check Use custom workspace and put a path there.
If you put an absolute path, it will be used without any extra workspace/ directory. (at least that's the behavior I can see on a windows server.)
I am configuring Jenkins for the first time, have been a user of it until now.
I read the documentation and understand what "$WORKSPACE" means on the slave.
I had a misconception that by default the jobs on Jenkins Slave run in a unique directory per job inside the workspace directory. This doesnt seem to be the case.
How do I assign a unique directory per job run?
Will Jenkins automatically cleanup this job run directory after its done?
By default jenkins runs from $WORKSPACE/JOB Name ; here WORKSPACE is defined in the node configuration. This could be changed by choosing Advance Project options -> Use custom workspace under your job configuration.
Regarding cleanup: Choose Build Environment -> Delete workspace before build starts under jobs configuration if you like to cleanup for each new job.
Jenkins will create workspace directory by default if jobs is successfully executed at-least once
I'm running jenkins on my local machine. I need to build and run a project on remote machine as a slave.
I have my project(Java code) in my local machine where the Jenkins is running. So Now when I build the project it looks for the code in my slave machine and says it's not able to find the build.xml in my slave machine.
I want to be able to have Jenkins looks for the code in my local machine and build it in my slave machine and run in the slave machine.
Is that possible? if yes pls help me.
You do not state which version control system you are using? Jenkins has version control plugins for Git, Subversion, etc...
The idea is that you commit and push your changes to your source code repository and the Jenkins slave will automatically pull down the code and compile if anything has changed.
Try the copy artifact plugin. You can create 2 jobs - 1st one to just check out the source code from your repo/version control/workspace. The second job (which runs on the slave restrict where this job can be run inside the job config) can copy those files automatically to the ...remote slave/workspace and then you do whatever you want with them.
This will do what you want, but as Mark O'Çonnor mentions, the idea is you commit the changes to your repository and then the other machine checks it out.