Only reuse launch process cache layer when test/development gem changes

[sophiewigmore]

What happened?

• What were you attempting to do?

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.

• What did you expect to happen?

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.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

pack 0.18.0

• What buildpacks are you using? Please include versions.

bundle-install v0.2.0

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

https://github.com/paketo-buildpacks/bundle-install/tree/main/integration/testdata/simple_app

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

[fg-j]

@paketo-buildpacks/ruby-maintainers This issue has been open for a while. Does this need to be investigated further before it's workable?

[sophiewigmore]

I think it's workable as is. We should re-use the launch cache layer when a development/test gem changes.

[robdimsdale]

@sophiewigmore I'm happy to take a look at implementing this, but my knowledge of the ruby ecosystem is limited, and I don't how to determine whether dev/test gems have changed.

My current mental model is to expand the BundleInstallProcess.ShouldRun() method to know whether it is running on the build or launch layer, and determine the subset of gems to analyze accordingly. This would probably mean that we have to parse the Gemfile (or Gemfile.lock?) rather than running a checksum over the whole file.

Does that make sense? Am I on the right track?

[ryanmoran]

@robdimsdale that seems like the right path. I'm wondering if you might be able to leverage the output of bundle check to see if the bundle install command needs to be rerun.

[robdimsdale]

I'm probably not going to get to this just yet, so I'm un-assigning myself. Anyone else who is interested is welcome to pick it up!