Cache timeouts

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Cache timeouts

Lóránt Pintér-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Cache timeouts

Daz DeBoer-2
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 <[hidden email]> 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




--
Darrell (Daz) DeBoer
Reply | Threaded
Open this post in threaded view
|

Re: Cache timeouts

Joachim Nilsson
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 <[hidden email]> 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 <[hidden email]> 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




--
Darrell (Daz) DeBoer

Reply | Threaded
Open this post in threaded view
|

Re: Cache timeouts

Adam Murdoch
In reply to this post by Lóránt Pintér-2

On 14 Aug 2014, at 8:44 am, Lóránt Pintér <[hidden email]> 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