On 14 Aug 2014, at 8:44 am, 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? I think it would make sense to have a ‘cache until’ convenience for the ‘cache for’ stuff. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
