4 ms·
The caching is so broken it's barely usable. You can't easily exclude files. The cache can't be updated incrementally. It's often slower than downloading all de
by oweiler 6y ago
The caching is so broken it's barely usable. You can't easily exclude files. The cache can't be updated incrementally. It's often slower than downloading all dependencies on every build.
- latch 6y agoInstead of caching node_modules, cache node_modules.tar.szt Then wrap your job in a untar/tar: tar --use-compress-program zstd -xf node_modules.tar.zst || true YOUR NORMAL JOB tar --use-compress-program zstd -cf node_modules.tar.zst node_modules (and you can delete things you don't need if you want)
- Already__Taken 6y agoThat's weird won't these all be docker layers somewhere in the guts? So it's already compressed.
- orf 6y agoThe caching is not broken and it's completely usable. It sounds like you've got a weird specific use case that doesn't benefit from a general solution.
- morelisp 6y agoThe caching has worked great for me for Java / JVM languages, and decently for Go (but a proxy is usually better). It is unusable for NPM or composer, or the version of yarn we use (maybe newer ones too but I know they were trying to improve their internal cache a while back). Anything with a ton of small files or entire git histories. It’s awful, and it’s not weird or specific.