I was under the impression that making the build faster was discussed before and it was suggested that we would add a profile which was a fast build option that skipped the majority of checks for developers instead of making it the default. The reason was along the lines that we want new developers to go through the entire build process to get the maximum amount of validation before they open a PR while a seasoned contributor would learn of the profile and use it selectively. Until that profile is added, there are many ways to disable running specific checks. For example with findbugs it is -Dfindbugs.skip=true and maybe we should just let people customize running their command themselves for advanced users.
On Mon, Oct 9, 2017 at 1:42 PM, Kenneth Knowles <k...@google.com.invalid> wrote: > 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) > > >
