Two possibilities: (1) follow through on implementation to make the default checks just compile and unit tests, with -D allchecks add findbugs, checkstyle, etc, with longer checks run by Jenkins and during merge (2) bind findbugs to the test or verify phases, which make more sense anyhow
I support both. Incidentally, that invocation of yours has an issue I just discovered, which is that modules which depend on both sdks/java/core and sdks/common/* (soon to be model/*) will not rebuild the generated classes for sdks/common/* so you'll get compile errors. And is the timeline tool time consuming itself? I would love to always generate it or at least always have a skipped config for it. On Mon, Oct 9, 2017 at 12:47 PM, Eugene Kirpichov < kirpic...@google.com.invalid> wrote: > I typically run the following command to sanity-check a PR: > > $ mvn clean compile test-compile -am -amd -Prelease -fae -pl > 'sdks/java/core' > > This command takes 8 minutes (and 4 minutes with -T 1C) and I think it > shouldn't take that long. > > I used the wonderful maven profiling tool > https://github.com/takari/maven-timeline/ and it produced a timeline html > that almost completely consists of running "findbugs". > > What can we do to ease the impact of findbugs on build performance? It > seems that it's legitimately doing a bunch of stuff - applying hundreds of > analyzers to thousands of classes, and taking a few ms per analyzer per > class on average, which seems not unreasonable. > > Perhaps we can manually construct a smaller list of findbugs analyzers we > actually want to run? (we should definitely keep findbugs in general - I've > seen it prevent several serious bugs just in my PRs) >
