GitHub Actionsでrubyを使うなら ruby/setup-ruby を使おう

GitHub Actionsで Ruby を使うための現状と展望（2019/01/05時点） - masa寿司の日記 のその後です。

前回の記事まとめ

  • GitHub Actionsで Rubyを使いたいときに、公式（GitHub）が出している actons/setup-ruby は期待する動作をしないから使わないほうがいい
  • VM上で直接Rubyを動作させたいならいくつか選択肢があるが、 @eregon が作っている eregon/use-ruby-action が様々な面でおすすめ。
  • eregon/use-ruby-action が出てきたので actions/setup-ruby も改善されるかもしれない

現在の状況

  • eregon/use-ruby-action は ruby/setup-ruby へと移管され、Rubyコミュニティが公式にサポート
  • 今後 ruby/setup-ruby と actions/setup-ruby がどういう関係性になるかは明らかになっていない
    • だけどもう ruby/setup-ruby 使っていればOK

前回記事から後の展開

（以降、前回記事読んでないとわからない箇所が多々あるかもしれませんので、一読をおすすめします）

その後も actoins/setup-ruby をどうするかという議論が以下のissueで続けられていました。

github.com

だいぶ長いので興味ある人だけ読んでもらうのが良いと思いますが、@eregon による実装が出た後、eregon/use-ruby-action が実質的に actoins/setup-ruby の後継となることについては早い段階で関係者の合意が取れていましたが、ビルドされたRubyが個人用アカウント上（eregon/ruby-install-builder）にあることがGitHub Organization所属のメンバーから懸念されていました。actions/setup-ruby はGitHub公式のactionであるため、その参照先がたとえRuby comitterであっても個人のアカウントというのは了承しづらい、ということでしょう。GitHub側としてはnpmのように「オフィシャルに用意されたバイナリをダウンロードしてtool-cacheに入れる」という形式が好ましいと考えていたようです。

そこまで話が進んだ段階で一度議論は膠着し、GitHubのメンバーからADR( Architecture Decision Record)が出されるも、「actions/setup-ruby が実質選択肢から外れてる状態どうするの？」という本質的な部分については進展が無いままでした。actions/setup-ruby のREADMEで eregon/use-ruby-action を代替として薦めようという案も出たのですが、やはり先程の理由と同じく、GitHub側がオフィシャルではない１個人のactionを公式actionの代わりに推薦するということについては抵抗があるようで、実現しませんでした。

結果として、上記の議論が進む間でも「使っていたバージョンのRubyが消えた」「そもそも利用可能なRubyのバージョンがわからん」という質問が散発的に生じる事態は変わらない一方で、Issueが立ったときに推薦される代替候補はもっとも適切な実装である eregon/use-ruby-action であり、それが各issueのコメントを通じて広まっていくという形で徐々に沈静化していきました。乱立していたissueも整理され（何故か突然Rails comitterでGitHubメンバーの@eileencodes がいくつかcloseしていったりもした）、eregon/use-ruby-action がいつどういった形で正式に actions/ruby-setup の後継になるのか、というのを待つのみとなっていました。

ruby/setup-rubyの誕生

そんな中、2/6に eregon/use-ruby-action が ruby/setup-ruby となり、個人アカウントからRubyコミュニティのorganizationアカウトに移行されました。

同様に実際にRubyをビルドする eregon/ruby-install-builder は ruby/ruby-builder　へと移行しました。これにより、actions/setup-ruby で懸念されていた個人アカウントへの依存という問題は解消しました。

また、ruby/ruby-builder でビルドされるRubyのバージョンも当初より大きく増え、EOLを迎えたRubyも含まれています。これにより、私が作ったactionも含め、ruby-build を使って自前でビルドするという選択はほぼ不要になったともいえます。そのため、現時点では相当古いRubyを直接VMで動かしたいというニーズがない限り「ruby/setup-ruby を使っていれば問題ない」といえる状況になりました。

ここまで至るに当たっては本当に @eregon の功績が大きく、GitHub Actions上でRubyを使うユーザの一人として、彼に心から感謝したいと思います。actions/setup-ruby に変わる実にスマートな設計と実装を素早く提供し、actions/setup-ruby　での議論も彼が積極的に先導してくれて、最終的に ruby/setup-ruby の実現につなげてくれました。ほんとに見事な動きだったと思います。

残された問題と根本原因

さて、残る問題は「 actions/setup-ruby どうなるの？」ということになります。今回、公式にGitHub Actions向けのRubyのバイナリが提供されるようになったのですが、同時に ruby/setup-ruby も提供されているため、 actions/setup-ruby の存在意義が無くなっています。今後、GitHub側がこれについてどう判断をするのかは気になるところです。

また、同様にactions/virtual-environments で現在提供しているRubyのパッケージがどうなるのかについても判断が求められるでしょう。本を正せば、今回起きた一連の混乱は actions/setup-ruby というより actions/virtual-environments が提供するtoolchainの運用ポリシー（popularなものだけ採用し、最新版だけインストールする）というアプローチが開発者の利用形態にマッチしないところから発生していると言えます。この点について根本的な対処が起きない限り、今後も actions/virtual-environments が提供する言語やアプリケーションについては今回のようにコミュニティ側が解決策を用意するという結末にならざるを得ない可能性が高いんじゃないでしょうか。それであればdocker利用を推奨するほうが遥かにデベロッパーフレンドリーな可能性が高く、結果的に actions/virtual-environments toolchain の存在意義が薄れていくように思えます。

個人的には toolchainでの提供を諦めてCircleCIなどのようにdockerベースでの利用をメインの使い方とし、VM上で直接環境を構築する方法はパフォーマンス向上用の選択肢として位置づけると、self-hosted runnerとの兼ね合いも良くなってバランス取れるように感じます。ただ、今からtoolchainを取り下げるとなるとユーザの反発も大きいでしょうから、難しいところですね。