Kostya, as mentioned before in this thread; the job does pick up
findbugs.xml without any job-config changes if your pom is configured to
produce one. It's the marking as unstable that requires a config change by
someone with permissions, or if you don't want that clutter in you pom.
Updating my example above to contain the FB execution:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<xmlOutput>true</xmlOutput>
<findbugsXmlWithMessages>true</findbugsXmlWithMessages>
<failOnError>false</failOnError>
</configuration>
<executions>
<!--
Ensures that FindBugs inspects source code when project
is compiled.
-->
<execution>
<id>analyze-compile</id>
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
If you change failOnError to true the build should be marked as failed if
it has any FB issues.
/B
On Sun, Jul 5, 2015 at 10:15 AM, Oleg Nenashev <[email protected]>
wrote:
> Kostya, the best way would be to update Jenkins parent POM and to publish
> results from it. BTW all plugins should be updated to the new parent
> version, which is not possible in particular cases
>
> суббота, 4 июля 2015 г., 17:14:51 UTC+3 пользователь Kanstantsin Shautsou
> написал:
>
>>
>>
>> On Saturday, July 4, 2015 at 5:04:14 PM UTC+3, James Nord wrote:
>>>
>>> On 02/07/2015 15:45, Robert Sandell wrote:
>>>
>>> I've changed the plugin template for maven to pick up findbugs and
>>> checkstyle reports* (on ttps://jenkins.ci.cloudbees.com
>>> <http://jenkins.ci.cloudbees.com>)* if any is generated by the build.
>>> So if plugin builds starts to fail for that reason you know who to blame ;)
>>> But it shouldn't change anything for existing jobs unless you actively do
>>> something.
>>>
>>> I've also added config options to run findbugs and mark the build as
>>> unstable if any findbugs issues are found, so maintainers can opt in for
>>> that if they want to.
>>>
>>>
>>> I don't think that maintainers have access to configure jobs on here do
>>> they (as a maintainer I could never change anything on the jenkins.ci.cb.c
>>> - which may be as I had no login for that system...)
>>>
>>> So I guess this is a case of ask one of the cloudbees people to turn it
>>> on?
>>>
>>> /James
>>>
>> Is there any way how to handle this without directly asking some unknown
>> list of persons? Why not just silently enable results parsing?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/d5d9503b-01c0-4665-97ba-0833b42f1d1c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/d5d9503b-01c0-4665-97ba-0833b42f1d1c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Robert Sandell
*Software Engineer*
*CloudBees Inc.*
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3AYr__NHCAyoywGcOrgF8WxS%2BL0br_EkthZe%2BoRGhhUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
