Lóránt, you asked for a best practice? We have in our builds set the dynamic cache to 0 seconds, but only for our 3-4 own plugins in the buildscript section. We have made sure that our plugin repository (Nexus in our case) is located on a machine 'close' to the developers and on a fast machine with an SSD disk. I'm not sure if what we are doing is the best for you but it works very good for us. Joachim
On Thu, Aug 14, 2014 at 4:36 PM, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > Have you investigated the impact of using a cache timeout of, say, 1 hour? > Would this slow things down too much? > The extra directory listing time may not be significant. > Daz > > > On Wed, Aug 13, 2014 at 4:44 PM, Lóránt Pintér <lorant.pin...@prezi.com> > wrote: > >> Hi, >> >> Most of our builds depend on dynamic versions of internal plugins that >> come from our internal Artifactory. This way we can easily update builds >> without having to change many repos, and it’s all very nice. Except for >> caching. >> >> The default cache timeout of 24 hours is messing with us a lot. It means >> that if I deploy a new version of an internal plugin, some people will get >> the update sometime later today, others only tomorrow. So I need to be on >> alert for the whole 24 hours to see if there was a problem, or ask everyone >> (there’s always somebody not listening) to run a build with >> --refresh-dependencies. >> >> It would make a lot more sense to me if the cache could be set to expire >> at a certain point in time, say, the next time the clock hits 5AM, so >> everybody would get the update in the morning. >> >> I can do this with the current tools by calculating the number of seconds >> until the next 5AM, but it looks weird. >> >> I was wondering if there was some best practice on how to do this better. >> Or if this is a good approach, would it make sense to have some DSL in >> Gradle to express “cache until 5AM” more easily? >> >> Thanks. >> >> -- >> >> *Lóránt Pintér* >> >> Developer at Prezi <http://prezi.com> >> > > > > -- > Darrell (Daz) DeBoer > http://www.gradleware.com >
