GitHub Actionsのサードパーティーマネージドランナーの紹介

この記事は はてなエンジニア Advent Calendar 2023 の 2024年1月4日 の記事です。


GitHub Actionsの実行環境であるランナーには、GitHubが提供するGitHub ホステッド ランナーと、自分でランナーを用意・管理するセルフホステッド ランナーの大きく二種類があります。

最近はGitHub ホステッド ランナーにもラージランナーが用意されるようになり、ある程度ランナーのスペックを選べるようにもなりましたが、他のCIサービスと比べてもスペックの割にコストが高めである感じは否めません。一方でセルフホステッド ランナーにはスペックを自分で調整できる自由度がありつつも、管理する手間とコストが掛かってきます。

こうした隙間を突くように、サードパーティーによるマネージドなセルフホステッド ランナーを提供するサービスが増えつつあります。基本的には runs-on: に各サービスが提供するランナーの名前を指定するだけで、その名前に応じた環境(CPUアーキテクチャーやスペック、OS)を選べる、という形になっています。

自分が見かけたり調べたり実際に使ってみたものをいくつか紹介してみようと思います。

BuildJet

はてなでも昨年から一部のチームで使用していて、CI/CDの速度向上の恩恵を受けています。管理画面はあまりいけていなくて、vCPU数上限がある割にはどれだけ消費されているかのリアルタイムの数値やグラフでの確認ができなかったりするので、キャパシティプランニングが難しいですね(上限に引っ掛かるとジョブの起動待ち状態になるので、悲鳴ベースで対処していくしかない)。

BuildJetのPricing

Namespace

  • 単なるGitHub Actionsのマネージドランナーというだけではなくて、Dockerイメージのリモートビルダーや、開発環境としてのKubernetesクラスターの作成もできたりする
    • Webアプリケーションのプレビュー環境機能なども
  • キャッシュのアップロード・ダウンロードではなく、キャッシュ用のボリュームをアタッチすることでの高速化が最近サポートされたようでとても良さそう
  • Pricingはプラン毎にシート数やコミコミのリソースが決まっている(超過分は別途)、という形なので若干複雑

NamespaceのPricing

GitRunners

  • 雰囲気としてはBuildJetに近そう
  • コスト的にはGitHub ホステッド ランナーとBuildJetの中間
    • 並列数の制限はなさそうなので、BuildJetのvCPU上限の拡張に課金するよりもいいケースもありそう
  • 1vCPUを選べるのが特徴的(GitHub ホステッド ランナーやBuildJetは最低2vCPU)
  • 個人で少し触ってみた程度だが、管理画面はBuildJetよりもいけていそう
  • Upcoming featuresのアピールが気になる
    • Persistent storage for all ephemeral runners and flamegraph visualizations to analize workflows runtimes.

    • 前者はNamespaceのCache Volumesに相当するものっぽい
    • 後者はボトルネックを見つけるのに便利そうで、やはり管理系の機能には力を入れていそう

GitRunnersのPricing

WarpBuild

  • Argonautというクラウドサービスのデプロイツールからピボットしたサービスらしい
  • こちらもBuildJetと近しい雰囲気
    • CPUパフォーマンスがいい
    • x86_64もARMもサポート
  • 並列数の制限もなし!
  • SSHデバッグ可能というのは面白そう・便利そう
    • この時の課金がどうなるのかは気になる
  • PricingもGitHub ホステッド ランナーの半額なので、BuildJetと同様
    • vCPUの選択肢が2X、4X、16Xとなっていて、8Xがないのが悩ましいかもしれない
  • Coming soonにも期待したい
    1. Faster distributed caching
    2. Windows and MacOS runners
    3. Custom runner images ... and more!

WarpBuildのPricing

Cirrus Runners

まとめ

ということで、自分の知る範囲でざっくりとGitHub Actionsのマネージドランナーについて紹介してみました。改めて調べてみると、新サービスが増えたり、各サービスで機能追加の予定も出ていたりして楽しみが増えました。逆にBuildJetは最近あまりアナウンスやブログの投稿がなかったりするのは気がかりですね。他にも同種のサービスをご存知の方がいたらぜひ教えてください!

