I installed the Deploy Plugin on my Jenkins in order to automate the deployment of my Maven built war packages to Tomcat 7. The problem is that I am able to use the plugin to deploy to a remote Tomcat server only if they are made within the same job that uses the deploy plugin. In other words, I have not been able to set up a standalone job that deploys artifacts made by a different job.
For example, I have a job named pack.foo. It uses the source code in /var/lib/project/module to create module.war and put it in /var/lib/project/module/target. However, because of the Maven version setup, the artifact posted on pack.foo's artifact page is something like module-2.0.0-SNAPSHOT.war.
The only way I am able to deploy module.war is if I add a Post-build Action to pack.foo and specify **/module.war to be a remote Tomcat manager URL (provided I have the manager's credentials in Jenkins config). Then the job's console output logs that /var/lib/project/module/target/module.war was deployed to that URL:
Deploying /var/lib/project/module/target/module.war to container Tomcat 7.x Remote with context
[/var/lib/project/module/target/module.war] is not deployed. Doing a fresh deployment.
Deploying [/var/lib/project/module/target/module.war]
How can I use this, or another plugin, to deploy a WAR artifact that was made in a separate Jenkins job? I would like to have separate jobs for artifact creation and deployment. The plugin wasn't finding **/module-2.0.0-SNAPSHOT.war or even **/module.war built by another job even though there was definitely a file on disk that matched that pattern.
See the paragraph on the Deploy Plugin's page you linked:
How to rollback or redeploy a previous build
There may be several ways to accomplish this, but here is one suggested method:
Install the Copy Artifact Plugin
Create a new job that you will trigger manually only when needed
Configure this job with a build parameter of type "Build selector for Copy Artifact", and a copy artifact build step using "Specified by build parameter" to select the build.
Add a post-build action to deploy the artifact that was copied from the other job
Now when you trigger this job you can enter the build number (or use any other available selector) to select which build to redeploy. Thanks to Helge Taubert for this idea.
I want to use a config file provided by config file provider plugin in a pipeline project.
However when I run a build step inside a slave. I get a "PermissionDenied" exception, The same runs in master however.
So question is thats the best possible way to share files between master and slaves. I may not be able to Copy to slave plugin as there doesn't seem to be pipeline support.
If you want to share files between stages or nodes you can use the stash - unstash methods. see the example here
If you want to share files between builds you can use the archive method and the Copy Artifact Plugin
I'd like to use the PostBuildScript plugin to deploy the artifacts from a Matrix job that runs on several slaves.
The slaves are archiving the artifacts-- but its unclear how to access them from the PostBuildScript. How can I get the matrix node artifacts into the master workspace where the PostBuildScript job is running?
There is a plugin called Copy To Slave Plugin.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin
This can copy artifacts from master to slave or vice versa. Inorder to get your work done you can use this plugin. It has a feature called "Copy files back to master node". This will copy the files back to the masters workspace. So you don't need post build script plugin to copy artifacts. This way will be more simpler.
I have a Java project, building with Gradle, using the Jenkins CI server, and I would like to publish to an Artifactory server, using Maven-compatible artifacts. The project is using Git. I would also like to use the release management features of Jenkins if possible.
This is very confusing. There are at least five plugins, with much overlapping redundant functionality. Some plugins seem to replace others. Some plugins seem to require others.
FYI, the five relevant plugins seem to be:
1) Jenkins Artifactory Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
2) Gradle "maven" Plugin
http://www.gradle.org/docs/current/userguide/maven_plugin.html
3) Gradle "maven-publish" Plugin
http://www.gradle.org/docs/current/userguide/publishing_maven.html
4) Gradle "artifactory" Plugin
https://www.jfrog.com/confluence/display/RTF/Gradle+Artifactory+Plugin
5) Gradle "artifactory-publish" Plugin
http://www.jfrog.com/confluence/display/RTF/Gradle+1.6+Publishing+Artifactory+Plugin
What is the best way to set this up?
If I use the Jenkins Artifactory Plugin with none of the other plugins mentioned, I get an error:
No publish configurations specified for project ':' and the default 'archives' configuration does not exist.
Cannot publish pom for project ':my-great-app' since it does not contain the Maven plugin install task and task ':my-great-app:artifactoryPublish' does not specify a custom pom path.
I assume I need to use either maven or maven-publish in build.gradle?
maven-publish is labeled as the incubating successor to the maven plugin. How much better is it? How stable is it?
How does using one of the Gradle Artifactory plugins compare to the standard maven publishing plugins vs using the Jenkins plugin?
Gradle Artifactory plugins: Gradle can deploy build artifacts and build information directly, without need in CI server by using one of the Artifactory plugins.
artifactory plugin works with maven plugin and publishes configurations, generated by maven plugin.
artifactory-publish plugin works with maven-publish plugin and publishes publications generated by maven-publish plugin.
Jenkins Artifactory plugin works in two modes:
Providing a UI to override settings, specified in artifactory or artifactory-publish plugins in Gradle build script.
Adding and configuring artifactory plugin to the Gradle script if it is not there.
It also provides release management (for both modes).
So, here's what you need to decide:
Whether you use one of the Gradle plugins. Our recommendation is - use it (versioned configuration in build script is an advantage comparing to UI-only configuration.
Which plugin you want to use -- maven or maven-publish. While the later is still 'incubating', it is much more flexible than the former. Once you know with which maven plugin you want to use, select the appropriate artifactory plugin.
You need the Artifactory Jenkins plugin in either way if you want to use the release functionality, just check (or uncheck) the 'Project uses the Artifactory Gradle Plugin' checkbox.
I am currently using Jenkins on my development PC. I installed it on my development PC, because I had limited knowledge on this tool; so I tested on it in my development PC. Now, I feel comfortable with Jenkins as my long term "partner" in the build process and would like to "move" this Jenkins to a dedicated server.
Before this I have done few builds and have the artifacts archived from each build. In particular, the build number is very important to me for version control.
How can I export all the Jenkins information from my current PC to my new server?
Following the Jenkins wiki, you'll have to:
Install a fresh Jenkins instance on the new server
Be sure the old and the new Jenkins instances are stopped
Archive all the content of the JENKINS_HOME of the old Jenkins instance
Extract the archive into the new JENKINS_HOME directory
Do not forget to change the owner of the new Jenkins files : chown -R jenkins:jenkins $JENKINS_HOME
Launch the new Jenkins instance
Do not forget to change documentation/links to your new instance of Jenkins :)
JENKINS_HOME is by default located in ~/.jenkins on a Linux installation, yet to exactly find where it is located, go on the http://your_jenkins_url/configure page and check the value of the first parameter: Home directory; this is the JENKINS_HOME.
In case your JENKINS_HOME directory is too large to copy, and all you need is to set up same jobs, Jenkins Plugins and Jenkins configurations (and don't need old Job artifacts and reports), then you can use the ThinBackup Plugin:
Install ThinBackup on both the source and the target Jenkins servers
Configure the backup directory on both (in Manage Jenkins → ThinBackup → Settings)
On the source Jenkins, go to ThinBackup → Backup Now
Copy from Jenkins source backup directory to the Jenkins target backup directory
On the target Jenkins, go to ThinBackup → Restore, and then restart the Jenkins service.
If some plugins or jobs are missing, copy the backup content directly to the target JENKINS_HOME.
If you had user authentication on the source Jenkins, and now locked out on the target Jenkins, then edit Jenkins config.xml, set <useSecurity> to false, and restart Jenkins.
This worked for me to move from Ubuntu 12.04 (Jenkins ver. 1.628) to Ubuntu 16.04 (Jenkins ver. 1.651.2). I first installed Jenkins from the repositories.
Stop both Jenkins servers
Copy JENKINS_HOME (e.g. /var/lib/jenkins) from the old server to the new one. From a console in the new server:
rsync -av username#old-server-IP:/var/lib/jenkins/ /var/lib/jenkins/
Start your new Jenkins server
You might not need this, but I had to
Manage Jenkins and Reload Configuration from Disk.
Disconnect and connect all the nodes again.
Check that in the Configure System > Jenkins Location, the Jenkins URL is correctly assigned to the new Jenkins server.
Jenkins Server Automation:
Step 1:
Set up a repository to store the Jenkins home (jobs, configurations, plugins, etc.) in a GitLab local or on GitHub private repository and keep it updated regularly by pushing any new changes to Jenkins jobs, plugins, etc.
Step 2:
Configure a Puppet host-group/role for Jenkins that can be used to spin up new Jenkins servers. Do all the basic configuration in a Puppet recipe and make sure it installs the latest version of Jenkins and sets up a separate directory/mount for JENKINS_HOME.
Step 3:
Spin up a new machine using the Jenkins-puppet configuration above. When everything is installed, grab/clone the Jenkins configuration from the Git repository to the Jenkins home direcotry and restart Jenkins.
Step 4:
Go to the Jenkins URL, Manage Jenkins → Manage Plugins and update all the plugins that require an update.
Done
You can use Docker Swarm or Kubernetes to auto-scale the slave nodes.
Sometimes we may not have access to a Jenkins machine to copy a folder directly into another Jenkins instance. So I wrote a menu driven utility which uses Jenkins REST API calls to install plugins and jobs from one Jenkins instance to another.
For plugin migration:
GET request: {SOURCE_JENKINS_SERVER}/pluginManager/api/json?depth=1 will get you the list of plugins installed with their version.
You can send a POST request with the following parameters to install these plugins.
final_url=`{DESTINATION_JENKINS_SERVER}/pluginManager/installNecessaryPlugins`
data=`<jenkins><install plugin="{PLUGIN_NAME}#latest"/></jenkins>` (where, latest will fetch the latest version of the plugin_name)
auth=`(destination_jenkins_username, destination_jenkins_password)`
header=`{crumb_field:crumb_value,"Content-Type":"application/xml”}` (where crumb_field=Jenkins-Crumb and get crumb value using API call {DESTINATION_JENKINS_SERVER}/crumbIssuer/api/json
For job migration:
You can get the list of jobs installed on {SOURCE_JENKINS_URL} using a REST call, {SOURCE_JENKINS_URL}/view/All/api/json
Then you can get each job config.xml file from the jobs on {SOURCE_JENKINS_URL} using the job URL {SOURCE_JENKINS_URL}/job/{JOB_NAME}.
Use this config.xml file to POST the content of the XML file on {DESTINATION_JENKINS_URL} and that will create a job on {DESTINATION_JENKINS_URL}.
I have created a menu-driven utility in Python which asks the user to start plugin or Jenkins migration and uses Jenkins REST API calls to do it.
You can refer the JenkinsMigration.docx from this URL
jenkinsjenkinsmigrationjenkinsrestapi
Let us say we are migrating Jenkins LTS from PC1 to PC2 (irrispective of LTS version is same of upgraded).
It is easy to use ThinBackUp Plugin for migration or Upgrade of Jenkins version.
Step1: Prepare PC1 for migration
Manage Jenkins -> ThinbackUp -> Setting
Select correct options and directory for backup
If you need a job history and artifacts need to be added then please select 'Back build results' option as well.
Go back click on Backup Now.
Note: This Thinbackup will also take Plugin Backup which is optional.
Check the ThinbackUp folder must have a folder with current date and timestamp.
(wait for couple of minutes it might take some time.)
You are ready with your back, .zip it and copy to PARTICULAR (which will be 'Backup directory') directory in PC2.
Unzip ThinbackUp zipped folder.
Stop Jenkins Service in PC1.
Step2: Install Jenkins (Install using .war file or Paste archived version) in PC2.
Create Jenkins Service using command sc create <Jenkins_PC2Servicename> binPath="<Path_to_Jenkinsexe>/jenkins.exe"
Modify JENKINS_HOME/jenkins.xml if needed in PC2.
Run windows service <Jenkins_PC2Servicename> in PC2
Manage Jenkins -> ThinbackUp -> Setting
Make sure that you PARTICULAR path from step1 as Backup Directory in ThinBackup settings.
ThinbackUp -> Restore will give you a Dropdown list, choose a right backup (identify with date and timestamp).
Wait for some minutes and you have latest backup configurations including jobs history and plugins in PC2.
In case if there are additional changes needed in JENKINS_HOME/Jenkins.xml (coming from PC1 ThinbackUp which is not needed) then this modification need to do manually.
NOTE: If you are using Database setting of SCM in your Jenkins jobs then you need to take extra care as all SCM plugins do not support to carry Database settings with the help of ThinbackUp plugin.
e.g. If you are using PTC Integrity SCM Plugin, and some Jenkins jobs are using DB using Integrity, then it will create a directory JENKINS_Home/IntegritySCM, ThinbackUp will not include this DB while taking backup.
Solution: Directly Copy this JENKINS_Home/IntegritySCM folder from PC1 to PC2.