Advanced Subversion Polling with Jenkins: File Fingerprints

In ‘Polling Subversion with Jenkins’ we showed you how to configure Jenkins to poll an Apache Subversion repository once every five minutes. In this follow-up post, we’ll explore some advanced options you can introduce once you’ve implemented the basic polling system. This post will show you how to configure Jenkins to automatically track versioned files using ‘file fingerprinting.’

In the world of modern software development, it’s common practice to work on different projects simultaneously. With so much going on, it’s easy to lose track of where files originated, and what version is being used by which project. Thankfully, Jenkins supports file fingerprinting, which allows you to see exactly when and where your files are being produced and used, and even to upload a file from your local machine and query Jenkins on its version number. File fingerprinting works by creating a database of MD5 checksums, which gets updated automatically as new versions of fingerprinted files are committed to the repository.

How To: Setup File Fingerprinting

1. To enable file fingerprinting in uberSVN, simply select the ‘Jenkins’ tab, followed by the Jenkins job you previously setup to poll Subversion.

2. Select the ‘Configure’ option from the left-hand menu.

3. Tick the ‘Record fingerprints of files to track usage’ option.

4. Specify the files to track in the ‘Files to fingerprint’ text box. In this example, trunk/*.txt will track all .txt files in the trunk (if you wanted to track all .zip files in the tags directory, you would use tags/*.zip)

How To: Test Your File Fingerprinting

1. To test your setup, make some changes to the files earmarked for fingerprinting, and commit those changes.

2. Open the build report in Jenkins, and select ‘See Fingerprints’ to view the recorded fingerprints.

3. This screen will display some basic details about the tracked files, including the original owner, and how old the information is. To see more, click on the ‘more details’ link.

4. On this page, you can see all the jobs and builds where the file has been used.

How To: Check File Fingerprint

Another benefit of enabling file fingerprinting, is that if you have a file on your local machine but are unsure of its version number, you can upload it to Jenkins and check the fingerprint against Jenkins’ fingerprint database.

1. Start by selecting the ‘Check File Fingerprint’ option from the main Jenkins dashboard.

2. Upload your file and select ‘Check’ to run it against Jenkins’ database of file fingerprints.

3. Jenkins will then display all the information about the uploaded file.

Not yet started with uberSVN? It’s free to download and free to use! You can download the latest version now from If you need some extra support with your Jenkins+uberSVN installation, Professional Support for Jenkins is also available.

3 Responses to “Advanced Subversion Polling with Jenkins: File Fingerprints”

  • This presentation is a bit unclear on why one would actually want to do this: if you only consider files in the version control system, you already have reliable indications of what has changed.

    Kohsuke’s original blog on the subject makes this a bit clearer:

    The particular point there is tracking build-output files from one build job/project to another. It’s generally considered poor policy to check in any file you can generate with a build, basically because it wastes space and time, since the version control of the inputs already tracks changes. But when there are cascading dependencies like this (Project1 builds something, say foo.jar, which is then used by Project2), the tracking is at the least laborious, and perhaps unreliable.

    People with such configurations often resort to checking in their build outputs anyway, despite the best-practices advice against this. The Jenkins fingerprinting plug-in provides an alternate way to track changes to these files. It saves space (stores only a checksum and file name, not the whole file), and actually provides more extensive protection than source-level versioning (since things outside the version control system can affect the output file, such as compiler versions).

  • The main use of fingerprinting is likely to be tracking build files for dependencies between projects, however it can be useful for testers/project managers etc, who would likely have access to Jenkins,but not necessarily the version control system in use.

  • This was helpful in outlining the process of fingerprinting and I had no idea that you’d be able to actually supply a file and let jenkins tell you which builds its included in, very slick. I’m working on a project currently that has multiple hg repositories and lower level dependency jars being built, these jars aren’t included in any repos but are deployed on the build machine for other projects to build off them and fingerprinting appears to be a great way to see what jars went into a particular build of one of the projects. Thanks for the writeup

Leave a Reply