[ovirt-devel] Findbugs on master patches

David Caro dcaro at redhat.com
Wed Aug 12 15:29:27 UTC 2015


On 08/12, Yevgeny Zaspitsky wrote:
> The findbugs failure is related to patch set 1, which was previously was
> marked by Jenkins as +1. If that wasn't +1'ed, we would've wait until
> Jenkins job is finished, but since it has +1 we were under impression that
> the patch is OK.

You are right, the findbugs was triggered by the verified +1 on patch 1.

> Looks like findbugs job was triggered by Verified+1, whereas test were run
> upon patch set upload. IMHO the split between the jobs makes their behavior
> misleading.

Agree, but so far there's no agreement on the flow for it, and there's no
effort being done to reach that agreement (it's on hold) so it will not change
any time soon. I think we should drop the triggering by flag, or make it
generic but not mix both. That's why I wanted to introduce the workflow flag,
to trigger only by that flag on demand of the reviewer.

Feel free to try and start that discussion again

> BTW, what was merged is patch set 2, which wasn't checked by findbugs at
> all.
> 
> On Wed, Aug 12, 2015 at 3:42 PM, David Caro <dcaro at redhat.com> wrote:
> 
> > On 08/12, Yevgeny Zaspitsky wrote:
> > > My bad, sorry. The findbugs job runs indeed.
> > >
> > > However look at that patch https://gerrit.ovirt.org/#/c/44604/ .
> > > Patch set 1 got Continuous-Integration+1 from Jenkins after running unit
> > > tests and then, much later,
> >
> > That much later is after merge, the findbugs ran once the patch was
> > merged. You
> > should understand that each event triggers a tests run, and for each tests
> > run
> > you get only one review. In this case the tests that check the code when
> > you
> > send the patch passed, but the ones that check the code after it's merged
> > failed.
> >
> >
> > > Jenkins changed its mind and gave -1 after
> > > findbugs job has finished.
> > > IMHO that's is a misleading behavior.
> > >
> > > Regards,
> > > Yevgeny
> > >
> > > On Wed, Aug 12, 2015 at 12:12 PM, Sandro Bonazzola <sbonazzo at redhat.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Tue, Aug 11, 2015 at 6:13 PM, Yevgeny Zaspitsky <
> > yzaspits at redhat.com>
> > > > wrote:
> > > >
> > > >> Hi All,
> > > >>
> > > >> Seems like recently Jenkins has stopped running findbugs check on the
> > > >> patches before they get merged into master. Although that could save
> > some
> > > >> Jenkins resources and make the its reaction faster, that makes the
> > > >> integration (with master) check less effective.
> > > >>
> > > >> Was that done on purpose? Can that be restored for master patches?
> > > >>
> > > >>
> > > > AFAIK findbugs is still up and running:
> > > > http://jenkins.ovirt.org/search/?q=find-bugs
> > > > Have you any specific patch as example?
> > > >
> > > >
> > > >
> > > >
> > > >> Regards,
> > > >> Yevgeny
> > > >>
> > > >> _______________________________________________
> > > >> Devel mailing list
> > > >> Devel at ovirt.org
> > > >> http://lists.ovirt.org/mailman/listinfo/devel
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Sandro Bonazzola
> > > > Better technology. Faster innovation. Powered by community
> > collaboration.
> > > > See how it works at redhat.com
> > > >
> >
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> > --
> > David Caro
> >
> > Red Hat S.L.
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> >
> > Tel.: +420 532 294 605
> > Email: dcaro at redhat.com
> > Web: www.redhat.com
> > RHT Global #: 82-62605
> >

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20150812/e033f6af/attachment.sig>


More information about the Infra mailing list