Plugin jobs configured to pick up findbugs and checkstyle reports

[Robert Sandell]

I've changed the plugin template for maven to pick up findbugs and checkstyle reports (on ttps://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.

For my own plugins I run checkstyle in the compile phase so I didn't bother adding that option there.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Mark Waite]

Can you explain a little further what that will mean?

When I merge a change to the git-plugin, will the https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ job now fail because findbugs reports are being retrieved? 

Will there be another graph on the page which shows the findbugs output for that job?

Likewise for checkstyle.

Thanks,

Mark Waite

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0bvoSb0CDYCEhhKfiwUHwayZ-mRxaCUNPfZGSC9Gzp7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Sandell]

By default nothing should happen.

If you as a maintainer would want to have findbugs run and/or mark the build as unstable you can ask someone with configure job permissions on jenkins.ci.cloudbees.com to tick one or both of the new checkboxes on the config page of your plugin job. And update your pom to produce xmlOutput for findbugs:

Example:
<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>
            </plugin>
    </plugins>
</build>

If you configure your pom to automatically run findbugs or checkstyle during for example the verify phase the Jenkins job should automatically pick that up.

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEYz1rDjaaJV4j9hSZ0cNVwmFNTxw2oRxOh%2BkOD5Dv3rA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

That sounds great.  Thanks.

As one of the maintainers of the git plugin and the git client plugin, I'd like findbugs reporting enabled on both jobs.  The job is already configured to run findbugs as a standard part of the build process.  I do not want the job to be marked unstable for findbugs warnings.  In the future, that may change, but for now, it is enough to report the findbugs resuls without changing the status of the job.

I do not want checksyle run on either of those projects at this time.

If Nicolas De Loof feels differently, I defer to his preference.

Thanks,
Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0vwdeyt%2BaLqKSfMFicQCnbG2%3DGKHEmmCwyYL%2Bx50ztTA%40mail.gmail.com.

[Robert Sandell]

If it's configured to run when you do mvn install it should be picked up automagically as long as xmlOutput is configured in the pom.

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEk6aq-NLKe-L4C_E17A-btzb%2B0%3DKtae6Er2MNpQJ3i%3Dw%40mail.gmail.com.

[Mark Waite]

It looks like I was wrong.  I thought the two plugins were configured to generate findbugs reports with the "install" goal.  As far as I can see from the jobs I run on my own server, I'm explicitly using the "findbugs" goal.  I'll need to investigate further before the jenkins.ci.cloudbees.com job will show results for those two plugins.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2aMPkNFnJKRbxQc96nzRYM%2BQBPNWLZd0hcjrwq%2BC99kw%40mail.gmail.com.

[Robert Sandell]

I can turn on the findbugs goal for you in the job if you like (that's one of the new checkboxes I added).

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGgrKPAb%2B6nUQrcE-R16-rSxpq4fem4-RHq8cOVygAJmg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[James Nord]

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) 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

[Kanstantsin Shautsou]

Is there any way how to handle this without directly asking some unknown list of persons? Why not just silently enable results parsing?

[Oleg Nenashev]

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 написал:

[Robert Sandell]

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

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d5d9503b-01c0-4665-97ba-0833b42f1d1c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ullrich Hafner]

Can someone with access rights please activate the Git option 'Recursively update submodules‘ for the analysis-suite-plugin on jenkins.ci.cloudbees.com?

Thanks, Ulli 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGgrKPAb%2B6nUQrcE-R16-rSxpq4fem4-RHq8cOVygAJmg%40mail.gmail.com.

[Kanstantsin Shautsou]

Seems CloudBees decided to do it mass wide without discussing with Jenkins community.

<QA-mode>

I tired reviewing https://github.com/oleg-nenashev activity/PRs and exposing this to maillist.

1)  jenkinsci/pom defines findbugs version in property https://github.com/jenkinsci/pom/blob/master/pom.xml#L623 , no need create custom property 

https://github.com/jenkinsci/script-security-plugin/pull/18/files#diff-600376dffeb79835ede4a0b285078036R15 (and many other PRs, part already merged https://github.com/jenkinsci/ssh-credentials-plugin/pull/15 )

2) Naming of strict variable is inconsistent https://github.com/jenkinsci/monitoring-plugin/pull/3#discussion_r34896879 and seems future parent pom changes wasn't discussed in dev list  https://github.com/jenkinsci/maven-plugin/pull/48/files#r34896275  

</QA-mode>

Also, why only FB? Why not enable PMD? Why not silently enable all static analysing collectors for jobs? 

[Kanstantsin Shautsou]

--

Robert Sandell

Software Engineer

CloudBees Inc.

$ git clone https://code.google.com/p/findbugs/

Cloning into 'findbugs'...

remote: Counting objects: 193242, done.

Receiving objects: 100% (193242/193242), 173.58 MiB | 455.00 KiB/s, done.

