GitHub ActionsよりもAWS CodeBuildの方が安かった為、AWS CodeBuildでSelf-Hosted RunnerのJust In Time Runnerを動かそうとしました。そこで調査をしたのですが、断念する事にしました。
これらは全て2023/11/19時点で観測した事象でです。
Just In Time Runnerについて
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-just-in-time-runners
どのようなシステムを組んだか
workflowのwebhookがLambdaに送られ、そこでjust in timeのconfigを作成し、CodeBuildに渡してself hosted runnerを走らせ、自動的にrunnerが終了するというシステムです。
コードは以下。
github.com
微妙な点
まとめると、concurrencyやキャンセル周りの処理が微妙で癖がある点と、プロビジョニングが1分以上かかる点が厳しいと思います。
お手軽に動くという感じではなく、追加で開発して、用途を絞って活用すればなんとか使えるかなくらいに思っています。
concurrencyを設定して、同じブランチに対して複数のworkflowを動かしたくない場合。
Pushした後にもう一度すぐにPushすると2つのwebhookが送られ、2つのCodeBuildが動くが、GitHub上ではrunnerに1つめのリクエストは送られずに、後の2つめのリクエストだけが送られます。2つCodeBuildが起動しているのに1つしかリクエストを処理していないので、1つのCodeBuildはタイムアウトまで動いてしまいます。
CodeBuildでビルドをキャンセルする為にはidを使用しないといけないため、GitHubのworkflowと紐付けるのは難しそうでした。
https://docs.aws.amazon.com/codebuild/latest/APIReference/API_StopBuild.html
その為、Runnerを起動してから30秒後にログを確認して、キューを受け取っていなければCodeBuildを終了させるというスクリプトを書きました。
concurrencyを設定しており、CodeBuild側でタイムアウトしたり、その他の理由でビルドが終了した場合
前のビルドがこの様な状態になっており、ここに追加のコミットをすると5分の間、追加のビルドが動きませんでした。前のビルドのキャンセルボタンを押してもキャンセルされずに5分待つことになります。この挙動をする時もあれば、しないで問題なくキャンセルされる時もあるのが厄介です。
プロビジョニングが遅い
Androidのビルドをする為に2GBくらいのコンテナを作成しましたが、プロビジョニングに70秒くらいかかりました。この時間も請求に入るのが厳しいです。他にもWebの記事を見ているとプロビジョニングが遅いという意見は見受けられました。
GitHub Actionsについては、GitHubが用意するマシンについてはプロビジョニングの時間は値段に含まれない点が良いところです。
大きいビルドで長い時間立ち上げるものについてはGitHub Actionsより安くなってコスパいいかなと思います。
おわりに
なんとか工夫次第で使えるかなといった感じでした。
