Hudson: Keeping track of number of changed files in each build

Question

Does anyone know of a built-in way to have Hudson keep track of how many files are changed, added or deleted in the source code repository in each build ? I'd like to plot the results in the same way that the JUnit test results graphs show the numbers of passing and failing tests for each build.

The Measurement Plots plugin and the Plot Plugin look like they might give me a starting point, but i'm wondering if there might be a more specific plugin or feature already available.

My SCM system is CVS, but I'd like a generic solution that would work with other SCM systems.

Answer 1

I think this question is more generic than specific to Hudson. You're probably going to have to write a little code by yourself. Unfortunately, I don't think any solution will be SCM agnostic because Hudson tends to use the SCM tools themselves to do the SCM bits.

I couldn't find any off-the-shelf solutions, so here's what I see would have to be done:

1. Find the SCM command that you are using (i.e., svn up, cvs -n).
2. Use wc -l or some other command to count the number of lines in output. This will give you an estimate to the number of changed/added/deleted files.
3. Parse the output if you want the names of individual files that have been added/changed/deleted.

Unfortunately, I don't think there's an SCM-agnostic way of doing this. Perhaps the best you could do is find a pure-Java CVS/SVN client implementation that you could modify to keep track of files as they come in from the SCM.

Answer 2

I don't believe there are any existing plugins that will do this directly.

If it doesn't need to be specifically tracked for each build (that is if you are really more interested in changes over time), then I would suggest setting up Sonar, which tracks daily changes from your builds and integrates fantastically with Hudson, or FishEye which connects directly to your SCM system.

But why not try to write the plugin for Hudson? Seems like the sort of thing that people might like to visualize as a per-build metric.