Open coderanger opened 8 years ago
Also as a separate issue kind of, the aliases for 2.1
and 2.0
are weird:
travis@2296d5b7cd1f:~$ rvm alias list
2.1 => ruby-2.1.5
jruby-19mode => jruby-1.7.19-d19
default => ruby-1.9.3-p551
jruby-d18 => jruby-1.7.19-d18
jruby-d19 => jruby-1.7.19-d19
jruby-18mode => jruby-1.7.19-d18
jruby => jruby-1.7.19-d19
2.0 => ruby-2.0.0-p598
@coderanger or maybe you could open a PR for RVM to add support for nested directories? my guess is that we can:
/binaries
)https://s3.amazonaws.com/travis-rubies
)binaries
) as a filter...well just guessing, but that would be the best fix if I understood the problem corectly
Seems like it could be done, but probably more work than fixing it on the S3 side :) It took me long enough to figure out what the RVM code is doing, I wouldn't feel comfortable changing it on my own. Part of the problem is that both https://travis-rubies.s3.amazonaws.com/
and https://s3.amazonaws.com/travis-rubies/
are valid S3 URLs, so given a URL you need to do a lot of parsing to know what part of the URL is a prefix. Might be more work than RVM wants to do in a shell script.
I've been trying to diagnose why RVM's usual fuzzy matching hasn't been working with Travis-provided binaries. As an example case, trying to use
2.3
as a Ruby version results in a failed build.2.0
,2.1
, and2.2
work but are manually aliased to things other than the latest versions of those respective releases, which is not what I would expect. The issue with2.3
seems to be that the travis-rubies S3 bucket was set up with everything under a singlebinaries
folder. This causes RVM's S3 support to fail because the base URL (https://s3.amazonaws.com/travis-rubies/binaries
) is a 404 rather than the expected XML key list document. Reorganizing things to remove thebinaries/
"folder" should fix this.