need to have dummy Gemfile.lock even if BUNDLE_GEMFILE is set

[thewoolleyman]

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

{
   "name": "Pivotal Application Service",
   "build": "2.2.6-build.2",
   "support": "https://support.pivotal.io",
   "version": 0,
   "description": "https://docs.pivotal.io/pivotalcf/2-2/pcf-release-notes/runtime-rn.html",
   "authorization_endpoint": "https://login.gcp.trackerred.com",
   "token_endpoint": "https://uaa.gcp.trackerred.com",
   "min_cli_version": "6.23.0",
   "min_recommended_cli_version": "6.23.0",
   "api_version": "2.112.0",
   "app_ssh_endpoint": "ssh.gcp.trackerred.com:2222",
   "app_ssh_host_key_fingerprint": "24:e9:68:4b:06:61:0a:66:71:45:16:9c:76:13:b3:25",
   "app_ssh_oauth_client": "ssh-proxy",
   "doppler_logging_endpoint": "wss://doppler.gcp.trackerred.com:443",
   "routing_endpoint": "https://api.gcp.trackerred.com/routing"
}
cf version 6.39.1+efdd631d2.2018-09-18

What version of the buildpack you are using?

Master branch has this issue

If you were attempting to accomplish a task, what was it you were attempting to do?

We want to run rails in "dual mode", where we can run both our current major release (e.g. 4) and the next (e.g. 5).

To accomplish this, we use the standard BUNDLE_GEMFILE env var to have two versions of the Gemfile and corresponding lockfile: Gemfile_rails4[.lock] and Gemfile_rails5[.lock].

This allows us (in conjunction with a RAILS=[4|5] env var to control other version-specific feature flagging) to easily determine which version of rails will run.

What did you expect to happen?

Even if the var isn't set in the manifest, everything in the buildpack should work without errors if the BUNDLE_GEMFILE is set on the app (via set-env) prior to cf push or other commands. I.e. the buildpack will respect the value of that env var and always use the specified name for the gemfile and lockfile.

What was the actual behavior?

Unless there is a dummy (empty) Gemfile.lock file existing, you get the following error on a cf push: "Gemfile.lock required"

This comes from the following line:

https://github.com/cloudfoundry/ruby-buildpack/commit/1037ea8d0705f7076dc8d17eeecf1e7d6c2f8ecb#diff-13bb68c3a6aee65b3524151744eff338R125

See also this thread on the internal buildpacks slack channel: https://pivotal.slack.com/archives/C05692KCR/p1539111127000100

This looks like it might have a recent change that was an oversight to properly supporting the previously supported (for a long time) 'BUNDLE_GEMFILE' behavior.

Please confirm where necessary:

• [ x] I have included a log output
• [ x] My log includes an error message
• [ x] I have included steps for reproduction

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161122636

The labels on this github issue will be updated when the story is started.

[sclevine]

Agree, we should also respect this env var for detection if we aren't already.

[zmackie]

Hey @thewoolleyman, We've pushed some changes to develop which should address this issue, so you should be good to use the latest commit on develop (https://github.com/cloudfoundry/ruby-buildpack/commit/132b5ab7835fdda4f7d02e515c0eba81ee522076) or you can just wait for our next release. Let me know if there are any further issues.

[zmackie]

Fixed as of https://github.com/cloudfoundry/ruby-buildpack/commit/132b5ab7835fdda4f7d02e515c0eba81ee522076 Closing.

[thewoolleyman]

Thanks for the quick fix! We will try it out and let you know if we have any issues.