Open wilkosz opened 4 years ago
I’m not sure what build this is referring to. Gems in test and development groups should already be excluded from the package that is deployed to lambda. Are you seeing otherwise? Or is there something else you want them excluded from?
I could be wrong about the package the gets uploaded to the cloud provider, but the serverless package when built using serverless package
contains gems listed in the test
and development
groups. Looking at https://github.com/joshuaflanagan/serverless-ruby-package/blob/master/index.js#L108 it appears that docker is building all the groups in the package for deployment.
Again I may be wrong. The setup.rb file of the serverless package contains gems within the test group i.e. rspec
Gemfile
:
source "https://rubygems.org"
ruby '~> 2.5.5'
# development and test groups are not bundled as part of the deployment
group :development, :test do
# Call 'byebug' anywhere in the code to stop execution and get a debugger console
# gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
gem 'rake'
gem 'pry'
gem 'awesome_print'
end
group :test do
gem 'rspec'
gem 'launchy'
gem 'capybara'
end
gem 'aws-sdk-secretsmanager'
gem 'redis-activesupport'
gem 'content_disposition'
gem 'mechanize'
You may be right - I might have broken that part when I added the dockerized packaging step. I'll look into this.
Oh, I see what you are referring to. Yes, the setup.rb
still adds those gem directories to the load path, but the gem files are not actually included in the package zip. If you unzip the zip file and look in vendor/bundle/ruby/2.5.0/gems/
you will see that rspec, etc are not included.
The extra load paths are annoying, but should not break anything. I'm not sure how to fix that without manually building that setup.rb file. I was explicitly avoiding using the --without
flag, since that changes your local working install - not just what goes in the package. You would then have to re-bundle every time to be able to use rspec
again.
This is causing breakage for me as well because dev dependencies that are native (debase) are failing the package step.
@apsoto don't you need those dev dependencies installed in order to develop? Or does this only come up in a separate build/package environment?
I've tried to troubleshoot this a bit and I had some success excluding dev and test groups without breaking the host's bundle environment.
The solution is to mount .bundle
so it does not over write the host's config file
docker run --rm --mount type=volume,dst=/var/task/.bundle -v "$PWD:/var/task" lambci/lambda:build-ruby2.5 bundle install --standalone --path vendor/bundle --without='development test'
The .bundle
mount options have to be before the -v
otherwise it's ignored if they are mounted after the parent dir was mounted.
In addition to updating the docker command that is run, we need some additional enhancements:
--without
, when I use --with=default
I still get the dev and test groups included.
We would need the ability to pass the bundle groups to exclude via serverless configNOTE I haven't fully vetted this, beyond getting the bundle task to run AND exclude certain bundle groups.
I use the dev and test groups for local unit testing, yard for docs, simplecov for code coverage, etc., some dev dependencies are necessary for VSCode plugins I use, but aren't necessary for production
also, forgot to mention, this only became a problem once I added a native package to the default group.
I had a native package in dev/test group and things would package and deploy without a problem.
However, once I added a gem with native dependencies in the default group, I started getting problems with the package step trying to build the native gems in my dev/test group
I have to comment out my native gems in the dev/test groups to get package/deploy to work rt now
Agenda
Drop
test
anddevelopment
gems during build:bundle install --standalone --path vendor/bundle --without test development;