Create a plan and design (ADR) for ruby builds at runtime

[eregon]

@bryanmacfarlane @eileencodes
cc @MSP-Greg
In #44 we agreed on prebuilding Rubies in this repository.
Here I detail some steps to get started with supporting prebuilt Rubies, based on my work in https://github.com/eregon/ruby-install-builder

To get started, we need a few things to be done by the owners of this repo:

• Create a release to store all builds, much like https://github.com/eregon/ruby-install-builder/releases/tag/builds-bundler1. The release should be public so everyone can see which Rubies are already available there.
• For that, we need a tag, I propose all-builds or builds-for-v2. The commit it points can be anything, I'd suggest the initial commit of this repository (58d0881).
• Create a branch named builder. The commit used for the branch's head doesn't matter, but I would also use the initial commit of this repository (58d0881).

Then I can add a workflow (via a PR) to the builder branch that builds Rubies and add them to that release. We can trigger builds just by pushing/PR a new commit to that branch. Changes on that branch should not directly affect users of this action, so I think it's best to be separate from master (we would not want to trigger it for every commit to master). Having a dedicated branch for this makes it easy to trigger builds manually (by merging a PR to that branch, or pushing to it).

Once that's done, we can start by building the stable releases (also for JRuby and TruffleRuby). That's easy, as shown by https://github.com/eregon/ruby-install-builder/blob/5f9e3c5e756846ee3df7af7883e136d4466fb144/.github/workflows/build.yml which does exactly that. I'll make a PR for that once the 3 items above are done.

Later on, we can then expand to eventually cover all Ruby versions.

As soon as we have some builds on that release, we can start integrating logic from https://github.com/eregon/use-ruby-action to use the prebuilt Rubies.
We'll probably want to maintain an explicit list of available Rubies in the action for nice error messages and being able to handle things like 2.4 => 2.4.9.

We might want at some point to use another tag/release for builds if we change significantly how Rubies are built. We could also reuse the same release, but currently https://github.com/actions/upload-release-asset does not allow to update an existing asset.

There are other concerns about building Rubies, but I'd rather discuss them on a PR to that builder branch to keep this issue focused.

I'm happy to make PRs for getting all this started and working, based on my experience in this area, as long as the feedback cycle is not too slow.

[bryanmacfarlane]

I think we should have a ruby-builder repo and a setup-ruby repo (exists). That keeps the concerns separate. Note we use tags and branches to version actions

The builder repos can produce a github release in that repo per immutable ruby released version. Similar to the pattern used in the runner. https://github.com/actions/runner/releases/tag/v2.164.0 (it contains a zip for a single version times n platforms supported)

This allows the setup-ruby task to query the releases api of the installer repo when resolving the semver specified in the workflow. It also allows each release to contain that version X platforms (instead of a full explosion every build). This is also consistent with other actions like setup-node where there's a global distribution point that's queryable and the setup action accepts semvers and resolves to download.

Finally, instead of iterating with discussions in multiple issues, I think we should write up an ADR document. It's the process we follow regardless of whether we're developing or it's a contribution.

I'll start an ADR document

[bryanmacfarlane]

I updated the title since we need to write up an ADR before we get started doing anything.

This issue will track that work.

[eregon]

I think we should have a ruby-builder repo and a setup-ruby repo (exists). That keeps the concerns separate. Note we use tags and branches to version actions

Right, I think this would be cleaner.

The builder repos can produce a github release in that repo per immutable ruby released version.

That would work, but I think that's a lot of extra work.
For example, https://github.com/eregon/ruby-install-builder/releases/tag/builds-bundler1 has 35 versions so we'd need 35 releases to support the same versions.
Just by that number we'll probably want to automate the creation of the release, which means it's problematic if the ruby build fails as then the release was created but no file uploaded.
BTW, https://github.com/actions/create-release currently fails if the release already exists.
We'll also have to care about draft vs published releases if we want to use releases to list available versions.
If something change in the virtual environements, such as a newer OpenSSL version which is not perfectly compatible, then updating these releases will be slow and can't be done atomically. If we used a single release, we can just create a new release with all builds for the new virtual environments and when ready switch to it in setup-ruby.

In summary I think that strategy involves a lot of extra manual steps (or a lot more work to get things automated) and will slow us down significantly.
If it's a single release, there are no manual steps around managing releases after it's done once.
That model of a release per version makes perfect sense when the repo is the source itself, but I think for a builder it's suboptimal.

[bryanmacfarlane]

I think there's a fairly straight forward ways to complete automate it with a single workflow. The discrete versions are much cleaner, offer the use of a real api and allow for scenarios such as advertising expectations (the pre-release bit).

The other option is universal packages in GPR. I'll update the ADR to cover that option.

It might be more work, but if we're going to do this in the actions org, we want the right pattern. It should be queryable releases and/or GPR.

#49

[bryanmacfarlane]

Closing this so discussions can happen in the ADR PR (we do that at GitHub so the history and design considerations are captured).