search

3scale / apisonator

Red Hat 3scale API Management Apisonator backend
https://3scale.net
Apache License 2.0
36 stars 27 forks source link

Excluding Git metadata and project examples from gems. #91

Open whitingjr opened 5 years ago

whitingjr commented 5 years ago

Hi, Taking a quick peek inside a generated apisonator container I see the following directories.

ruby/3scale_backend-2.89.0/vendor/bundle/ruby/2.3.0/bundler/gems/puma-9b17499eeb49/.git
ruby/3scale_backend-2.89.0/vendor/bundle/ruby/2.3.0/bundler/gems/puma-9b17499eeb49/examples
ruby/3scale_backend-2.89.0/vendor/bundle/ruby/2.3.0/bundler/gems/resque-88839e71756e/.git
ruby/3scale_backend-2.89.0/vendor/bundle/ruby/2.3.0/bundler/gems/resque-88839e71756e/examples

Git metadata can quickly add up in size. Are these directories good candidates for exclusion ?

It might be the case this suggestion needs raised upstream to the respective gem projects.

unleashed commented 5 years ago

Hi @whitingjr, those .git directories are the results of vendoring gems from git repositories using Bundler, so it's not a matter of upstream gems but rather us pointing to forks or specific commits with patches added on top.

I have not considered whether the vendored code from git repositories could be smaller by using shallow check outs, but we can certainly take a look at it. The obvious requirement is that Bundler needs to ensure the correct code is being loaded (so some git metadata is needed) to function correctly.

I'll take a look and update accordingly, thanks!

unleashed commented 4 years ago

Hi,

support for shallow clones in git checkouts referencing rubygems is not implemented in Bundler. There is https://github.com/rubygems/bundler/issues/4556 though, which if closed with an implementation should allow us to use shallow clones and reduce a bit the footprint.