Resolving deltas: 100% (102972/102972), done.

Checking connectivity... done.

$ cd findbugs/

$ grep findbugsXmlWithMessages -r ./

$

 

$ git clone https://github.com/gleclaire/findbugs-maven-plugin.git

Cloning into 'findbugs-maven-plugin'...

remote: Counting objects: 1533, done.

remote: Total 1533 (delta 0), reused 0 (delta 0), pack-reused 1533

Receiving objects: 100% (1533/1533), 1.09 MiB | 444.00 KiB/s, done.

Resolving deltas: 100% (955/955), done.

Checking connectivity... done.

$ cd findbugs-maven-plugin/

$ grep -i findbugsXmlWithMessages -r ./

$

$ git clone https://github.com/jenkinsci/findbugs-plugin.git

Cloning into 'findbugs-plugin'...

remote: Counting objects: 12411, done.

remote: Total 12411 (delta 0), reused 0 (delta 0), pack-reused 12411

Receiving objects: 100% (12411/12411), 3.68 MiB | 535.00 KiB/s, done.

Resolving deltas: 100% (4870/4870), done.

Checking connectivity... done.

$ grep -i findbugsXmlWithMessages -r ./

.//plugin/src/main/webapp/help-m2.html:      &lt;findbugsXmlWithMessages&gt;true&lt;/findbugsXmlWithMessages&gt;

.//plugin/src/main/webapp/help-m2_zh_TW.html:      &lt;findbugsXmlWithMessages&gt;true&lt;/findbugsXmlWithMessages&gt;

.//plugin/src/main/webapp/help.html:      &lt;findbugsXmlWithMessages&gt;true&lt;/findbugsXmlWithMessages&gt;

.//plugin/src/main/webapp/help_zh_TW.html:      &lt;findbugsXmlWithMessages&gt;true&lt;/findbugsXmlWithMessages&gt;

Where did you get this option?

[evernat]

This option does not exist but is documented in the wiki page (and help files):
https://wiki.jenkins-ci.org/display/JENKINS/FindBugs+Plugin#FindBugsPlugin-HowToUse

Issue created:
https://issues.jenkins-ci.org/browse/JENKINS-29489

Le samedi 18 juillet 2015 16:04:06 UTC+2, Kanstantsin Shautsou a écrit :

Where did you get this option [findbugsXmlWithMessages] ?

[Ullrich Hafner]

This option does exist in older releases of findbugs (2.x.x). It has been removed in 3.0.0 release. 

I think maven ignores configuration options that are unused, so it is ok to let the value as it is...

 

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bdc1168a-e2ac-494a-a26b-93c86ed94235%40googlegroups.com.

[Oleg Nenashev]

Seems CloudBees decided to do it mass wide without discussing with Jenkins community. ... Also, why only FB? Why not enable PMD? Why not silently enable all static analysing collectors for jobs? 

The changes are not "mass wide", but the improvement in pull request builders has been announced by Robert about two weeks ago.

There are pretty much plugins being modified, but the most of them are being maintained by by Jenkins contributors currently working at CloudBees. We want to improve the code quality of the plugins and reduce maintenance efforts by enforcing FindBugs in pull requests. I suppose such activity does not need additional approvals, because there's no binary compatibility loss, Jenkins core dependency changes or any other breaking changes requiring the discussion.

Regarding other plugins... As any other Jenkins contributor, I'm eligible to create a pull request and then to get a feedback from plugin owners and other Jenkins contributors. Nobody merges my PRs without approvals of plugin owners. Even if there are possible improvements in the approach selected by me, I don't think that my pull requests violate any formal or informal contribution rules.

Usage of static analysis has been discussed many times on Jenkins Governance meetings. The summary of these discussions was to encourage static analysis in plugins, so l'm strongly sure these PRs address the general need in a better quality of Jenkins plugins. FindBugs is one of the most popular tools for Java, so IMO it should be considered as an improvement even if it is a first baby step. If you want to integrate other tools, feel free to go forward, any contributions will be appreciated.

jenkinsci/pom defines findbugs version in property https://github.com/jenkinsci/pom/blob/master/pom.xml#L623 , no need create custom property 

Yes, it would be correct to use this property. I was not aware about it, so I introduced my one. It is not very important, because in plugin POMs we will definitely override this property to get newer FindBugs versions on old Jenkins cores. BTW I'll try to adjust my pull requests.

Naming of strict variable is inconsistent

No need to keep the naming consistent (it would be preferable BTW). The current plugin POM architecture is not designed for effectively sharing FindBugs configurations across plugins, because they depend on Jenkins cores. We need a huge rework oof parent POMs architecture to make shared configs usable. Currently plugins need to manage static analysis flows on their own.

 

... and seems future parent pom changes wasn't discussed in dev list  https://github.com/jenkinsci/maven-plugin/pull/48/files#r34896275  

