Using the Jenkins Subversion Plugin

Git, Mercurial and other distributed software configuration management (SCM) solutions enjoyed great success over this past year, but the large majority of developers still use the classic, de facto standard — Subversion. Now hosted by the Apache Software Foundation, Subversion 1.7 was released last year with significant improvements. Due to its widespread acceptance, we can rely on a large user base for the foreseeable future. As it does for other SCM solutions, Jenkins has a dedicated plugin to support Subversion, one of the most widely used SCMs. It is part of the core release and provided by default with your Jenkins installation files.

The Jenkins Subversion plugin uses SvnKit as the subversion client and doesn’t require a native client to be available on the host. Setting up a CI server with Jenkins and Subversion is limited to a very minimal installation process: just run the Jenkins WAR and you’re done.

How To …
When configuring a job with Jenkins Subversion plugin, Jenkins will try to validate the repository URL that was entered. As the repository may require authentication, Jenkins will ask you to enter credentials. Those credentials are stored on your first valid authentication, so it won’t bother you for them on your next access. To change the credentials used to access a repository, you can navigate to https://JENKINS/scm/SubversionSCM/enterCredential. Please note: in some circumstances, setting authentication may be a more complex process, especially if you use Kerberos or client certificates.

A Jenkins SCM plugin will:

  1. detect changes in the SCM and trigger a new build if needed
  2. put the workspace in the desired state for a build to start

The Jenkins Subversion plugin can poll changes from one or multiple repositories, and do some fine filtering for incoming changes. For example, you can select a subset of your repository using include/exclude rules, or filter by user or commit message to ignore some commits if you use automated tools that commit irrelevant changes in the repository.

Multiple repositories, inclusion and exclusion rules can be used to focus on a precise set of changes you want your continuous integration server to monitor. As combinations may be complex, you’re encouraged to progressively introduce such rules to exclude irrelevant commits.

When a commit is detected to match all the configured rules, a build is triggered. But this will require your Jenkins server to actively poll Subversion for changes. If you already have read

The Jenkins Subversion plugin exposes the current state to the build as an environment variable, like $SVN_URL and $SVN_REVISION. You can use them in your build script to improve the metadata of the generated artifact. On a Java project you can, for example, include the Subversion URL and revision in your MANIFEST to easily retrieve the source code for a JAR.

Use on DEV@cloud
The Subversion plugin is, of course, available on CloudBees DEV@cloud and can be configured to access either SVN repositories hosted by CloudBees or your existing repository hosted on SourceForge, Google Code or your own infrastructure as long as it is available on the Internet using http(s).

Relevant Documentation
You can read more about the Subversion plugin on the Jenkins wiki

You can read more about Subversion in general in the SVN e-book available at

— Nicolas de Loof, Senior Engineer
Blog Categories: 


I use jenkins(1.445) and subversion plugin(1.34),<br />the svn:externals could be checked out on linux slaves, but couldn't be checked out on win32 slaves(no error message).<br />Could you give me a hand?I don't know where to ask,thanks!

You can ask on Jenkins User list (!forum/jenkins-user). May relate to the SvnKit implementation on windows to use JavaHL and native svn client when available on the OS - just my assumption.

svn update does not work in jenkins like subversion. It removes local files that have been copied over. If I am testing some file changes, I will copy them over to the jenkins workspace and run the job... it removes what I copied and uses the older version... this is not how subversion does it with svn update. Also if as the user jenkins, I cd into the workspace and do an svn up, it works just fine, when the job is run, it reverts back to the previous version and complains about the svn time being off, there is some sort of defect with timing.. .I always use an ntp server....

Add new comment