S3 bucket layout breaks RVM

[coderanger]

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, and 2.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 with 2.3 seems to be that the travis-rubies S3 bucket was set up with everything under a single binaries 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 the binaries/ "folder" should fix this.

[coderanger]

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

[mpapis]

@coderanger or maybe you could open a PR for RVM to add support for nested directories? my guess is that we can:

• detect the extra directory levels (/binaries)
• get index from proper level (https://s3.amazonaws.com/travis-rubies)
• use the suffix (binaries) as a filter

...well just guessing, but that would be the best fix if I understood the problem corectly

[coderanger]

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.