heroku / heroku/heroku-buildpack-ruby
The "Ruby version does not exist for this stack" warning doesn't explain sticky versions
- Dominant language
- Ruby
- Stars
- 785
- Forks
- 1.8k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 8
Description
In https://heroku.support/967916 after upgrading from Heroku-16 to Heroku-20, builds of an existing app started failing with:
```
-----> Building on the Heroku-20 stack
-----> Ruby app detected
-----> Installing bundler 1.17.3
-----> Removing BUNDLED WITH version in the Gemfile.lock
-----> Compiling Ruby/Rack
Command: 'set -o pipefail; curl -L --fail --retry 5 --retry-delay 1 --connect-timeout 3 --max-time 30 https://s3-external-1.amazonaws.com/heroku-buildpack-ruby/heroku-20/ruby-2.3.4.tgz -s -o - | tar zxf - ' failed on attempt 1 of 3.
Command: 'set -o pipefail; curl -L --fail --retry 5 --retry-delay 1 --connect-timeout 3 --max-time 30 https://s3-external-1.amazonaws.com/heroku-buildpack-ruby/heroku-20/ruby-2.3.4.tgz -s -o - | tar zxf - ' failed on attempt 2 of 3.
!
! The Ruby version you are trying to install does not exist on this stack.
!
! You are trying to install ruby-2.3.4 on heroku-20.
!
! Ruby ruby-2.3.4 is present on the following stacks:
!
! - cedar-14
! - heroku-16
!
! Heroku recommends you use the latest supported Ruby version listed here:
! https://devcenter.heroku.com/articles/ruby-support#supported-runtimes
!
! For more information on syntax for declaring a Ruby version see:
! https://devcenter.heroku.com/articles/ruby-versions
```
In this case, the app didn't have a Ruby version defined in `Gemfile.lock`, so the `2.3.4` version wasn't something they'd specified, but due to the sticky versions feature.
Whilst the above error message does link to docs that say how to specify a version explicitly, it requires both reading those docs and a couple of mental leaps to understand that the issue may be due to no version being specified. What also added to the confusion in this case, was that their review apps did work, since they were starting with a clean cache so defaulted to newer Ruby.
As such it would be great to explicitly call out why `2.3.4` was used in this case.
For example during successful builds, this warning is shown:
```
-----> Detecting rake tasks
###### WARNING:
You have not declared a Ruby version in your Gemfile.
To declare a Ruby version add this line to your Gemfile:
```
ruby "2.6.6"
```
For more information see:
https://devcenter.heroku.com/articles/ruby-versions
```
However the build doesn't get as far as showing that warning in the stack upgrade case.
(For what it's worth the Python buildpack currently has the same issue -- it uses sticky versioning but doesn't explain what happened when that version isn't found on the current stack)
cc @schneems
Contributor guide
No contributing guide indexed for this repository
Research direction
Start from the build output for the missing Ruby version on a stack upgrade and trace the sticky-version handling in the Ruby buildpack. Reproduce the heroku-20 case with Ruby 2.3.4 unavailable on that stack, then update the warning so it explains that the version came from sticky versioning and verify the resulting message.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100