Backup and Store Jenkins Jobs and Configuration in Source Control such as GIT or SVN

Issue

  • I would like to automatically check-in and backup my Jenkins jobs via GIT. How can I manage separate masters with different jobs that move between the masters?
  • I would like manage plugin versions in a source control system.

Environment

  • CloudBees Jenkins Enterprise
  • CloudBees Jenkins Operations Center

Resolution

There are several options, depending on your organization’s SCM configuration and specific needs:

1) Use CloudBees Backup Plugin to take a “Local directory” backup which would be a snapshot of your $JENKINS_HOME/jobs/ directory. From here you can store the data in SCM for version control/history and disaster recovery purposes.

2) Use the Workflow Multibranch Feature
provided by the Pipeline Plugin. It requires the workflow
definition to be stored in a Jenkinsfile in the project and will use it to build your project. As the job configuration
is stored in the SCM, it can be moved to another master.

3) If you need to perform backups of your masters, you could also use a Cluster Operation
on your CloudBees Jenkins Operations Center
instance to generate and gather the backups on all connected masters.

4) To capture plugin versions on your CloudBees Jenkins Enterprise (Client Master), you can use the run the Jenkins CLI to do this:
java -jar jenkins-cli.jar -s ${JENKINS_MASTER_URL} list-plugins
(append > myinstance_plugins.txt " to this command to capture the output as a text file, from which you can check-in to source control)

If you have CloudBees Jenkins Operations Center, you can similarly capture plugin versions:
java -jar jenkins-cli.jar -s ${CJOC_URL} list-plugins

This command will return the job definition XML to stdout which includes the section that does contain all of
the plugins available on the Update Center:
java -jar jenkins-cli.jar -noKeyAuth -s ${CJOC_URL} get-job CustomUpdateCenter

Was this article helpful?
1 out of 2 found this helpful

Have more questions?

2 Comments

Date Votes
  • 1
    Avatar
    Lee Meador

    Two questions:

    1) Why the "multibranch" pipeline? Wouldn't the plain pipeline work?

    2) Where is the list of files that need to be saved? If the pipeline job is going to collect the files, we need information on which files.

    Perhaps the strategy is to take the latest zip or tar.gz file created by the backup job and update those in the scm. If so, it would store all the hpi and jpi files for plugin AND why would you need a list of plugins with versions. Further, hpi, jpi and war files aren't really good subjects for inclusion in an scm (as aren't most binary files). So, if the strategy is to use the backup zip/tar.gz, which files should be left out.

    I think this article needs some more detail so everyone doesn't have to duplicate the efforts.

  • 0
    Avatar
    Jason Franks

    shouldn't have to setup a bunch of stuff to get an undo / history of the jobs configuration.  I just lost a full job that I have been working hours on.  Yes I have backups but they are nightly so all of today's work is lost not just the last changes, also dont want to restore everything just 1 job config.   This was due to a bad VPN link messing up on the save call.  I dont understand how a bad save deletes all contents from the config.

    I hope that CB or Jenkins teams work out a more integrated solution to save job versions and revert.

    Edited by Jason Franks
Please sign in to leave a comment.