Local docker layer cache lifespan is too short.

[JoseRolles]

When CodeBuild projects are ran within minutes of each other, the local docker layer cache works wonderfully.

However, if a subsequent build runs maybe 30-60 minutes later, the cache is gone.

Is there anyway to add a feature where we can set an expiration time for the cache to make it a bit more predictable and persistent? Or maybe have a native way for the cached layers to be stored on S3 where we can set a lifecycle policy?

[zen0wu]

It seems that codebuild is built on top of AWS lambda, hence a few minutes of inactivity invalidate the container and in turn the cache.

I'm considering having a custom volume in EFS and mount it at build time as cache, haven't tested it yet

[joelfogue]

Would this explain why every commit takes so long to provision the container? Basically it takes about 4mins just to provision the java runtime version and AFTER 4mins we then have to wait for our actual build time. Is there anyway to bypass that initial 4mins that codepipeline takes on every checkin just to setup our Codebuild environment?

[subinataws]

@Joel-fogue - Your provisioning delay doesn't sound related to the layer cache. Please post your issue on the AWS forums (https://forums.aws.amazon.com/forum.jspa?forumID=230), so we can follow up on your build configuration.

@ZenoZen - CodeBuild is not built on top of AWS Lambda. However, you are correct that the warm node and cache is discarded, if you run sparse builds.

@JoseRolles - CodeBuild's local cache is best effort and most useful when you run frequent builds with similar configuration. If you are running sparse builds (more than 15 mins or so apart), then you are less likely to hit the cache. Currently, the best option is to also back up the layer in Amazon ECR, as described by @monken in #26 (comment). In a future release, we will give a option to back up the local cache in your s3 bucket and ECR. At which time, you may set the lifecycle policy on your AWS resources that back up the cache.