A Cloud Native Buildpack to install gems from a Gemfile
License: Apache License 2.0
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Please provide some details about the task you are trying to accomplish and
what went wrong.
What were you attempting to do?
I was trying to build a ruby application with a gemfile that specifies major.minor for Ruby.
What did you expect to happen?
I expected the buildpack to build the image with the correct mri version.
What was the actual behavior? Please provide log output, if possible.
Instead, it used the latest ruby version
===> BUILDING
Paketo MRI Buildpack 0.0.164
Resolving MRI version
Candidate version sources (in priority order):
<unknown> -> "*"
<unknown> -> "*"
Selected MRI version (using <unknown>): 2.7.2
Executing build process
Installing MRI 2.7.2
Completed in 1.005s
Configuring environment
GEM_PATH -> "/home/cnb/.gem/ruby/2.7.0:/layers/paketo-buildpacks_mri/mri/lib/ruby/gems/2.7.0"
It looks like the code forces you to specify a patch when it should be able to accept major.minor and then decide which of the available mri version patches to use.
bundle-install/gemfile_parser.go
Lines 22 to 25 in 8370e8b
Please provide some details about your build configuration.
What platform (pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.
What buildpacks are you using? Please include versions.
ruby 0.2.0
What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
Can you provide a sample app or relevant configuration (buildpack.yml,
nginx.conf, etc.)?
Please confirm the following:
I updated the puma gem in my Gemfile but didn't update the Gemfile.lock and the buildpack reused the cache without erroring:
Paketo Bundle Install Buildpack 0.0.59
Reusing cached layer /layers/paketo-buildpacks_bundle-install/gems
I expect that it either:
We built a Ruby app with version 2.7.2 of mri, then rebuilt it, changing the version to 2.6.6. The app failed to run after rebuild because it was not able to find the required gems.
Gemfile.lock by running bundle install locally.buildpack.yml that specifies an MRI version:---
mri:
version: 2.7.2pack build changing-version --builder paketobuildpacks/builder:0.1.20-base --buildpack gcr.io/paketo-buildpacks/ruby:0.1.5 --clear-cachedocker run -d --env PORT=8080 --publish 8080:8080 changing-version
curl 0.0.0.0:8080
<!DOCTYPE html>
<html>
<head>
<title>Powered By Paketo Buildpacks</title>
</head>
<body>
<img style="display: block; margin-left: auto; margin-right: auto; width: 50%;" src="https://paketo.io/images/paketo-logo-full-color.png"></img>
</body>
</html>
buildpack.yml to specify a different MRI version:---
mri:
version: 2.6.6 pack build changing-version --builder paketobuildpacks/builder:0.1.20-base --buildpack gcr.io/paketo-buildpacks/ruby:0.1.5[builder] Paketo Bundle Install Buildpack 0.1.0
[builder] Reusing cached layer /layers/paketo-buildpacks_bundle-install/gems
[builder]
docker run -it --env PORT=8080 --publish 8080:8080 changing-version
bundler: command not found: puma
Install missing gem executables with `bundle install`
ruby/2.7.0 directorydocker run -it --env PORT=8080 --publish 8080:8080 --entrypoint=launcher changing-version /bin/bash
cnb@80bec5a816a0:/workspace$ ll /layers/paketo-buildpacks_bundle-install/gems/ruby/
total 12
drwxr-xr-x 3 cnb cnb 4096 Jan 1 1980 ./
drwxr-xr-x 4 cnb cnb 4096 Jan 1 1980 ../
drwxr-xr-x 9 cnb cnb 4096 Jan 1 1980 2.7.0/The buildpack should rebuild the gem layer when the minor version of ruby changes, because the gems will need to be placed in a different subdirectory.
Please confirm the following:
The paketo buildpacks team is officially supporting ruby so this buildpack should be
paketo-buildpacks/bundle-installpaketo-buildpacks github org.This RFC describes the changes.
Currently the building stage output does not include the output from running bundle install:
Paketo Bundle Install Buildpack 0.0.60
Executing build process
Running 'bundle config path /layers/paketo-buildpacks_bundle-install/gems'
Running 'bundle config cache_path --parseable'
Running 'bundle install'
Completed in 20.239s
Could we get this output included please to show progress?
Please provide some details about the task you are trying to accomplish and
what went wrong.
Build a ruby application that has the mysql2 gem specified in it's Gemfile.
This worked after building a new stack build image on top of the CNB Full Stack build image and running apt-get install libmysqlclient-dev.
The image to successfully build.
It looks like there's a variant of the libmariadb-dev library but it doesn't seem to meet the requirements for the mysql2 gem: https://github.com/paketo-buildpacks/stacks/blob/caf3e44bd54c3a8cc4da0dafe65d3d875142a908/packages/full/build#L89-L90
Installing mysql2 0.5.3 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
current directory:
/layers/paketo-buildpacks_bundle-install/gems/ruby/2.5.0/gems/mysql2-0.5.3/ext/mysql2
/layers/paketo-buildpacks_mri/mri/bin/ruby -r ./siteconf20201203-76-wo6d1g.rb
extconf.rb
checking for rb_absint_size()... yes
checking for rb_absint_singlebit_p()... yes
checking for rb_wait_for_single_fd()... yes
checking for -lmysqlclient... no
-----
mysql client is missing. You may need to 'sudo apt-get install libmariadb-dev',
'sudo apt-get install libmysqlclient-dev' or 'sudo yum install mysql-devel', and
try again.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.
Please provide some details about your build configuration.
pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.===> DETECTING
======== Results ========
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pack inspect-builder <builder>?A custom builder with the paketo-buildpacks ruby buildpack specified.
buildpack.yml,nginx.conf, etc.)?We don't need a buildpack.yml for this app, and the Gemfile contains:
...
gem "mysql2"
...
Please confirm the following:
Trying to build an container for ci test runs, and the development/test gems are missing
What were you attempting to do?
I'm trying to build a image to use in multiple different CI runs, thus the development:test gems are need in the launch layer.
What did you expect to happen?
A way to the launch layer to be configured to allow development and test gems to be included
What was the actual behavior? Please provide log output, if possible.
pack, kpack, tekton buildpacks plugin, etc.) are youpack: 0.21.1
paketo-buildpacks/ca-certificates 2.4.0
paketo-buildpacks/mri 0.2.5
paketo-buildpacks/bundler 0.1.9
paketo-buildpacks/bundle-install 0.2.4
paketo-buildpacks/node-engine 0.7.1
paketo-buildpacks/yarn 0.4.0
paketo-buildpacks/yarn-install 0.4.0
paketo-buildpacks/rails-assets 0.2.4
paketo-buildpacks/puma 0.0.61
paketo-buildpacks/procfile 4.3.0
pack inspect-builder <builder>?paketobuildpacks/builder:full
buildpack.yml,nginx.conf, etc.)?Go get update workflow failed.
Please take a look to ensure CVE patches can be released. (cc @pivotal-cf/commercial-buildpacks).
When I am pack building a ruby app that has a Gemfile
I Want my gems to be reused when possible
So That my app is built faster
Given
I am building a ruby app that has a Gemfile
When
The gems can be reused and pulled rather than re-built
Then
The gems are reused and I am informed that the gems were reused
The current implementation makes a few modifications to the Bundler configuration as it executes:
path to the gems layerbundle clean is executed after the installation completesThese configuration settings modify any of the settings that may already be set in the working directory in .bundle/config. They also won't be persisted beyond this given build of the application. So, we may lose some useful configuration settings if the layer is reused and the configuration is not repopulated on a subsequent build.
If the .bundle/config file exists, we should copy it into the gems layer. Then we should set the BUNDLE_APP_CONFIG environment variable to point to the new layer path. The bundle config docs outline that it will look at $BUNDLE_APP_CONFIG/config for configuration settings. Finally, when setting the above enumerated configuration options in the build process, we should use the --local flag to ensure it records those values to the config file in the gems layer. At this point, it is reasonable to remove the BUNDLE_PATH and BUNDLE_WITHOUT environment variables and to only set the BUNDLE_APP_CONFIG environment variable as it should supersede these environment variable values.
The buildpack currently only installs those gems that do not belong to the development or test groups in the Gemfile. Unfortunately, some buildpacks may need access to development or test gems during their build phase. We should enable those buildpacks to have access to those gems if they request that gems be made available during the build phase.
If the build plan entry includes a launch entry in the metadata, then the buildpack should install the "production" gems (excluding development and test) into a layer that is made available at launch. This is the buildpack's current behavior.
If the build plan entry includes a build entry in the metadata, then the buildpack should install all gems (including development and test) into a layer that is made available at build. This is net-new behavior.
If the build plan entry contains both a launch and build entry in the metadata, then the buildpack should do both of the above behaviors, resulting in 2 layers, but with different lifecycle phase access and purposes.
Update GitHub config workflow failed.
Approve bot PR workflow failed.
Push Buildpackage workflow failed.
Publish All Draft Releases workflow failed.
Context:
Currently bundle-install hardcodes that it is a layer that is required during launch here:
Line 32 in 293d791
This hardcoding ignores requirements that are made be other buildpacks in their Build Plans. This is an anti-pattern for the Paketo Buildpacks and eliminates the ability for other integrating buildpacks to require gems during the build phase.
Proposal:
Bundle-install should have a strategy similar to other Paketo Buildpacks where is merges Buildpack Plan entry metadata to find the build and launch requirements.
Hey there 👋
I am testing the performance of building an image with buildpacks vs using a dockerfile with buildkit enabled.
For a given ruby app:
bundle installI expect the second build to be fast since all of the other gems are available in the vendor/cache directory.
With docker buildkit, this step takes ~2 seconds.
=> [stage-0 10/16] RUN --mount=type=cache,uid=1000,gid=1000,target=/app/.cache/gems --network=none bundle install --local && cp -ar .cache/gems 2.3s
With the buildpack, it took a few minutes:
2020/10/13 16:25:29.971038 Paketo Bundle Install Buildpack 0.0.59
2020/10/13 16:25:29.971201 Executing build process
Running 'bundle config path /layers/paketo-buildpacks_bundle-install/gems'
2020/10/13 16:25:30.100074 Running 'bundle config cache_path --parseable'
2020/10/13 16:25:30.218272 Running 'bundle install --local'
2020/10/13 16:28:16.406565 Completed in 2m46.624s
Since the app has a vendor/cache directory with the gems already available, I expected a rebuild after a single gem change to be faster.
Following the completion of #182, I tested out the code which installs development and test gems during the build phase. I performed a rebuild of an app with test gems, and I changed a test gem (same experience fordevelopment gem change) it caused both the build and launch install process to re-run.
When I changed a production gem on a rebuild, it also caused both the build and launch install process to re-run.
I would have only expected the relevant install process to rerun depending on the type of gem. For example, when changing a test gem I would've expected only the build process the rerun, but the launch process cache layer to be reused so that my rebuild is more performant.
pack, kpack, tekton buildpacks plugin, etc.) are youpack 0.18.0
buildpack.yml,nginx.conf, etc.)?https://github.com/paketo-buildpacks/bundle-install/tree/main/integration/testdata/simple_app
Run an application image created with this buildpack. The spring gem is only available in the development group of the gemfile.
group :development do
gem "spring"
end
For it to start without spring without needing to explicitly set DISABLE_SPRING=1 in the environment.
Running via Spring preloader in process 20
WARNING: Spring is running in production. To fix this make sure the spring gem is only present in `development` and `test` groups in your Gemfile and make sure you always use `bundle install --without development test` in production
pack, kpack, tekton buildpacks plugin, etc.) are youLatest pack
Latest ruby buildpack
pack inspect-builder <builder>?Custom builder
buildpack.yml,nginx.conf, etc.)?Context
If my app is vendored and I am running in an offline environment I should still be able to run bundle install in offline mode.
Proposal
Enable an offline bundle install workflow in this buildpack and write integration tests for it.
Acceptance Criteria
GIVEN I have a vendored ruby app in an offline environment
THEN I can run a pack build
AND get a functioning app the result
Create Draft Release workflow failed.
Context
If there is no change in the gems that are needed to run an app then the buildpack should reuse the gem layer from a previous build.
Proposal
Enable a gem layer reuse between builds and provide an integration test.
Acceptance Criteria
GIVEN I have a ruby app
AND my gem environment does not change between builds
THEN I can run a pack build on that same app
AND it will reuse the gem layer from my pervious build
With the recent builder image update, the build of application https://github.com/cloudfoundry/cf-acceptance-tests/tree/develop/assets/dora stopped working. It fails with:
Paketo Bundler Buildpack 0.1.0
Resolving Bundler version
Candidate version sources (in priority order):
Gemfile.lock -> "2.1.4"
<unknown> -> "*"
<unknown> -> "*"
failed to satisfy "bundler" dependency version constraint "2.1.4": no compatible versions. Supported versions are: [1.17.3, 2.2.3, 2.2.4]
See above
The build should continue to succeed
It failed. I started a discussion in Slack about this behavior. The buildpack tries to exactly match the BUNDLED WITH version in the Gemfile.lock with the available bundler versions. This is unexpected to colleague who is more Ruby expect than me. The lockfile certainly defines the exact version of the gems that are to be installed, but not which bundler version must be used. Outcome of the slack discussion currently is that the check should be relaxed to filter one the major version only -> 2.1.4 in the lockfile should pick the newest 2.* bundler included in the buildpack which would be 2.2.4 in my case.
Please provide some details about your build configuration.
pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.Shipwright Build which is based on Tekton 1.18.1.
I am using the 0.1.66-full builder image and the creator command. The versions can be seen here: https://github.com/paketo-buildpacks/full-builder/releases/tag/v0.1.66
What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
Can you provide a sample app or relevant configuration (buildpack.yml,
nginx.conf, etc.)?
https://github.com/cloudfoundry/cf-acceptance-tests/tree/develop/assets/dora
Please confirm the following:
When the Ruby version is modified in an app's Gemfile, the cached versions of ruby from previous builds are preserved in the final gems layer.
Please provide some details about the task you are trying to accomplish and
what went wrong.
We modified
first toruby '~> 2.6.6' and pack built the application. Next, we changed the line once again to ruby '~> 2.7.2' and rebuilt the application.
It was expected that layers/paketo-buildpacks_bundle-install/gems/ruby/ would only contain a 2.7.0 directory on the second build.
layers/paketo-buildpacks_bundle-install/gems/ruby/ contained both 2.6.0 and 2.7.0 directories.
First build:
===> DETECTING
[detector] 4 of 5 buildpacks participating
[detector] paketo-buildpacks/mri 0.0.164
[detector] paketo-buildpacks/bundler 0.0.153
[detector] paketo-buildpacks/bundle-install 0.1.1
[detector] paketo-buildpacks/rackup 0.0.48
===> ANALYZING
[analyzer] Previous image with name "index.docker.io/library/testv3cache:latest" not found
===> RESTORING
===> BUILDING
[builder] Paketo MRI Buildpack 0.0.164
[builder] Resolving MRI version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> "~> 2.6.6"
[builder] <unknown> -> "*"
[builder]
[builder] Selected MRI version (using <unknown>): 2.6.6
[builder]
[builder] Executing build process
[builder] Installing MRI 2.6.6
[builder] Completed in 1.487s
[builder]
[builder] Configuring environment
[builder] GEM_PATH -> "/home/cnb/.gem/ruby/2.6.0:/layers/paketo-buildpacks_mri/mri/lib/ruby/gems/2.6.0"
[builder]
[builder] Paketo Bundler Buildpack 0.0.153
[builder] Resolving Bundler version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> "*"
[builder] <unknown> -> "*"
[builder]
[builder] Selected Bundler version (using <unknown>): 2.1.4
[builder]
[builder] Executing build process
[builder] Installing Bundler 2.1.4
[builder] Completed in 198ms
[builder]
[builder] Configuring environment
[builder] GEM_PATH -> "$GEM_PATH:/layers/paketo-buildpacks_bundler/bundler"
[builder]
[builder] Paketo Bundle Install Buildpack 0.1.1
[builder] Executing build process
[builder] Running 'bundle config path /layers/paketo-buildpacks_bundle-install/gems'
[builder] Running 'bundle config clean true'
[builder] Running 'bundle config cache_path --parseable'
[builder] Running 'bundle install'
[builder] Completed in 2.617s
[builder]
[builder] Configuring environment
[builder] BUNDLE_PATH -> "/layers/paketo-buildpacks_bundle-install/gems"
[builder]
[builder] Paketo Rackup Buildpack 0.0.48
[builder] Writing start command
[builder] bundle exec rackup -p "${PORT:-9292}"
===> EXPORTING
[exporter] Adding layer 'paketo-buildpacks/mri:mri'
[exporter] Adding layer 'paketo-buildpacks/bundler:bundler'
[exporter] Adding layer 'paketo-buildpacks/bundle-install:gems'
[exporter] Adding 1/1 app layer(s)
[exporter] Adding layer 'launcher'
[exporter] Adding layer 'config'
[exporter] Adding layer 'process-types'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] Setting default process type 'web'
[exporter] *** Images (d6f54b1dced3):
[exporter] index.docker.io/library/testv3cache:latest
[exporter] Adding cache layer 'paketo-buildpacks/mri:mri'
[exporter] Adding cache layer 'paketo-buildpacks/bundler:bundler'
[exporter] Adding cache layer 'paketo-buildpacks/bundle-install:gems'
Successfully built image testv3cache
Second build:
===> DETECTING
[detector] 4 of 5 buildpacks participating
[detector] paketo-buildpacks/mri 0.0.164
[detector] paketo-buildpacks/bundler 0.0.153
[detector] paketo-buildpacks/bundle-install 0.1.1
[detector] paketo-buildpacks/rackup 0.0.48
===> ANALYZING
[analyzer] Restoring metadata for "paketo-buildpacks/mri:mri" from app image
[analyzer] Restoring metadata for "paketo-buildpacks/bundler:bundler" from app image
[analyzer] Restoring metadata for "paketo-buildpacks/bundle-install:gems" from app image
===> RESTORING
[restorer] Restoring data for "paketo-buildpacks/mri:mri" from cache
[restorer] Restoring data for "paketo-buildpacks/bundler:bundler" from cache
[restorer] Restoring data for "paketo-buildpacks/bundle-install:gems" from cache
===> BUILDING
[builder] Paketo MRI Buildpack 0.0.164
[builder] Resolving MRI version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> "~> 2.7.2"
[builder] <unknown> -> "*"
[builder]
[builder] Selected MRI version (using <unknown>): 2.7.2
[builder]
[builder] Executing build process
[builder] Installing MRI 2.7.2
[builder] Completed in 1.118s
[builder]
[builder] Configuring environment
[builder] GEM_PATH -> "/home/cnb/.gem/ruby/2.7.0:/layers/paketo-buildpacks_mri/mri/lib/ruby/gems/2.7.0"
[builder]
[builder] Paketo Bundler Buildpack 0.0.153
[builder] Resolving Bundler version
[builder] Candidate version sources (in priority order):
[builder] <unknown> -> "*"
[builder] <unknown> -> "*"
[builder]
[builder] Selected Bundler version (using <unknown>): 2.1.4
[builder]
[builder] Reusing cached layer /layers/paketo-buildpacks_bundler/bundler
[builder]
[builder] Paketo Bundle Install Buildpack 0.1.1
[builder] Executing build process
[builder] Running 'bundle config path /layers/paketo-buildpacks_bundle-install/gems'
[builder] Running 'bundle config clean true'
[builder] Running 'bundle config cache_path --parseable'
[builder] Running 'bundle install'
[builder] Completed in 2.541s
[builder]
[builder] Configuring environment
[builder] BUNDLE_PATH -> "/layers/paketo-buildpacks_bundle-install/gems"
[builder]
[builder] Paketo Rackup Buildpack 0.0.48
[builder] Writing start command
[builder] bundle exec rackup -p "${PORT:-9292}"
===> EXPORTING
[exporter] Adding layer 'paketo-buildpacks/mri:mri'
[exporter] Reusing layer 'paketo-buildpacks/bundler:bundler'
[exporter] Adding layer 'paketo-buildpacks/bundle-install:gems'
[exporter] Adding 1/1 app layer(s)
[exporter] Reusing layer 'launcher'
[exporter] Adding layer 'config'
[exporter] Reusing layer 'process-types'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] Setting default process type 'web'
[exporter] *** Images (e1efdee9ddd1):
[exporter] index.docker.io/library/testv3cache:latest
[exporter] Adding cache layer 'paketo-buildpacks/mri:mri'
[exporter] Reusing cache layer 'paketo-buildpacks/bundler:bundler'
[exporter] Adding cache layer 'paketo-buildpacks/bundle-install:gems'
Successfully built image testv3cache
Resulting gems layer directory:
cnb@8b4921868f90:/$ ll layers/paketo-buildpacks_bundle-install/gems/ruby/
total 16
drwxr-xr-x 4 cnb cnb 4096 Jan 1 1980 ./
drwxr-xr-x 4 cnb cnb 4096 Jan 1 1980 ../
drwxr-xr-x 9 cnb cnb 4096 Jan 1 1980 2.6.0/
drwxr-xr-x 9 cnb cnb 4096 Jan 1 1980 2.7.0/
Please provide some details about your build configuration.
What platform (pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.
pack v0.13.1+git-4134cc6.build-1135
What buildpacks are you using? Please include versions.
pack inspect-builder output:
paketo-buildpacks/[email protected]
│ ├ Group #5:
│ │ ├ paketo-buildpacks/[email protected]
│ │ ├ paketo-buildpacks/[email protected]
│ │ ├ paketo-buildpacks/[email protected]
│ │ ├ paketo-buildpacks/[email protected]
│ │ └ paketo-buildpacks/[email protected] (optional)
What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
index.docker.io/paketobuildpacks/builder:full-cf
Can you provide a sample app or relevant configuration (buildpack.yml,
nginx.conf, etc.)?
Sample app
Please confirm the following:
NOTE: This may be resolved by addressing #112
Please provide some details about the task you are trying to accomplish and
what went wrong.
We were trying to use some build-time configuration that the bundle tool natively respects to change the contents of the built app image. In particular, we wanted to take advantage of the BUNDLE_WITHOUT environment variable to exclude certain gems from the built app image. Rather than rebuilding the gems layer, the buildpack reused the cached version of the layer. The resulting app image included gems we didn't want in our image.
source 'https://rubygems.org'
ruby '~> 2.0'
group :test do
gem 'rspec'
end
gem 'puma'
gem 'sinatra'bundle locally to generate a Gemfile.lock.pack build exclude-gems --builder paketobuildpacks/builder:0.1.20-base --buildpack gcr.io/paketo-buildpacks/ruby:0.1.5 --clear-cacherspec gem is present:docker run -it --entrypoint=launcher exclude-gems /bin/bash
cnb@fa0d8cb9967f:/workspace$ ls /layers/paketo-buildpacks_bundle-install/gems/ruby/2.7.0/gems/
diff-lcs-1.4.4 nio4r-2.5.4 rack-2.2.3 rspec-3.10.0 rspec-expectations-3.10.0 rspec-support-3.10.0 sinatra-2.1.0
mustermann-1.1.1 puma-5.0.4 rack-protection-2.1.0 rspec-core-3.10.0 rspec-mocks-3.10.0 ruby2_keywords-0.0.2 tilt-2.0.10BUNDLE_WITHOUT env var to exclude the test group:pack build exclude-gems --builder paketobuildpacks/builder:0.1.20-base --buildpack gcr.io/paketo-buildpacks/ruby:0.1.5 --env BUNDLE_WITHOUT=testThe output should contain:
[builder] Paketo Bundle Install Buildpack 0.1.0
[builder] Reusing cached layer /layers/paketo-buildpacks_bundle-install/gems
[builder]rspec is still present in the app containerdocker run -it --entrypoint=launcher exclude-gems /bin/bash
cnb@546bd3d68aea:/workspace$ ls /layers/paketo-buildpacks_bundle-install/gems/ruby/2.7.0/gems/
diff-lcs-1.4.4 nio4r-2.5.4 rack-2.2.3 rspec-3.10.0 rspec-expectations-3.10.0 rspec-support-3.10.0 sinatra-2.1.0
mustermann-1.1.1 puma-5.0.4 rack-protection-2.1.0 rspec-core-3.10.0 rspec-mocks-3.10.0 ruby2_keywords-0.0.2 tilt-2.0.10
The buildpack should rebuild the gems layer in a way that respects this native configuration.
Notably, running
pack build exclude-gems --builder paketobuildpacks/builder:0.1.20-base --buildpack gcr.io/paketo-buildpacks/ruby:0.1.5 --env BUNDLE_WITHOUT=test --clear-cacheproduces the desired result, where rspec gems are not present.
Please confirm the following:
To implement Paketo RFC0038, this buildpack will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.
To conform to RFC0043 this buildpack should ensure that builds are reproducible. Specifically it should not include a built_at metadata field. In the tests that leverage this field to assert layer reuse, we should instead compare layer SHA values across rebuilds.
See also the tracking issue: paketo-buildpacks/rfcs#165.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.