iOSDC Japan 2023 day2でLT登壇します #iosdc

すでに始まってしまったiOSDC Japan 2023。今年ははてな勢は4人でお邪魔しております。自分も2019年以来、4年振りのオフライン参加をとても楽しんでいます!

X(Twitter)ではお知らせしていたものの、ブログには書いていなかったので改めて共有ですが、最終日の明日9/3 (日) day2 ラストのLT大会にて登壇させていただきます!(最後から4番目)

fortee.jp

Renovate芸人・またiOSDC JapanのLT芸人として頑張りたいと思います⚡️

カンファレンスの最後までワイワイ楽しみましょう!😆

UISearchBarのデフォルトの背景色は `UIColor.tertiarySystemFill`

Use system fill colors for items situated on top of an existing background color. System fill colors incorporate transparency to allow the background color to show through.

Use this color to fill large shapes, such as input fields, search bars, or buttons.

と説明されているとおりだった。

ライトでの cgColor の出力はこんな感じ:

<CGColor 0x60000260e1c0> [<CGColorSpace 0x60000260cf00> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; sRGB IEC61966-2.1; extended range)] ( 0.462745 0.462745 0.501961 0.12 )

XcodeGenのpackagesをRenovateで更新するプリセットを用意しました

ikesyo.hatenablog.com

この時の発表でXcodeGenの packagesをRenovateのregex managerで更新する方法を紹介してから、複数回言及・参照されることがありました。

これはこの方法を一般化しておいた方がよかろう、と思って hatena/renovate-config にXcodeGen用のプリセットを用意してみました。XcodeGenxcodegen ディレクトリにファイルを分割しているケースにも対応しています。

fileMatch が合致する場合はこのプリセットをextendsするだけで活用できるので、どうぞご利用ください。

{
  "extends": ["github>hatena/renovate-config:xcodegenSwiftPackages.json5"]
}

あわせて読みたい

Mojoのパラメータ(コンパイル時メタプログラミング)を使ったFizzBuzzを書いてみる

Mojoが発表されて早速盛り上がっていますね。

LLVMやSwiftの作者であるChris Lattner率いるチームが開発した新しい言語ということで、Swift好きな自分としてももちろん興味があります。現時点ではPlaygroundにアクセスするのにウェイトリストに並ぶ必要がありますが、自分もアクセスできるようになったので早速ちょっと遊んでみます。

Mojoにはコンパイルメタプログラミングを可能とするパラメータという機能があって、これを遊ぶにのにFizzBuzzを書いてみましょう。

早速コードを書いてみるとこんな感じです:

fn parameterizedFizzBuzz[n: Int, counter: Int]():
    @parameter
    if counter > n:
        return
    else:
        if counter % 15 == 0:
            print("FizzBuzz")
        elif counter % 3 == 0:
            print("Fizz")
        elif counter % 5 == 0:
            print("Buzz")
        else:
            print(counter)
        parameterizedFizzBuzz[n, counter + 1]()

通常の引数(argument)は () に引数リストを定義しますが、パラメータ(parameter)は [] に定義します。また @parameter if を使うことで、コンパイル時にif文を実行することができます。

This makes use of the @parameter if feature, which is an if statement that runs at compile time. It requires that its condition be a valid parameter expression, and ensures that only the live branch of the if is compiled into the program.

これを実際に実行してみると正しく動作します。

parameterizedFizzBuzz[60, 1]()

ちなみに2023年5月7日現在のPlayground環境のトップレベルコードとしては60回が限界でした。61にすると elaborator expansion is 129 levels deep - infinite recursion? というエラーになりました。

error: Expression [6]:21:1: no viable expansions found
fn __lldb_expr__(__mojo_repl_arg&: __mojo_repl_context__):
^

