I have thought about this but I have shied away from doing it because the development systems are Mac and the deployment is Linux. Most of the gems are pure ruby and should OK but there are bound to be some gems that use C libs and/or have platform specific versions.
Maybe bundler is smart enough to manage all of that though, I am just not sure. On Tue, Feb 4, 2020 at 12:30 AM Nigel Sheridan-Smith < [email protected]> wrote: > Have you considered using bundler's vendor cache? > > > https://stackoverflow.com/questions/14607636/is-it-advisable-to-include-the-contents-of-vendor-cache-in-git-in-a-rails-3-2-ap > > Cheers, > Nigel > > *Dr Nigel Sheridan-Smith PhD* / Principal > *Green Shores Digital* > > [image: Twitter] <https://twitter.com/GreenShoresAU>[image: Linkedin] > <http://au.linkedin.com/in/nsheridansmith> > > *M*: +61 403 930 963 > *E*: [email protected] > *W*: http://www.greenshoresdigital.com > > > > > > > On Mon, Feb 3, 2020 at 8:54 PM Oleg Ivanov <[email protected]> wrote: > >> We're doing yarn install and asset precompilation for our docker build, >> and we run these steps on CI to prepare the source code, which is then >> packaged into a docker image. >> >> This allows us to fully leverage CI's own caches (we're doing it on >> Gitlab as well btw), and basically we do with bundler what you already >> discussed here - cache the bundle plus Gemfile/Gemfile.lock, then we cache >> node_modules plus package.json/yarn.lock, and we also keep tmp/assets >> between builds to speed up assets precompilation. Can't comment on the >> database thing - we just let our build connect to the db, it didn't really >> bother us much. >> >> If no dependencies changed between the builds – the installation steps >> are fast, and it's only asset compilation itself that takes some time. >> >> It also removes the need for us to have yarn or raw assets in the docker >> image at all – we just add Rails bundle as a separate layer to cache it, >> and then copy project code with precompiled assets, but WITHOUT any raw >> assets - it speeds up the process and reduces final image size (no >> node_modules and all that in the image). >> >> Hope this helps. >> >> On Mon, 3 Feb 2020 at 20:05, Simon Russell <[email protected]> wrote: >> >>> It's not that the gemfile is changing it's that Gemfile.lock is changing >>>> because we have gems we are pulling from git. >>>> >>> >>> Okay sure yes that would complicate things a bit; kind of the same issue >>> -- there are frequent changes to the Gems. Just trying to understand why >>> it was needing rebuilding so often. >>> >>> That's what I am doing but I am doing it in two phases like this. >>> >>> ... >>> >>> This allows me add the base gems as one layer and the second bundle >>>> install uses the already installed gems from the base layer so it goes >>>> faster. This allows all my gems to be defined in the same project (no base >>>> layer to pull from) but it's split into two files so that's not ideal. >>>> >>> >>> That all looks okay to me. >>> >>> >>>> I have a pretty robust dockerignore (I can post it if you want) but the >>>> build still take a long time and as I said the docker image is HUGE 1.2 >>>> gigs. I did a three stage docker build once and got the image to just a >>>> hair under 600 megs but that still seems insanely large for a rails app. >>>> >>> >>> Yeah it seems like the issue isn't that layers are being rebuilt when >>> they shouldn't be -- if you're updating the lock file then you do need to >>> reinstall. >>> >>> I mean nothing you're doing looks like the wrong thing; I guess there >>> might be more you can clear out of the build process for the gems, but that >>> might come down to looking at the Gemfile and stepping through things one >>> by one and understand where that 1.2Gb comes from. If the gems that take >>> ages to install are the gems that are getting updated frequently then >>> nothing springs to mind about what you might do. >>> >>> >>>> What about the asset precompilation? Can I skip that if I have done a >>>> yarn install? how about visa versa? Can I skip the yarn install if I do a >>>> asset precompile? Is there another way to avoid a database connection when >>>> I am doing asset precompile than using the nulldb adapter? >>>> >>> >>> Deliberately didn't respond to this bit because I haven't used that >>> stuff, sorry :) >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rails-oceania/CAGD6pKZ89%2B9JTEH%3DYw-CKW7e_ZnyRvN-4S5oMpQXs%2BnTBsTLXw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/rails-oceania/CAGD6pKZ89%2B9JTEH%3DYw-CKW7e_ZnyRvN-4S5oMpQXs%2BnTBsTLXw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> With best regards, >> Oleg Ivanov. >> ICQ #69991809 >> Jabber: [email protected] >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rails-oceania/CAC-XhxXvASC4%3DHs0cY%3D8yv2zZU1r%3Dds%2Bx93-rXzX4-q9R%2BemEQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/rails-oceania/CAC-XhxXvASC4%3DHs0cY%3D8yv2zZU1r%3Dds%2Bx93-rXzX4-q9R%2BemEQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rails-oceania/CAOOM5kx2PjvKCE6QdBAnFez4ygqBO5TpQTFLp4F2xGJ4B1o3rQ%40mail.gmail.com > <https://groups.google.com/d/msgid/rails-oceania/CAOOM5kx2PjvKCE6QdBAnFez4ygqBO5TpQTFLp4F2xGJ4B1o3rQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rails-oceania/CAGuHJrPB%3D03zXK2VkyjT9DQ_eJPmDejcaFfdu%3DzfQA2AhrjDNQ%40mail.gmail.com.
