[
https://issues.apache.org/jira/browse/YETUS-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791768#comment-16791768
]
Allen Wittenauer edited comment on YETUS-809 at 3/13/19 2:44 PM:
-----------------------------------------------------------------
Yeah, that's not going to work so much and it's evident now that for even
simple installations it's questionable if the current code works correctly.
The code assumes that "${module}/target/findbugsXml.xml" is the key
differentiator. We don't want test-patch to run through a bunch of meaningless
code paths if that doesn't exist. However, this also means that children of
the given module may have problems that are never reported if the parent module
does not have any JVM byte code.
Currently, I'm thinking the best way forward is to rip out the skipper. Run
findbugs as usual, but use find to specifically look for
"/target/findbugsXml.xml". If there isn't one found, report it as being
skipped. But if one or more are, process them as though the the dirname of
/target/findbugsXml.xml is a module, regardless of whether it was in the
CHANGED_MODULES list or provided as a MODULE.
A particular kink in this plan is that apparently find's return code isn't
every reliable. On OS X Mojave, find always returns 0, regardless of whether
or not it found anything. So it looks like testing the output of find is going
to be required. Hooray.
P.S., This likely explains why in some instances in the past Hadoop has failed
to report findbugs errors that later showed up in qbt reports. When I have
noticed them in the past, I just assumed that multiple commits involved
triggered the problem or, as is usually the case, the committer just ignored
them.
was (Author: aw):
Yeah, that's not going to work so much and it's evident now that for even
simple installations it's questionable if the current code works correctly.
The code assumes that "${module}/target/findbugsXml.xml" is the key
differentiator. We don't want test-patch to run through a bunch of meaningless
code paths if that doesn't exist. However, this also means that children of
the given module may have problems that are never reported if the parent module
does not have any JVM-processed code.
Currently, I'm thinking the best way forward is to rip out the skipper. Run
findbugs as usual, but use find to specifically look for
"/target/findbugsXml.xml". If there isn't one found, report it as being
skipped. But if one or more are, process them as though the the dirname of
/target/findbugsXml.xml is a module, regardless of whether it was in the
CHANGED_MODULES list or provided as a MODULE.
P.S., This likely explains why in some instances in the past Hadoop has failed
to report findbugs errors that later showed up in qbt reports. When I have
noticed them in the past, I just assumed that multiple commits involved
triggered the problem or, as is usually the case, the committer just ignored
them.
> findbugs isn't finding bugs in qbt-mode
> ---------------------------------------
>
> Key: YETUS-809
> URL: https://issues.apache.org/jira/browse/YETUS-809
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
> Affects Versions: 0.9.0
> Reporter: Allen Wittenauer
> Assignee: Allen Wittenauer
> Priority: Blocker
> Fix For: 0.10.0
>
> Attachments: YETUS-809.00.patch
>
>
> In current Yetus master, test-patch stopped reporting findbugs issues when
> run in qbt mode against the Yetus source tree (there is currently one).
> Individual patch testing does work, however.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
