Reviewing the prior thread, it was sort of 60/40 but ambiguous enough that neither fast nor slow default is the clear choice. The slightly bigger camp was people who want a fast default build that is more friendly to new contributors (specifically to *remove* barriers to opening a PR) and the other side was folks who wanted local builds to be as nearly identical to the precommit as possible.
Our current situation is neither - the default is slow but still not what the precommit does. So the thing that did have consensus was that we should have the fast and slow paths well-defined with a single simple invocation so we can easily toggle with -Dslow and -Dfast or some such. Next time I am waiting for slow builds maybe I'll set some of this up... but I already have elaborate [multi-command] fast build invocations in my bash history :-) Is there already a JIRA for setting up the fast and slow paths? Kenn On Wed, Oct 11, 2017 at 3:14 PM, Lukasz Cwik <[email protected]> wrote: > 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 <[email protected]> > 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 < > > [email protected]> 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) > > > > > >