Expression [6]:23:28:   call expansion failed - no concrete specializations
    __mojo_repl_expr_impl__(__mojo_repl_arg)
                           ^

Expression [6]:34:26:     call expansion failed - no concrete specializations
  __mojo_repl_expr_body__()
                         ^

Expression [6]:31:33:       call expansion failed - no concrete specializations
    parameterizedFizzBuzz[61, 1]()
                                ^

Expression [6]:18:46:         call expansion failed - no concrete specializations
        parameterizedFizzBuzz[n, counter + 1]()
                                             ^

Expression [6]:5:1:                                                                                                                                 elaborator expansion is 129 levels deep - infinite recursion?
fn parameterizedFizzBuzz[n: Int, counter: Int]():
^

この elaborator というのは、ロードマップの「Protocols / Traits」というセクションで少し触れられていました。コンパイルのパイプライン中でパラメータ化されたコードをインスタンス化する役割のようですね。ここの再帰に制限があるのは納得できます。

Unlike C++, Mojo does not “instantiate templates” in its parser. Instead, it has a separate phase that works later in the compilation pipeline (the “Elaborator”) that instantiates parametric code, which is aware of autotuning and caching. This means that the parser has to perform full type checking and IR generation without instantiating algorithms.

パラメータではなく引数を使った場合は1万回や10万回でも問題なかったので、普通に末尾再帰最適化もされているということでいいのかな:

fn fizzBuzz(n: Int, counter: Int):
    if counter > n:
        return
    else:
        if counter % 15 == 0:
            print("FizzBuzz")
        elif counter % 3 == 0:
            print("Fizz")
        elif counter % 5 == 0:
            print("Buzz")
        else:
            print(counter)
        fizzBuzz(n, counter + 1)

ということでMojoのパラメータで少し遊んでみました。

Mojoは現時点ではPlaygroundが公開されているだけで、手元で動かすこともできませんし、オープンソースでもありませんが、すでにGitHubリポジトリは用意されてバグレポートやフィーチャーリクエストも受け付けています。

正式リリースまではクローズドな形で開発が進み、OSS化まではしばらく時間が掛かりそうではありますが、ロードマップやChangelogもチェックしながら今後を楽しみにしていきたいですね。

なぜ人はソースコードの複数行コメントで文が分かれているのに、改行を文区切りとしてしまって句点(。)を使わないのか?

改行されているときに、文が終わっている時もあれば、文が続いている時もあって、これは前の行からの続きなのか、別の文なのかを毎回意識する必要があって読みにくいなと思ってしまうパーソンです。皆さんはいかがですか?

YAPC::Kyoto 2023に参加した&GitHub Sponsorsに登録した

yapcjapan.org

京都、それも自宅から徒歩圏の会場で開催されるということもあり、去る3月19日に初めてYAPCに参加してきました。自分はPerlは(ほぼ)書いたことがないけど、YAPCPerlに関係あるものないものも何でもありなカンファレンスという感じがして、お祭り感があってよかった。

聞いたトークはどれも面白かったんですが、OSS好きパーソンな自分としては

の3つが響いてよかった。その勢いもあって、前から長らくやろうと思ってやっていなかったGitHub Sponsorsの登録作業についに手を付けました。

ここ半年以上はOSS活動がほとんど止まっていたけれど、これを機にまたいい感じにやっていきたいところ。宣伝になりますが、ikesyoのOSS活動を応援してくれる方がいればよろしくお願いします 🙏


閑話休題。ラストの id:onishi さんによるキーノートもとてもエモくてよかったですね……大西さんの元で自分もまだまだはてなで頑張っていこう。

オフラインでのカンファレンス参加自体がiOSDC Japan 2019以来だったのでとても久しぶりな感覚で、楽しさを思い出しました。次回のYAPCは広島で開催予定らしいので、次も遊びに行きたくなってきました。今度は何かしら喋れると楽しそうでもあり、CfPも出してみたい。

スピーカー・スタッフ・スポンサー・参加者・その他関係者の方々、楽しませてもらってありがとうございました!