Considering to move the list of ruby versions to ruby-builder

[eregon]

Currently the list is at https://github.com/ruby/setup-ruby/blob/master/ruby-builder-versions.json But that means every time a Ruby is released we need to merge the automatic PR and make a release of setup-ruby too, even if nothing changes except that list (well, and the README, but we could just link to the list from the README). That's a non-trivial overhead.

I'm thinking to move that list to https://github.com/ruby/ruby-builder which has the built Rubies already anyway. It actually used to be like that a long while ago. I don't recall all the reasons but the most important where:

• I used some NPM package for the HTTPS request, and that was getting multiple security issues per month (how does one even work in that ecosystem?) which was untenable. So having the file here avoided to depend on a problematic NPM package. But these days there is https://github.com/actions/toolkit/tree/main/packages/http-client or https://github.com/actions/toolkit/tree/main/packages/github which should address that
• We might hit some GitHub limits potentially if too many such requests are done in an amount of time.
• It seems a bit cleaner/safer to have the list in this action directly, rather than having to fetch it over the network. But the churn on releases is not great.
• Having the list here means new versions are automatically tested in the PR adding those versions.

One alternative might to merge the PR & create the release automatically, but that seems difficult to do safely.

[eregon]

It looks like setup-python does something similar: https://github.com/actions/python-versions/blob/main/versions-manifest.json

There is even some toolcache function to get the manifest: https://github.com/actions/toolkit/blob/361a115e538ac6d8eb06cc47f3fcecce557d04c8/packages/tool-cache/src/tool-cache.ts#L589 But they were hitting limits, and using raw URLs seems to fix it: https://github.com/actions/setup-python/pull/766

[MSP-Greg]

Re 'GitHub limits', I don't know what type of operations they apply to. ruby/ruby-builder is a small repo, maybe use actions/checkout to get the file.

Another issue is workflows that are using this with the ruby/setup-ruby@v1 run format, vs repos that are using the ruby/setup-ruby@3783f195e29b74ae398d7caca108814bbafde90e format.

Workflows with @v1 won't see any change from current behavior, but workflows using @<commit sha> will see changes, as ruby-builder-versions.json could change?

EDIT: Never mind the 'run format' issue. The readme could be updated to state that setup-ruby no longer locks Ruby versions, and that information should be part of the workflow file.

What about windows-versions.json?

[eregon]

I automated the creation of release with a GitHub Actions workflow. So then it's only a couple clicks per someruby release, which seems fine for now.