search

limjh16 / jekyll-action-ts

:hammer: https://github.com/helaili/jekyll-action but without Docker
MIT License
42 stars 19 forks source link

Why is enable_cache better than using actions/cache? #3

Closed 0xdevalias closed 3 years ago

0xdevalias commented 3 years ago

In the README you state:

It also automatically caches the vendor/bundle directory for faster build times, by setting the enable_cache input to true in the workflow file. This is preferred over actions/cache (for now) since it decreases the time needed to find the Jekyll source and Gemfile.

I'm wondering if you could explain how this differs from using actions/cache, and why it is a better choice. It would also be useful to know under what conditions/when using actions/cache would be the better choice again.

limjh16 commented 3 years ago

Hi there! When you set the enable_cache input, it runs the restoring of cache after the Gemfile and _config.yml files are found via globbing. Apart from the time where the cache action is run, it does not differ from actions/cache at all.

This helps because restoring the cache before globbing means the action will run through every single file in the bundle cache, which can get very huge and take >30secs in my experience.

Honestly, I'm not sure when using actions/cache will be a better choice, but I did not enable the enable_cache input by default because it would be a breaking change for the ≈2 people out there who are already using this action 😆

Let me know if this answers your question!

0xdevalias commented 3 years ago

That seems to make sense :)

Though just to make sure I understand correctly, when you say the globbing would have to run over every file in the bundle cache, which globbing is that?

I'm curious if using some kind of ignore path in the glob could have a similar effect, while still allowing to use the actions/cache directly?

limjh16 commented 3 years ago

https://github.com/limjh16/jekyll-action-ts/blob/7ded763186a1a13a2967dc7fdd4a9a61c1c0c302/src/main.ts#L56-L57

As you can see, I already have an ignore path. However, it will still go through all the files in vendor/bundle, just reject those files after they have been found. I am using GitHub action's toolkit for the globbing

Is there any reason you want to use actions/cache? Because this cache implementation is really exactly the same, you can compare the source code of this and actions/cache

Hope this clears your doubts!

0xdevalias commented 3 years ago

Ah ok, that makes sense. Annoying that it doesn't just 'short circuit' early on the rejected paths.

No big reason specifically. Mostly I just like to understand the 'why' behind it when things seem to differ from the common/expected patterns. Helps for the tools I end up using not to be too 'magic', and helps me solve similar problems if I come across them myself in future.

Thanks for your quick responses! :)

limjh16 commented 3 years ago

Great! If you meet any issue with this action in the future, do bring it up since I have not really tested this action with many "edge" cases before.