If cache gets corrupted and build fails, there is no way to fix the cache


#1

I noticed this many months ago, but did not bother to post about it because it was not affecting me in a significant way. That is no longer the case. Our staging build is failing because of a corrupt cache, and the only way to fix it is to build w/o cache. This raises build times from 2-4~ minutes (excl. deploy time) to 15+ minutes (excl. deploy time). If this were a one-time thing, no big deal, but it is not. The build w/o cache feature also does not update the cache. This means that a corrupt cache is there to stay, and I do not see a way to fix that without making changes to the config.yml file just to fix the issue temporarily. Is there any way I can kill the cache and have it repopulate on next build? Thanks,

-Ian


#2

Hi Ian,

Thanks for reaching out!

It’s possible to use a cache key within config.yml to address the problem you’re facing. You’ll first need to decide when a cache will be saved or restored by using a key for which some value is an explicit aspect of your project. For example, when a build number increments, when a revision is incremented, or when the hash of a dependency manifest file changes.

Following are some examples of caching strategies for different goals:

  • myapp-{{ checksum "package.json" }} - Cache will be regenerated every time something is changed in package.json file, different branches of this project will generate the same cache key.
  • myapp-{{ .Branch }}-{{ checksum "package.json" }} - Cache will be regenerated every time something is changed in package.json file, different branches of this project will generate the separate cache keys.
  • myapp-{{ epoch }} - Every build will generate separate cache keys.

More details can be found in our documentation.

I hope this fixes your caching issue, please let us know if you’re still having issues and we’ll investigate again.

Cheers,
Eugene


#3

Hi Eugene,

I already use cache keys extensively. I’m in the process of dockerizing everything in our main project, so that may correct the issue in a different way.


#4

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.