GitHub Actionsで
リリースしていたら、
無料枠を使い切った

by
  • TauriアプリのリリースをGitHub Actionsで自動化したところ、macOSランナーを含む複数OSのビルドを繰り返したことで、月2,000分の無料枠をすぐに使い切りました。
  • 上限に達するとpublishジョブが起動せず、コードではなく支払い・spending limit設定の問題としてエラーが出ます。
  • macOSランナーはLinuxより単価が高く、失敗したworkflowの再実行も分数を消費するため、個人開発でも想定外に早く枠が尽きます。
  • 対策として、日常のpushではLinuxのみビルドし、macOS向けDMGはタグpushやworkflow_dispatchによる手動実行に限定するのが有効です。

関連記事

1. GitHub Actionsには（当然ですが）利用制限がある

1. GitHub Actionsには（当然ですが）利用制限がある

Tauriで作ったデスクトップアプリを、GitHub Actionsでビルド・リリースできるようにしました。

開発環境はLinuxですが、GitHub ActionsのmacOSランナーを使えば、macOS向けのDMGも自動で作れます。
CI/CD、つまりコードをpushしたら自動でテストやビルド、配布まで進める仕組みです。

最初はとても快適でした。

ローカルにmacOS環境がなくても、Release workflowを回せば、Linux版とmacOS版の成果物がGitHub Releasesに並びます。
前回の記事で書いた「LinuxだけでmacOS向けDMGまで作る」流れの続きです。

ところが、何度かビルドとリリースを試しているうちに、GitHubから通知が届きました。

1. GitHub Actionsには（当然ですが）利用制限がある
1. GitHub Actionsには（当然ですが）利用制限がある

まず、GitHub Actions minutes の90%を使ったという通知です。

表示を見ると、2,000分中1,854分を使用していました。

その後、100%の通知も届きました。

2,000分中2,000分。
つまり、その月に含まれるActions minutesを使い切った状態です。

2. 失敗したのはpublishジョブ

GitHub Actionsの画面を見ると、Release workflowは失敗していました。

2. 失敗したのはpublishジョブ

ただし、ビルドそのものはすべて失敗していたわけではありません。
Matrix buildでは3つのジョブが完了し、その後のpublishジョブで止まっていました。

2. 失敗したのはpublishジョブ
2. 失敗したのはpublishジョブ

エラーメッセージは次の内容でした。

2. 失敗したのはpublishジョブ

The job was not started because recent account payments have failed or your spending limit needs to be increased.

つまり、依存関係のエラーでも、Tauriのビルドエラーでも、YAMLの書き間違いでもありません。

GitHub Actionsの使用量が無料枠に達し、さらに追加利用のための支払い方法やspending limit、つまり使用上限の設定に引っかかったため、ジョブが開始されなかったのです。

3. macOSビルドは便利だが、何度も回すと重い

今回のworkflowでは、Linux向けに1つ、macOS向けにApple SiliconとIntel Macの2つ、合計3種類をビルドしていました。

3. macOSビルドは便利だが、何度も回すと重い

GitHub-hosted runner、つまりGitHubが用意している実行環境を使うと、自分のPCにそのOSがなくてもビルドできます。
これは非常に便利です。

一方で、GitHub Actionsのminutesは無限ではありません。
GitHub Freeでは月2,000分が含まれますが、Private repositoryでGitHub-hosted runnerを使う場合、その無料分を消費します。
公式ドキュメントでも、GitHub FreeのActions minutesは月2,000分とされています。

さらに、macOSランナーはLinuxランナーより単価が高く設定されています。
公式ドキュメントでは、Linux、Windows、macOSでrunnerの分あたり料金が異なり、macOSはLinuxより高い料金として示されています。

4. 今回学んだこと

GitHub Actionsでリリースを自動化すると、手元にないOS向けの成果物まで作れるようになります。

4. 今回学んだこと

しかし、便利だからといって何度もRelease workflowを回すと、個人開発でもすぐに無料枠を使い切ることがあります。

とくに、次のようなworkflowは注意が必要です。

  • pushのたびに複数OSでビルドする
  • macOS向けのビルドを毎回走らせる
  • 失敗したworkflowを何度もre-runする
  • Release用のpublishジョブまで自動で実行する

対策としては、普段のpushやPRではLinuxだけをビルドし、macOS向けDMGはタグを打ったときだけ作る構成にするのがよさそうです。

たとえば、日常の確認は軽いCIにして、Release workflowは v0.1.12 のようなタグをpushしたときだけ動かす。
あるいは workflow_dispatch を使って、手動実行に限定する。

CI/CDは自動化できるほど便利になりますが、自動化した処理は、失敗も含めて実行時間を消費します。

今回の失敗は、コードの問題ではなく、リリース自動化がちゃんと動くようになったからこそ見えてきた運用上の制限でした。