I think you're right on the tests part. Task that are run by the QA Bot ( https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997 ) could benefit from caching though right?
On Sun, May 5, 2019 at 11:39 AM Dawid Weiss <[email protected]> wrote: > 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] > >
