Ruby Buildpack 1-9-x defaults to Ruby 3-1
Article ID: 298293
Updated On:
Products
VMware Tanzu Application Service for VMs
Issue/Introduction
Starting with Ruby Buildpack v1.9.x, the default ruby version has been updated to v3.1.
Please ensure applications that leverage ruby_buildpack are compatible with ruby 3.1 prior to upgrading the Ruby Buildpack to v1.9.x.
Example observed impact:
Tanzu Application Service (TAS) Smoke-test releases prior to v4.8.2 are not compatible with Ruby Buildpack v1.9.x.
Running the smoke-test errand with ruby_buildpack v1.9.x+ and smoke-test release < v4.8.2 will result in the following error which crashes the smoke-test app and fails the smoke test errand:
Smoke-test release v4.8.2+ have been patched to work with ruby_buildpack v1.9.x and are available since the following versions of TAS:
Please note the version of the ruby_buildpack and smoke-test packaged together in TAS should work by default. This example failure was observed when we updated the ruby_buildpack to v1.9.x on an existing TAS installation. Please see this KB article for more information on the TAS smoke test.
Please ensure applications that leverage ruby_buildpack are compatible with ruby 3.1 prior to upgrading the Ruby Buildpack to v1.9.x.
Example observed impact:
Tanzu Application Service (TAS) Smoke-test releases prior to v4.8.2 are not compatible with Ruby Buildpack v1.9.x.
Running the smoke-test errand with ruby_buildpack v1.9.x+ and smoke-test release < v4.8.2 will result in the following error which crashes the smoke-test app and fails the smoke test errand:
2023-01-26T09:19:19.89-0500 [APP/PROC/WEB/0] ERR bundler: failed to load command: rackup (/home/vcap/deps/0/vendor_bundle/ruby/3.1.0/bin/rackup) 2023-01-26T09:19:19.90-0500 [APP/PROC/WEB/0] ERR /home/vcap/deps/0/vendor_bundle/ruby/3.1.0/gems/mustermann-1.0.3/lib/mustermann/regular.rb:22:in `initialize': wrong number of arguments (given 2, expected 1) (ArgumentError)
Smoke-test release v4.8.2+ have been patched to work with ruby_buildpack v1.9.x and are available since the following versions of TAS:
Please note the version of the ruby_buildpack and smoke-test packaged together in TAS should work by default. This example failure was observed when we updated the ruby_buildpack to v1.9.x on an existing TAS installation. Please see this KB article for more information on the TAS smoke test.
Environment
Product Version: 2.11
Resolution
In the event the Ruby Buildpack v1.9 line is incompatible with applications running on the platform then the following workarounds are available:
Depending on your scenario, you may want to make ruby_buildpack v1.9.x available in the environment but not the default.
### Example where ruby_buildpack v1.9.x is the default, and we want to revert to previous ruby_buildpack as the default but make v1.9.x available in the environment for testing:
Alternatively you may want to make ruby_buildpack v1.9.x the default, but provide a previously known working buildpack to be available so that developer apps can use if needed while they update their apps to be compatible with ruby 3.1.
### Example where ruby_buildpack v1.9.x is the default, and we want to provide a previously known working ruby_buildpack in the environment for staging and running applications while the impacted apps are updated to be compatible with ruby 3.1:
Note - Buildpacks can be downloaded from Broadcom Support Portal. In this example, we downloaded ruby_buildpack v1.8.60
Now if an application needs to be updated to be compatible with ruby 3.1 then the application can reference the provided buildpack name in their cf manifest or push command.
- Update applications to be compatible with ruby 3.1
- cf-hello-worlds app has this example commit showing the version updates necessary in Gemfile.lock and Gemfile for application to work with ruby 3.1.
- Every application is different and may have other dependencies that can break so do not assume this as a generic solution. Ultimately the developer needs to review and test code to ensure compatibility with ruby 3.1.
- Push up a previously known working ruby_buildpack so that ruby apps can stage and run. This allows availability of the application while updating them to be compatible with ruby 3.1
Depending on your scenario, you may want to make ruby_buildpack v1.9.x available in the environment but not the default.
### Example where ruby_buildpack v1.9.x is the default, and we want to revert to previous ruby_buildpack as the default but make v1.9.x available in the environment for testing:
cf update-buildpack ruby_buildpack --rename=ruby_buildpack_1_9 cf create-buildpack ruby_buildpack ~/Downloads/ruby_buildpack-cached-cflinuxfs3-v1.8.60.zip 3
Alternatively you may want to make ruby_buildpack v1.9.x the default, but provide a previously known working buildpack to be available so that developer apps can use if needed while they update their apps to be compatible with ruby 3.1.
### Example where ruby_buildpack v1.9.x is the default, and we want to provide a previously known working ruby_buildpack in the environment for staging and running applications while the impacted apps are updated to be compatible with ruby 3.1:
Note - Buildpacks can be downloaded from Broadcom Support Portal. In this example, we downloaded ruby_buildpack v1.8.60
cf create-buildpack ruby_buildpack_1_8_60 ~/Downloads/ruby_buildpack-cached-cflinuxfs3-v1.8.60.zip 3
Now if an application needs to be updated to be compatible with ruby 3.1 then the application can reference the provided buildpack name in their cf manifest or push command.
Feedback
Yes
No
Powered by
