I think most of the build time is spent in tests. Since we're using randomization I don't think you'd gain much from caches?
Dawid On Sun, May 5, 2019 at 8:24 PM Varun Thacker <[email protected]> wrote: > > Over the last few months, I've realized the power of build caches. > > In the future could we have remote caches for Jenkins? In which case the > Lucene/Solr QA bot will be significantly faster as well? And then it could > just run against all patches and even block commits that violate it? > > On Sun, May 5, 2019 at 9:37 AM Erick Erickson <[email protected]> wrote: >> >> I don’t know enough about the differences to even think consider complaining. >> >> Is the proposal that we use Gradle for master and continue to use ant for >> 8x? As long as the two build systems can exist side by side (i.e. we can >> build master by executing some Gradle target and continue to build 8x with >> Ant like we always have) the minor inconvenience doesn’t merit standing in >> the way of progress. >> >> If that’s the case I don’t particularly care if we continue to use Ant with >> 8x forever. Or maybe some ambitious person can work on bringing 8x to Gradle >> after it has some mileage on master. >> >> And I have great faith that you wouldn’t be putting in the work unless you >> thought it was worth it ;) >> >> Erick >> >> > On May 4, 2019, at 10:31 PM, Mark Miller <[email protected]> wrote: >> > >> > We already dump out to groovy to do anything interesting, so I doubt there >> > is much we can't replicate. >> > >> > - Mark >> > >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya >> > <[email protected]> wrote: >> > Would beasting of tests be possible through gradle? >> > >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <[email protected]> wrote: >> > > >> > > I looked into this a little more. >> > > >> > > Seems if we just do it with master and going forward, we don’t need >> > > multi version support - Uwe seems to have taken it out with the move to >> > > Java 11? >> > > >> > > I can handle regenerate. >> > > >> > > The other quality checks shouldn’t be crazy. >> > > >> > > So I guess we can probably do this, but before I focus on BS details, >> > > please speak up if you hate the idea of Gradle and you have the clout to >> > > stop it. >> > > >> > > >> > > Mark >> > > >> > > >> > > >> > > >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller <[email protected]> wrote: >> > >> >> > >> I've got my own lucene-solr gradle branch as well. >> > >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but >> > >> also made some changes. >> > >> >> > >> * Similar to above above, I don't move the src files so it can keep >> > >> things up to date without lots of pain. >> > >> * I used a plugin that lets us define versions in a root props file >> > >> like we currently do and ensures we use the same versions in all >> > >> modules even after auto conflict resolution (unlike gradle by default) >> > >> * It also locks versions so we can continue to pay attention to scary >> > >> automatic dependency resolution changes >> > >> * implementation and api used instead of compile >> > >> * Things build and the majority of tests pass (Lucene's >> > >> TestVirtualMethod does not for example) >> > >> >> > >> If someone like Uwe is serious about helping out with fun extras >> > >> (regenerating sources, extracting data from ICU, quality checks, >> > >> documentation (XSLT)), I'd look at contributing. >> > >> >> > >> - Mark >> > >> >> > >> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh <[email protected]> >> > >> wrote: >> > >>> >> > >>> Cool Diego, >> > >>> >> > >>> I will take a look on this. Thanks a lot! >> > >> >> > >> >> > >> >> > >> -- >> > >> - Mark >> > >> >> > >> http://about.me/markrmiller >> > > >> > > -- >> > > - Mark >> > > >> > > http://about.me/markrmiller >> > >> > >> > -- >> > - Mark >> > >> > http://about.me/markrmiller >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
