> I'll have to look more closely but it uses the term "installing"
rather than "using"
The steps are: downloading -> installing -> using
You're caching `vendor/cache` now – so you're skipping downloading step,
and go straight to installing. If you want to skip that as well – you need
to cache `/bundle` directory, too.
> As for tarring the entire install from /bundle it's HUGE
tar it and put it into gitlab's cache, don't send it to your own cloud
storage. It's not lightning fast, but it is much faster than installing all
binary gems on every build.
On Tue, 25 Feb 2020 at 21:07, Tim Uckun wrote:
> I'll have to look more closely but it uses the term "installing"
> rather than "using" which it normally does when the gems are already
> installed and some of the gems take quite a while to install
> (httpparty, nokogiri etc)
>
> As for tarring the entire install from /bundle it's HUGE. I am going
> to try that next and see if the act of downloading, untarring,
> installing, tarring, and uploading takes less time than just
> installing them outright.
>
>
> On Tue, Feb 25, 2020 at 5:51 PM Oleg Ivanov wrote:
> >
> > Hi Tim,
> >
> > > Despite all this the bundler installs fresh gems every time the
> dockerfile builds
> >
> > Does it download them from rubygems, or does it use local copies from
> `vendor/cache`? I assume the latter, but you can confirm it just by looking
> at whether there's a download step before the installation.
> >
> > If it does use gems from `vendor/cache` to install them – then
> everything's working well. If you want to cache not just the gems
> themselves, but also fully installed bundle environment to avoid bundler
> installing anything at all between runs – then you need to store not just
> `vendor/cache`, but also your bundle install path, which seems to be
> `/bundle` in your example (or actually it's the only thing you need to
> store – unless you're unhappy with what comes in `vendor/cache` from your
> repository for any reason).
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Ruby or Rails Oceania" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to rails-oceania+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/rails-oceania/CAC-XhxXu3%2BgYFgjZYLmudyyQ4qvBx31L%2BC7oF8E7aiypD8eLoA%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rails-oceania+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rails-oceania/CAGuHJrPO1YmrRrA-DSVXhrc%3DWx66fMUnk%2BVCzmkFY4qON63X7A%40mail.gmail.com
> .
>
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rails-oceania+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rails-oceania/CAC-XhxUGqH-%3D-gDBtPxf3etif_yP_LZiVktt--wtyG%3DyWqFQLg%40mail.gmail.com.
