Ruby gems cache seems to be ineffective

Support
, ,
#1

Hello!

I have a Jekyll 4 site, which uses the sassc gem.

The installation of the sassc gem is very long (several minutes in general):

6:46:37 PM: Fetching sassc 2.3.0
6:46:38 PM: Installing sassc 2.3.0 with native extensions
6:50:08 PM: Fetching jekyll-sass-converter 2.1.0

One log makes me believe it should be cached:

6:46:03 PM: Started restoring cached ruby gems
6:46:03 PM: Finished restoring cached ruby gems

And later:

6:50:26 PM: Started saving ruby gems
6:50:26 PM: Finished saving ruby gems

Yet for some reason, at least during my preview builds, the cache doesn’t seem to have any effect.

Since this gem build is very long, I would really like to be able to cache it.

What are possible debugging tips & work-arounds? Did anyone meet the same problem?

Many thanks!

– Thibaut

#2

I’ve noticed that apparently, once I merged into master and deployed as real build, the next branch will not exhibit the same behaviour, and cache seems to be effective.

I guess maybe the caching doesn’t completely work for preview branch, but that will be good enough for now.

– Thibaut

1 Like
#3

As you’ve noticed, the caching works fine after the first time a branch is built. However, the cache is not shared between branches. If it were, then we would never have noticed the 3 minute long build times. Each new branch is built on a clean slate, and then everything that should be cached is cached.

I’ve really had issues with this while using Netlify CMS, where each new blog post is a new branch. So now it takes 3 minutes to generate a branch preview. This then blocks other deploys from being built, at least on Netlify’s free plan (idk about higher levels). For the time being, I’ve just turned off branch deploys all together.

#4

Thanks for the input! Appreciated. I thought about this after working on similar troubles on e.g. CircleCI. Luckily on CircleCI you can specify the cache key naming scheme, which allows you to decide if you should share the cache between master and branches.

Luckily for blog posts, I will just render locally from branch for now, and will merge once ready.

1 Like
#5

This is a sore point, because it means I cannot collaborate easily with other people and share previews. And this has unintended effect of discouraging people from upgrading to latest version of the most popular static site generator.

#6

Hey @shushugah,
Can you say more about how this prevents collaborating and sharing previews? Do you mean that it makes collaborating on a branch more difficult because you have to reinstall dependencies on every push?

It’d also be great to hear more about your last comment-- are you saying our caching discourages people from upgrading because upgrading clears the cache?

Thanks in advance!

#7

Jekyll 4 builds 75% more quickly locally compared to Jekyll 3.8.5, but now the netlify previews take far longer, because with every new git branch, the sassc native extensions are recompiled without cache, therefore it takes 3-7 minutes to load the dependencies.

I am specifically asking for a caching mechanism per repository project, if the bundler output doesn’t change, which is the case most of the time, for most builds/users in Jekyll environment.

I don’t know what the technical considerations are, but I can report, as a user it makes netlify deploy previews, almost unusable with JEKYLL 4

#8

Hey @shushugah, I looked into this and found out that we intend to use the production dependency cache for Deploy Previews.

For other branches, we use the production dependency cache for the first deploy to that branch, but after that, the branch has its own cache. So it sounds like you’re running into a) a bug or b) something specific to Jekyll 4-- or maybe you’re trying out new dependencies on a separate branch? You’re correct that Deploy Previews won’t work for that. But deploying to a separate branch should work to try those out.

Would you mind sharing a Netlify URL where you’re running into this so we can keep digging?