How do you handle builds with several commits? Is this relevant for new warnings only, i.e. the information is visible only for one build?

Easiest to explain what I think would be nice...

All of the files for build #38 look at who last touched the file (i.e. the last committer). From this you will get a total number for each user..... that's the new TOTAL's per user. The NEW Warnings by User is just the difference between build #38 and build #37's totals.

Build #38
Total Warnings per User

Change in Warnings from Build #37 per User

This raises a few questions. If there are two commits since the last build only the last committer get's pinned with the blame (which is kinda correct anyway), yes?

In an ideal world we would track how many new ones have been added and how many have been resolved... but that I imagine to be impossible, is this impossible?

Ok, I see. This will be not so easy to implement...

Hey all,

It's been a while since last comment . I'm quite interested in this issue since we would like to use similar behaviour in our build system. We would like to compare checkstyle violations before and after commit. If it get's increased after commit, we would like to send off emails with notification (same as when build fails). Therefore I would like to check on this issue, if it's going to be developed or it's dead and left behind . Thanks.

If I remember correctly two volunteers wanted to dig into that issue but since I didn't hear anything I think there is no progress (there are also some GitHub comments or issues about that problem).

Martin, I'm not sure if I misunderstand your use case but it looks much simpler that the original request and is already solved: if you set the new warning count to 0, then all committers participating in that build will become an email on any new warning. This is quite similar to the build failed email due to compile errors: Here you also don't know which commit actually broke the build, all committers get that Email.

Vote for this feature.

I found a similar maven plugin, but I haven't managed to work it like I want yet.
However it's obviously not the same solution, as it works only locally.
But integrating it to Jenkins would be very useful for controlling the code style.

I've implemented this feature using git's blame feature: https://github.com/jgibson/analysis-core-plugin/tree/blame

If you are working on a project that uses git as the SCM the plugin will run git blame on files that contain warnings. The commit that last modified the primary line number of each warning will be be associated with the warning. Then in the main UI there are tabs and links for viewing issues on a per-user basis.

The attached screenshots show the warnings generated for the analysis-core-plugin itself after the move to PMD 5.

With these changes to analysis-core all of the plugins that rely upon it (Checkstyle, PMD, etc.) will have per-user warnings generated automatically if they are using a git scm and running a Maven build.

There are a couple of problems with this implementation. First and foremost, Jenkins' hudson.scm.SCM class lacks blame functionality, so I had to manually use the JGit and Git-Client libraries to actually make the blame calls. Adding support for other VCSes would require a similar effort. Unfortunately the only solution to this problem would be adding new methods to the SCM class which would require support from the core Jenkins developers.

Second, all of the plugins based upon analysis-core need some updating to run blame assignment. Unfortunately the architecture of the freeform builds prevents us from intercepting the ParserResult to run blame analysis on it before it is converted to a BuildResult. On the bright side, the change is minimal. Here is the update that I needed to make to Checkstyle:

--- a/src/main/java/hudson/plugins/checkstyle/CheckStylePublisher.java
+++ b/src/main/java/hudson/plugins/checkstyle/CheckStylePublisher.java
@@ -143,6 +143,7 @@ public class CheckStylePublisher extends HealthAwarePublisher {
        ParserResult project = build.getWorkspace().act(parser);
        logger.logLines(project.getLogMessages());

+               assignBlame(build, project, pattern, logger);
        CheckStyleResult result = new CheckStyleResult(build, getDefaultEncoding(), project, getUseStableBuildAsReference());
        build.getActions().add(new CheckStyleResultAction(build, this, result));

Also, some of the descendent plugins (like FindBugs) override the standard warnings view and thus don't include the User and Commit ID columns. Those plugins would need updates to their jelly files to show the new metadata.

Here are screenshots of the blame support being run against the analysis-core plugin itself.