I have Perforce managing our source. I have an application that uses Perforce as the back end. I have also setup an automated test tool that runs my application and performs automated tests. I want Jenkins to trigger the test every time there is a change in the source code. However, my Jenkins instance messes up the workspace root. It creates its own workspace root and that causes my application to fail. Jenkins actually overwrites the Perforce clients workspace root. So every time I try to get Jenkins work, I have to go and edit the workspace root in Perforce and reset it to the required value. I have tried getting Jenkins to manage the workspace and clearing the option to do the same but have failed. Is there anyway that Jenkins will use my workspace (root) settings and not change it?
Jenkins 'owns' the Perforce workspace used for the build, hence it sets the root.
Your application should ideally build and run independently of its location. However, there is the 'Advanced Project Options' --> 'Use custom workspace' configuration option in Jenkins.
Jenkins must have it's own Perforce workspace separate to your own development workspace. Use the Template workspace to mirror the options or create a Manual workspace for Jenkins own use.
Please note, there are two Perforce plugins for Jenkins p4 and perforce, documentation for the p4 plugin is located here/
Related
We have some jobs set up which share a workspace. The workflow for the various branches is:
Build a big honking C++ project called foo.
Execute several downstream tests, each of which uses the workspace of foo.
We accomplish this by assigning the Use custom workspace field of the downstream jobs to the build workspace.
Recently, we took one branch and assigned it to be build on a Jenkins slave machine rather than on the master. I was surprised to find that on master, the foo repository was cloned to $JENKINS_JOBS_PATH/FOO/workspace/foo_repo - while on the slave, the repository was cloned to $JENKINS_JOBS_PATH/FOO/foo_repo.
Is this by design, or have we somehow configured master and slave inconsistently?
Older versions of Jenkins put the workspace under the ${JENKINS_HOME}/jobs/JOB/workspace directories. After upgrading, this pattern stays with the Jenkins instance. New versions put the workspaces in ${JENKINS_HOME}/workspace/. I suspect the slaves don't need to follow the old pattern (especially if it is a newer slave), so the directories may not be consistent across machines.
You can change the location of the workspaces on the master in Jenkins -> Configure Jenkins -> Advanced.
I think the safe way to handle this... If you are going to use a custom workspace, you should use that for all of your jobs, including the first one that builds the big honking c++ project.
If you did this all in a pipeline, you can run all of this in a single job and have more control over where all the files are, and you have the option of stash and unstash, but if the files are huge, stash may not be the way to go.
You can omit 'Use custom workspace' option for each job and instead change master and/or slave workspace paths and use
%WORKSPACE%/../foo_repo path
or (that equal)
./../foo_repo path
In that case
%WORKSPACE% = [master or slave node workspace]/[job name]
and
%WORKSPACE%/../ = [master or slave node workspace]
I have a maven jenkins job which builds to a directory called 'build.x86_64'. All of the artifacts are built to this directory. For some reason if I enable SCM polling, this directory gets deleted after the build completes. I can't see anything in the console output which says it is deleting the target.
Jenkins does however keep the build artifacts in it's own configured directory
/var/lib/jenkins/jobs/[my job]/builds
I have a downstream job which needs the artifacts but they keep getting deleting.
If I turn off SCM polling and use the 'Build Now' option in the GUI, it doesn't delete the build directory. I can' see anything in the configuration which could cause this. The jenkins job is cloned from one with the same configuration. The problem does not occur in the job I cloned from.
This was caused by the misconfiguration of the Source Code Management section of the Jenkins config. Under the Additional Behaviours section I had added, Clean before checkout. It should have been set to Clean after checkout.
My Jenkins is installed on the default location: /var/lib/jenkins. Every time it builds, it changes my root directory of my workspace (on my local machine /home/john/p4) to /var/lib/jenkins/..., which shouldn't happen?
How to specify my root directory of my client(workspace) so that the build won't change its location? Should I change $JENKINS_HOME? If I should change it, then that's equavilent to the fact that I have to re-install Jenkins to the location I want, because $JENKINS_HOME is supposed to be the root directory for all jenkins files and builds.
What should be the correct behavior of Jenkins and P4 client? Also, does it have anything to do with the user who starts the builds in Jenkins? Does Jenkins user have anything to do with the Linux user who installs Jenkins?
The p4-plugin Jenkins requires it's own Perforce workspace and it WILL set the Perforce workspace root to match the Jenkins workspace root.
Let Jenkins create a new Perforce workspace (use a name that does not exist, I generally prefix it with jenkins-). If you want to be dynamic use a name like:
jenkins-${NODE_NAME}-${JOB_NAME}
...as ${NODE_NAME} and ${JOB_NAME} will expand.
Next define a view mapping (or streams path) to specify the location of the files in Perforce and how you want them to appear in the workspace. e.g.:
View:
//depot/myProj/main/... //jenkins-${NODE_NAME}-${JOB_NAME}/...
As for the user that connects to Perforce, that is defined in the Perforce Credentials, but the files sync'ed to the Jenkins Master (or Slave if you have a build farm) will use the UID/GID of the Jenkins service.
You can find the documentation for the p4-plugin here.
I have two Jenkins, both are master. Both have 5 salve Jenkins each. I have one job on first jenkins that needs to be cloned for each job.
I can clone the job on first jenkins and its slave but not on second master jenkins. Is there a way to clone a job from one jenkins to another?
I have one more question can I archive the job at some defined location other than master jenkins, May be on slave?
I assume you have a job called "JOB" on "Jenkins1" and you want to copy it to "Jenkins2":
curl JENKINS1_URL/job/JOB/config.xml | java -jar jenkins-cli.war -s JENKINS2_URL create-job
You might need to add username and password if you have turned on security in Jenkins. The jenkins-cli.war is available from your $JENKINS_URL/cli.
Ideally you should make sure you have the same plugins installed on both Jenkins1 and Jenkins2. More similar you can make the two Jenkins masters, the fewer problems you will have importing the the job.
For the second part of your question: slaves don't store any Jenkins configuration. All configuration is done on Master. There is a lot of backup plugins, some backup the whole Jenkins, some backup just job configuration, some backup individual jobs, export them to files, or even store/track changes from SCM such as SVN.
So "archiving job configuration to slave" simply makes no sense. But at the end of the day, a job configuration is simply an .xml file, and you can take that file and copy it anywhere you want.
As for the first part of the question, it's unclear what you want. Do you want to clone a job automatically (as part of another job's process), programmatically (through some script) or manually (through the UI, other means)?
Edit:
Go to your JENKINS_HOME directory on the server filesystem, navigate to the jobs folder, then select the specific job folder that you want.
Copy the config.xml to another server, this will create the same job with the same configuration (make sure your plugins are same)
Copy the whole job_name folder if you want to preserve history, builds, artifacts, etc
This question is similar to the question being asked at How to configure a single Jenkins job to make the release process from trunk or branches? however in this case Perforce is the SCM being used within Jenkins. Currently in Jenkins I have the following:
One release job per branch/trunk.
Each job has a separate Perforce workspace mapping the necessary branch/trunk
Upon running the job, the jenkins-perforce-plugin synchronises the complete workspace and then runs the maven release plugin.
Ideally I would like to have one release job that can point to any branch, synchronise to the code from that branch and carry out a maven release. However, with Perforce workspaces, I will require a view mapping for each branch/trunk. Is there are way to tell the jenkins-perforce-plugin to only synchronise to a particular view in the workspace view? This way I could build the release job with a parameter that passes in the branch path and the jenkins-perforce-plugin synchronises to jobs perforce workspace to this path only and then carries a build from there.
If I were trying to implement this as described I would created a parameterized build where I could hand in a Perforce label name. The Perforce Jenkins plugin can sync to a label; I would create labels for each release specifying the paths that should be synced and with a revision specifier of #head.
Jenkins should then sync just the files you want for that build. The workspace would of course map everything; the labels will specify the files to fetch.