Printing static code analysis errors in log #236
Conversation
|
Would be nice to have several downstream pull requests demonstrating the enhancement |
jenkinsci/gerrit-trigger-plugin#402 |
|
@oleg-nenashev I added profiles to the parent. But I when I try it out in jenkinsci/generic-webhook-trigger-plugin#137 they are not getting activated. I use Edit: Seems only system properties can be used to activate profiles: https://stackoverflow.com/questions/5676231/how-to-activate-profile-by-means-of-maven-property Perhaps I'll just change the PR so that the <violations.maxViolations>0</violations.maxViolations>
<findbugs.failOnError>false</findbugs.failOnError>
<spotbugs.failOnError>false</spotbugs.failOnError>Edit2: Changed implementation to the above. |
tomasbjerre
changed the title
|
@tomasbjerre force pushing makes it harder to reivew 😓 If you wish for the commit to be squashed it can be done so. |
To allow control over column widths.
There was a problem hiding this comment.
I am generally against a change like this for the following reasons:
- it unconditionally adds another plugin execution into the lifecycle (for questionable gain - see Needed a dep on jenkins.war itself for use from hpi:run #3)
- it is not intelligent about which issues it will find - thus if you actually have some test files (say in a checksytle/warnings plugin then it will pick those ut)
but mainly:
- Jenkins already has a lovely way to report these anyway - all plugins can enable these reports and all users can view them (including trends today) whn the plugin is built on ci.jenkins.io
I can see the potential use when you are developing locally and running mvn verify - but in reality does anyone not use an IDE which can enable all of this directly in the IDE to prevent you even having to drop to the command line?
|
@tomasbjerre Thanks for this proposal! Having to search what the stupid error codes mean is annoying, and this looks pretty helpful in that case. However, beyond concerns like James' around the functionality and usefulness itself, this looks pretty much unproven: This has no known uses on mvnrepository.com, no stars or forks on GitHub, and the only notable uses GitHub identifies are plugins and other components by its own maintainer. Which means to me that, so far, the plugin basically just had to deal with issues its maintainer threw at it, and may well have problems when exposed to the wider plugin ecosystem. I realize this is kind of a chicken-and-egg problem for Tomas as a maintainer, but I'd really like to see something be more battle-tested before we roll it out this widely. I would propose you open a discussion on the dev list asking for plugin maintainers' support for this change, as ultimately it's plugin maintainers who end up using this (and having to deal with the resulting problems). And finally, even if there's no strong support, individual plugin maintainer can always choose to use this -- they just wouldn't get it through the parent POM. |
|
There is only one way to get it battle tested :) |
just seen @uhafner's analysis reports where never installed or have been uninstalled on the server :-o |
|
They are still installed, e.g. see https://ci.jenkins.io/job/Plugins/job/analysis-model/job/master/718/spotbugs/ |
|
I find it safer to get this "battle tested" on handfull of the plugins/components first and only promote it to parent-pom for everyone after positive reception. |
The build log may look like: