-
New Feature
-
Resolution: Fixed
-
Minor
-
None
Checkstyle warnings generally arise because a developer is running an auto format that is not in sync with a project's standard, or they are choosing not to format.
The current checkstyle analysis tend to display where warnings are, but not where they come from. What I would like is to see is a 'Warnings By User' analysis (user is the commit user).
Then you can easily see who's IDE is out of whack, or who's being slack - even if that's happens to be me 
Example:
Warnings by User
- mjackson: 23 warnings
- jsmith: 1,634 warnings
- jdoe: 432 warning
New Warnings by User (build #30)
- jsmith: 84 warnings
- jdoe: 4 warnings
Cheers for listening.
- is blocking
-
JENKINS-46641 Git Blame kills slave (memory overload)
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-6748] Analysis of Checkstyle Warnings per User
ahhughes
added a comment - 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
| User | Warnings |
|---|---|
| mjackson | 23 |
| jsmith | 1,634 |
| jdoe | 432 |
Change in Warnings from Build #37 per User
| User | Warnings |
|---|---|
| mjackson | -6 |
| jdoe | +38 |
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?
ahhughes
added a comment - 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
User
Warnings
mjackson
23
jsmith
1,634
jdoe
432
Change in Warnings from Build #37 per User
User
Warnings
mjackson
-6
jdoe
+38
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? 
Martin Hanus
added a comment - 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.
Martin Hanus
added a comment - 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.
Igor Stepanov
added a comment - 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.
Igor Stepanov
added a comment - 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. 
John Gibson
added a comment - 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.
John Gibson
added a comment - 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. John Gibson
added a comment - Here are screenshots of the blame support being run against the analysis-core plugin itself.
John Gibson
added a comment - Here are screenshots of the blame support being run against the analysis-core plugin itself. @John: Thanks for providing a first implementation of the feature for git! I'll have a look at it and check if there is an option to add new functionality to the SCM API.
Code changed in jenkins
User: Ulli Hafner
Path:
analysis-core.iml
pom.xml
src/main/java/hudson/plugins/analysis/core/AbstractProjectAction.java
src/main/java/hudson/plugins/analysis/core/HealthAwarePublisher.java
src/main/java/hudson/plugins/analysis/graph/AnnotationsByUserGraph.java
src/main/java/hudson/plugins/analysis/graph/BuildResultGraph.java
src/main/java/hudson/plugins/analysis/graph/CategoryBuildResultGraph.java
src/main/java/hudson/plugins/analysis/graph/UserBuildResultGraph.java
src/main/java/hudson/plugins/analysis/util/AbstractBlamer.java
src/main/java/hudson/plugins/analysis/util/BlameFactory.java
src/main/java/hudson/plugins/analysis/util/BlameInterface.java
src/main/java/hudson/plugins/analysis/util/GitBlamer.java
src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java
src/main/java/hudson/plugins/analysis/util/model/AnnotationContainer.java
src/main/java/hudson/plugins/analysis/util/model/Author.java
src/main/java/hudson/plugins/analysis/util/model/FileAnnotation.java
src/main/java/hudson/plugins/analysis/views/AuthorDetail.java
src/main/java/hudson/plugins/analysis/views/DetailFactory.java
src/main/java/hudson/plugins/analysis/views/TabDetail.java
src/main/resources/hudson/plugins/analysis/views/AuthorDetail/index.jelly
src/main/resources/hudson/plugins/analysis/views/TabDetail/authors.jelly
src/main/resources/hudson/plugins/analysis/views/TabDetail/warnings.jelly
src/main/resources/result/main.jelly
http://jenkins-ci.org/commit/analysis-core-plugin/64e45dc705970bac9bdb3cd1fdbe94516bccf61f
Log:
JENKINS-6748 Integrated the work of Lukas Krose/John Gibson:
show culprint of warnings (for git).
Compare: https://github.com/jenkinsci/analysis-core-plugin/compare/a3d48bf5f198^...64e45dc70597
Code changed in jenkins
User: Ulli Hafner
Path:
analysis-core
http://jenkins-ci.org/commit/analysis-suite-plugin/a247381f12197677ba7fb932ebe636fa17191604
Log:
JENKINS-6748 Integrated the work of Lukas Krose/John Gibson:
show culprint of warnings (for git).
mirza zeyrek
added a comment - Looks very nice but I have a question. That might be an edge case but just wondering.
What will happen if devs use auto code fixer like phpcbf and commited styling changes ? Will they be shown as responsible for the other errors in those changed lines ?
mirza zeyrek
added a comment - Looks very nice but I have a question. That might be an edge case but just wondering.
What will happen if devs use auto code fixer like phpcbf and commited styling changes ? Will they be shown as responsible for the other errors in those changed lines ? This depends on the context: if the warning is resolved as a new one, then yes. Otherwise: no.
Unfortunately this change makes some assumptions about the environment that are not always true. Our Jenkins jobs are now abending with this:
Recording test results
[Boolean condition] checking [true] against [^(1|y|yes|t|true|on|run)$] (origin token: ${ENV,var="postbuild_scan_for_compiler_warnings"} )
Run condition [Boolean condition] enabling perform for step [[Scan for compiler warnings]]
[WARNINGS] Parsing warnings in console log with parser Buckminster
<Git Blamer> Using GitBlamer to create author and commit information for all warnings.
<Git Blamer> Getting blame results for all files in /scratch/jenkins_slave/workspace/GDA.master-junit.tests.
> git rev-parse 5977ce7cd6b4f4be8bba6c5226655c12e50340ca^{commit} # timeout=10
ERROR: [flexible-publish] Scan for compiler warnings (hudson.plugins.warnings.WarningsPublisher@616e8ea4) aborted due to exception
hudson.plugins.git.GitException: Command "git rev-parse 5977ce7cd6b4f4be8bba6c5226655c12e50340ca^{commit}" returned status code 128:
stdout:
stderr: fatal: Not a git repository (or any parent up to mount point /scratch)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1903)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1871)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1867)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1512)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1524)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:718)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at hudson.plugins.analysis.util.GitBlamer.getHead(GitBlamer.java:70)
at hudson.plugins.analysis.util.GitBlamer.loadBlameResultsForFiles(GitBlamer.java:58)
at hudson.plugins.analysis.util.GitBlamer.blame(GitBlamer.java:52)
at hudson.plugins.analysis.util.AbstractBlamer$1.invoke(AbstractBlamer.java:66)
at hudson.plugins.analysis.util.AbstractBlamer$1.invoke(AbstractBlamer.java:63)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2750)
at hudson.remoting.UserRequest.perform(UserRequest.java:181)
at hudson.remoting.UserRequest.perform(UserRequest.java:52)
at hudson.remoting.Request$2.run(Request.java:336)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ......remote call to DLS-RHEL6w-1(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1554)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:281)
at hudson.remoting.Channel.call(Channel.java:839)
at hudson.FilePath.act(FilePath.java:987)
at hudson.FilePath.act(FilePath.java:976)
at hudson.plugins.analysis.util.AbstractBlamer.invokeBlamer(AbstractBlamer.java:63)
at hudson.plugins.analysis.util.AbstractBlamer.blame(AbstractBlamer.java:49)
at hudson.plugins.analysis.core.HealthAwarePublisher.blame(HealthAwarePublisher.java:109)
at hudson.plugins.warnings.WarningsPublisher.annotate(WarningsPublisher.java:432)
at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(WarningsPublisher.java:378)
at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:312)
at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:69)
at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:298)
at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
at org.jenkins_ci.plugins.flexible_publish.builder.FailAtEndBuilder.perform(FailAtEndBuilder.java:104)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)
at org.jenkins_ci.plugins.flexible_publish.strategy.FailAtEndExecutionStrategy.perform(FailAtEndExecutionStrategy.java:85)
at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)
at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:730)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:676)
at hudson.model.Build$BuildExecution.post2(Build.java:186)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:621)
at hudson.model.Run.execute(Run.java:1760)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
[Boolean condition] checking [true] against [^(1|y|yes|t|true|on|run)$] (origin token: ${ENV,var="postbuild_scan_for_open_tasks"} )
Run condition [Boolean condition] enabling perform for step [[Scan workspace for open tasks]]
[TASKS] Skipping publisher since build result is FAILURE
Build step 'Flexible publish' changed build result to FAILURE
Build step 'Flexible publish' marked build as failure
Finished: FAILURE
The problem, I suspect, is that some of the code under test comes frmo a Git repository, but is checked out by a bash script, and not using the Jenkins SCM plugin.
Matthew Webber
added a comment - - edited Unfortunately this change makes some assumptions about the environment that are not always true. Our Jenkins jobs are now abending with this:
Recording test results
[Boolean condition] checking [true] against [^(1|y|yes|t|true|on|run)$] (origin token: ${ENV,var="postbuild_scan_for_compiler_warnings"} )
Run condition [Boolean condition] enabling perform for step [[Scan for compiler warnings]]
[WARNINGS] Parsing warnings in console log with parser Buckminster
<Git Blamer> Using GitBlamer to create author and commit information for all warnings.
<Git Blamer> Getting blame results for all files in /scratch/jenkins_slave/workspace/GDA.master-junit.tests.
> git rev-parse 5977ce7cd6b4f4be8bba6c5226655c12e50340ca^{commit} # timeout=10
ERROR: [flexible-publish] Scan for compiler warnings (hudson.plugins.warnings.WarningsPublisher@616e8ea4) aborted due to exception
hudson.plugins.git.GitException: Command "git rev-parse 5977ce7cd6b4f4be8bba6c5226655c12e50340ca^{commit}" returned status code 128:
stdout:
stderr: fatal: Not a git repository (or any parent up to mount point /scratch)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1903)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1871)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1867)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1512)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1524)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:718)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at hudson.plugins.analysis.util.GitBlamer.getHead(GitBlamer.java:70)
at hudson.plugins.analysis.util.GitBlamer.loadBlameResultsForFiles(GitBlamer.java:58)
at hudson.plugins.analysis.util.GitBlamer.blame(GitBlamer.java:52)
at hudson.plugins.analysis.util.AbstractBlamer$1.invoke(AbstractBlamer.java:66)
at hudson.plugins.analysis.util.AbstractBlamer$1.invoke(AbstractBlamer.java:63)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2750)
at hudson.remoting.UserRequest.perform(UserRequest.java:181)
at hudson.remoting.UserRequest.perform(UserRequest.java:52)
at hudson.remoting.Request$2.run(Request.java:336)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ......remote call to DLS-RHEL6w-1(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1554)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:281)
at hudson.remoting.Channel.call(Channel.java:839)
at hudson.FilePath.act(FilePath.java:987)
at hudson.FilePath.act(FilePath.java:976)
at hudson.plugins.analysis.util.AbstractBlamer.invokeBlamer(AbstractBlamer.java:63)
at hudson.plugins.analysis.util.AbstractBlamer.blame(AbstractBlamer.java:49)
at hudson.plugins.analysis.core.HealthAwarePublisher.blame(HealthAwarePublisher.java:109)
at hudson.plugins.warnings.WarningsPublisher.annotate(WarningsPublisher.java:432)
at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(WarningsPublisher.java:378)
at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:312)
at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:69)
at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:298)
at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
at org.jenkins_ci.plugins.flexible_publish.builder.FailAtEndBuilder.perform(FailAtEndBuilder.java:104)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)
at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)
at org.jenkins_ci.plugins.flexible_publish.strategy.FailAtEndExecutionStrategy.perform(FailAtEndExecutionStrategy.java:85)
at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)
at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:730)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:676)
at hudson.model.Build$BuildExecution.post2(Build.java:186)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:621)
at hudson.model.Run.execute(Run.java:1760)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
[Boolean condition] checking [true] against [^(1|y|yes|t|true|on|run)$] (origin token: ${ENV,var="postbuild_scan_for_open_tasks"} )
Run condition [Boolean condition] enabling perform for step [[Scan workspace for open tasks]]
[TASKS] Skipping publisher since build result is FAILURE
Build step 'Flexible publish' changed build result to FAILURE
Build step 'Flexible publish' marked build as failure
Finished: FAILURE
The problem, I suspect, is that some of the code under test comes frmo a Git repository, but is checked out by a bash script, and not using the Jenkins SCM plugin. Please create a new bug issue after a feature issue has been resolved. Otherwise it is hard to follow the actual problems.
PS: This exception has been fixed in 1.89 of analysis-core see JENKINS-45572
Matthew Webber
added a comment - Apologies, I agree it should be a new bug.
I can report that 1.89 of analysis-core does indeed fix the problem.
Matthew Webber
added a comment - Apologies, I agree it should be a new bug.
I can report that 1.89 of analysis-core does indeed fix the problem. 
Daniel Sobral
added a comment - "Skipping warnings blame since pipelines do not have an SCM link." – does that mean this feature isn't supported at all from a Jenkins Pipeline? I don't understand the issue – I do have a checked out git repository.
Daniel Sobral
added a comment - "Skipping warnings blame since pipelines do not have an SCM link." – does that mean this feature isn't supported at all from a Jenkins Pipeline? I don't understand the issue – I do have a checked out git repository. It is not supported since pipelines may use several SCMs. The API does not return an SCM instance right now, so this implementation will be more complex. (It is feasible, just not as simple as in freestyle builds).
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?