Yes, this proposal has not been discussed yet. I'm planning to start the discussion only when I have some time to handle it's follow ups.

 

воскресенье, 19 июля 2015 г., 17:07:44 UTC+3 пользователь Ullrich Hafner написал:

[Kanstantsin Shautsou]

On Jul 19, 2015, at 21:17, Oleg Nenashev <o.v.ne...@gmail.com> wrote:

Seems CloudBees decided to do it mass wide without discussing with Jenkins community. ... Also, why only FB? Why not enable PMD? Why not silently enable all static analysing collectors for jobs? 

The changes are not "mass wide", but the improvement in pull request builders has been announced by Robert about two weeks ago.

Yes, in form “I changed”. 

There are pretty much plugins being modified, but the most of them are being maintained by by Jenkins contributors currently working at CloudBees. We want to improve the code quality of the plugins and reduce maintenance efforts by enforcing FindBugs in pull requests.

Excellent, why not document on Jenkins Project wiki then? So all developers may help you with such activity. 

Some maintainers already raised that 3.0.1 doesn’t work with French. It would be good to document such thing. 

I suppose such activity does not need additional approvals, because there's no binary compatibility loss, Jenkins core dependency changes or any other breaking changes requiring the discussion.

On one hand you want improve/update core, on other not.

Regarding other plugins... As any other Jenkins contributor, I'm eligible to create a pull request and then to get a feedback from plugin owners and other Jenkins contributors. Nobody merges my PRs without approvals of plugin owners. Even if there are possible improvements in the approach selected by me, I don't think that my pull requests violate any formal or informal contribution rules.

You are right, but i think it will be not difficult to announce/discuss such changes in central place.

Usage of static analysis has been discussed many times on Jenkins Governance meetings.

Seems i missed something. Could you point me on some date/log?

The summary of these discussions was to encourage static analysis in plugins, so l'm strongly sure these PRs address the general need in a better quality of Jenkins plugins. FindBugs is one of the most popular tools for Java, so IMO it should be considered as an improvement even if it is a first baby step. If you want to integrate other tools, feel free to go forward, any contributions will be appreciated.

As non CB person i have no access to job configuration and ability to install/update static analysing plugins. In my plugins i tried enable PMD - has no job parsing and checkstyle - failed build even with false failing option (will try investigate more, maybe it’s job configuration).

jenkinsci/pom defines findbugs version in property https://github.com/jenkinsci/pom/blob/master/pom.xml#L623 , no need create custom property 

Yes, it would be correct to use this property. I was not aware about it, so I introduced my one. It is not very important,

https://github.com/jenkinsci/jenkins/pull/1487
IMHO keeping less chaos in poms is the way to improvements. 

because in plugin POMs we will definitely override this property to get newer FindBugs versions on old Jenkins cores. BTW I'll try to adjust my pull requests.

Now you have to spend more time on it ;(

Naming of strict variable is inconsistent

No need to keep the naming consistent (it would be preferable BTW). The current plugin POM architecture is not designed for effectively sharing FindBugs configurations across plugins, because they depend on Jenkins cores.

imho current pom architecture has clear property naming convention. 

We need a huge rework oof parent POMs architecture to make shared configs usable.

Not sure what really need to be hugely reworked rather then cutting ‘pom’ project. 

There are also some redundant profiles, probably you need modify them. 

Currently plugins need to manage static analysis flows on their own.

 

... and seems future parent pom changes wasn't discussed in dev list  https://github.com/jenkinsci/maven-plugin/pull/48/files#r34896275  

Yes, this proposal has not been discussed yet. I'm planning to start the discussion only when I have some time to handle it's follow ups.

IMO If you discuss it firstly you will save everyones time.

Does anyone compared Efforts FB value? Default vs Max?

[Oleg Nenashev]

I've published the POM file template, which I've used in my patches: https://gist.github.com/oleg-nenashev/9be4c1d7a9652513808d. Kostya does not agree with several configs, but we can discuss them now.

> Does anyone compared Efforts FB value? Default vs Max?

This is a subject for the global configuration. Now we suffer from hundreds issues in the "Default" mode, so I think it should be enough for the first baby step.

In the global configuration we should also consider PMD, so it's a topic for another discussion. I hope to start it soon and probably to raise it on the Governance meeting.

> https://github.com/jenkinsci/jenkins/pull/1487

IMHO keeping less chaos in poms is the way to improvements. 

done

> Now you have to spend more time on it ;(

It was not comparable to the bugfixing time :)

> Not sure what really need to be hugely reworked rather then cutting ‘pom’ project. 

There are also some redundant profiles, probably you need modify them.

Our parent POM is bundled to Jenkins core version => no reliable way to enhance the build flow without bumping the core

воскресенье, 19 июля 2015 г., 21:51:13 UTC+3 пользователь Kanstantsin Shautsou написал: