News for hackers. Stuff that matters.

A comment on GitLab 13.0. Parent comment

Re:GitLab 13.0 by oweiler on Friday May 22, 2020 @02:35PM (#23275392)
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.
[ Parent | on HN ]
Re:GitLab 13.0 by latch on Friday May 22, 2020 @02:47PM (#23275493)
Instead 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)
[ Parent | on HN ]
Re:GitLab 13.0 by Already__Taken on Friday May 22, 2020 @06:37PM (#23277870)
That's weird won't these all be docker layers somewhere in the guts? So it's already compressed.
[ Parent | on HN ]
Re:GitLab 13.0 by orf on Friday May 22, 2020 @05:05PM (#23277027)
The 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.
[ Parent | on HN ]
Re:GitLab 13.0 by morelisp on Friday May 22, 2020 @05:15PM (#23277140)
The 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.

[ Parent | on HN ]