Got it. Thanks a lot Sean and Allen for explaining. On Mon, Jan 25, 2016 at 7:58 PM, Allen Wittenauer <[email protected]> wrote:
> I think you pretty much covered it Sean. haha. > > It’s probably worth mentioning that the ability of Yetus to > shrink/grow the scope of how much work it does is a factor of a few things: > > a) the build system in use (esp post-YETUS-70; committed > today to master) > b) the personality > c) the plug-in doing the work > > Maven, for example, has been written to primarily focus on > individual pom.xml’s as dividing points. In contrast, our gradle support > only covers building everything. In general, personalities know better and > so can override much of that behavior, even on a per plug-in basis. For > example, when Hadoop does a compile, it uses base common directories > (CHANGED_UNION_MODULES in Yetus-jargon) rather than individual modules when > it can so that maven dependencies are handled better. Some plug-ins such > as shellcheck will tend to process everything in one go, regardless of the > personality’s direction though since there is no compile phase and breakups > by modules are fairly meaniningless. > > In the case of checkstyle in particular, probably worth mentioning > it got a lot smarter in master and the content of those individual files > and what we report to the user reflects that. We’ve been slowing cleaning > up that code to more consistent with the rest of Yetus too, since a lot of > that was written before a lot of the APIs existed. > > > On Jan 25, 2016, at 9:07 AM, Sean Busbey <[email protected]> wrote: > > > > Hi Appy! > > > > I'm copying in dev@yetus, since those folks are better positioned to > answer > > these questions. > > > > The output for checkstyle is only present on that build because the patch > > that it is testing only changed the hbase-server module. By default Yetus > > only does correctness checks on modules that have been changed. Currently > > the HBase personality maintains this behavior. > > > > It might help explain the five files to arrange them in terms of the > phases > > Yetus Precommit uses when evaluating a patch[1] (I've skipped phases > > unrelated to checkstyle): > > > > - post-compile for branch (e.g. master, branch-1, branch-1.2, etc) > > > > after checking out and installing everything, changed modules have > > checkstyle run against the _current_ state of the repo > > > > -- the checkstyle results go into branch-checkstyle-${module_name}.txt > > -- the console output of running the checkstyle command (since hbase uses > > maven) goes into maven-branch-checkstyle-${module_name}.txt > > > > - post-compile for patch (i.e. after applying the changes to be tested) > > > > -- the checkstyle results go into patch-checkstyle-${module_name}.txt > > -- the console output of running the checkstyle command (since hbase uses > > maven) goes into maven-branch-checkstyle-${module_name}.txt > > -- the difference between the branch and patch versions of the checkstyle > > output is calculated[2] and stored in diff-checkstyle-${module}.txt > > > > > > > > Sounds like we (Yetus) should build some overview docs on plugins. Thanks > > for the question! > > > > [1]: http://yetus.apache.org/documentation/0.1.0/precommit-architecture/ > > [2]: > > > https://github.com/apache/yetus/blob/master/precommit/test-patch.d/checkstyle.sh#L65 > > > > On Sun, Jan 24, 2016 at 5:44 PM, Apekshit Sharma <[email protected]> > wrote: > > > >> So looking at artifacts of a build ( > >> > >> > https://builds.apache.org/job/PreCommit-HBASE-Build/261/artifact/patchprocess/ > >> ), > >> I see checkstyle for only 'hbase-server', why so? Is it that we haven't > >> turned it on for other modules yet? > >> > >> Also I see following five different files, what is each one for? > >> > >> - branch-checkstyle-hbase-server.txt > >> - diff-checkstyle-hbase-server.txt > >> - maven-branch-checkstyle-hbase-server.txt > >> - maven-patch-checkstyle-hbase-server.txt > >> - patch-checkstyle-hbase-server.txt > >> > >> > >> - Appy > >> > > > > > > > > -- > > Sean > > -- Regards Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California | 650-963-6311
