BEACHSIDE BLOG

Azure と GitHub と C# が好きなエンジニアの個人メモ ( ・ㅂ・)و ̑̑

GitHub Actions の storage の容量がいっぱいになった時の対処方法とエコな運用 Tips

GitHub Actions を何気に使ってると、Storage の容量がいっぱいになって GitHub Actions がエラーで実行できなかったり、ストレージの課金をせねばあかんのかと迫られることがあります。

こんな時の確認方法や対処方法と、運用で考慮しておきたい Tips を書いていきます。

記事の前半に利用制限に関して知っておきたい基礎知識、後半でエラーで使えなくなった GitHub Actions を使えるようにする方法や運用の Tips を書いていきます。

🚀 GitHub Actions の制限に関する基礎知識

GitHub Actions を使うにあたり、プラン (Free とか Pro とか Enterprise Cloud とか) に応じて無料枠がついています。制限というのは、この無料枠を使い切ることで、使い切ると GitHub Actions を実行してもエラーがはかれてが動かなくなります。

課金に関する制限は、主に Storage の容量と実行時間が対象です 。

無料枠について軽くふれると、GitHub Enterprise Cloud だと Storage の 50 GB で実行時間は 50000 分/一ヶ月です。Free プランだと Storage は 500 MB、実行時間は2000分/一ヶ月なので、特に storage はちょっと派手な検証をしたら使い切ってしまうかもですね。

ちなみに実行時間については、GitHub Hosted Runner を使ってる場合は GitHub Actions を実行する OS によって倍率がありちょっとだけ複雑です。詳しくは以下のドキュメントに書いています。

GitHub Actionsの支払いについて - GitHub Docs

制限を超えたからといって勝手に課金されることはないです。実行するとエラーで動かなくなるだけです。

課金には関係ない面での制限だと、GitHub-hosted runner なら1回のジョブの実行時間や1回のワークフローの実行時間や同時実行ジョブ数とか self-hosted runner ならそれはそれでとか色々あります。以下のドキュメントにだいたい書いてます。

Storage のリミットを超えたときのエラーメッセージ?

GitHub Actions の storage がリミットに到達した時には、GitHub Actions の実行ログをみると以下のようなエラーが出ます。

"Create Artifact Container failed: Artifact storage quota has been hit. Unable to upload any new artifacts"

Storage には、GitHub Actions の実行ログやビルドして生成した Artifacts (ワークフローで upload-artifact を使ったときに保存される) を保存されます。

その他に GitHub Packages で保存しているものも含まれます。public の repo は無料で private の repo の packages が対象です。

それがたまりにたまると無料枠を使い切ります。ただし、保存期間の設定がありその期間を超えると自動で削除されます。保存期間については後述します。

実行時間の超過について

時間超過は、私がしたことないので実際のエラーに遭遇したことはないですが、エラーも似たような感じでしょう (適当....) 。

使用量の確認方法

プランに応じて2通りの方法を紹介します。ほとんど一緒です。

Organization をもたないアカウントの場合

Free や Pro や Team プランの場合は、GitHub で右上の自分のアバターをクリック → Settings をクリックします。

左側のメニューで Billing and plans をクリックします。

表示された画面を下にスクロールすると、実行時間と Storage の使用量が確認できます。

余談: GitHub Packages は転送量の制限もある

余談として、上図で赤で囲んでいない "Packages" はデータの転送量の使用量です。これには制限がありますがこれにふれると話が膨らみすぎるので、その制限や課金方法のドキュメントリンクをはっておくだけにします。

Organization があるアカウントの場合

GitHub Enterprise Cloud などの場合は、Organization レベル の Settings (Organization のトップページの Settings タブ)→ Billing and plans から同様の内容が確認できます。
また GitHub Enterprise Cloud だと Organization を複数もてるため、Enterprise レベルの SettingsBilling からOrganization を跨いだ使用量を確認することができます。

Settings は、ログインしているアカウントのロール次第では見れない場合もあります。その場合強い権限持ってる人に相談する感じでしょうかね。

🚀 無料枠を使い切ったときの対処方法

Storage の無料枠を使い切った場合に、また使うようにするには?

Storage は前述で書いた通り実行ログや Artifacts が保存されることで消費されます。復活の儀のパターンは2通りあります。

  • 保存されている実行ログや Artifacts を削除する (推奨)
  • 課金をする (そりゃな...

各種設定は、ログインしているアカウントのロール次第では見れない場合もあります。その場合強い権限持ってる人に相談する感じでしょうかね。

Storage にたまった実行ログや Artifacts の削除方法

これが一番お手軽です。削除の方法はまず repo で GitHub Actions を開き、実行の詳細を適当にクリックします。

実行ログの削除

右上の "..." をクリック → Delete all logs をクリックすると、その実行ログが削除されます。これを愚直に繰り返す感じです。たくさんあってつらいときを想定して、あとで保存期間の設定の話をします。

ログを削除する前は以下の図のように各ジョブを展開してログをみることができます。

削除するとジョブも展開できずログがみれなくなります。

Artifacts の削除

前述同様、GitHub Actions の実行の詳細を開くと、下の方に保存されている Artifact が表示されます。これの右側にあるゴミ箱アイコンをクリックして削除ができます。表示されていない場合はそもそも保存しないか、手動で削除したかのどちらかです。

保存期間の設定によって自動削除された場合は、ごみ箱アイコンは無く、"Expired" (期限切れ) の表示がでます。

Packages の削除

これは少々ややこしい (書くのがめんどい...) のでドキュメントのリンクをはっておきます (雑

docs.github.com

ログや Artifacts の保存期間を設定する

保存期間を設定することでその期間を過ぎたものは自動で削除されます。最初からこの設定を適切に行っておくことで Storage の圧迫を避けることができます。

個人のプロジェクトとかだと私の場合は一度ちゃんと動くようになれば後日ログ見ることないし、仕事のプロジェクトでも一か月前のログをみることなんてそうそうないので、プロジェクトに応じて適切な期間を設定すればよいでしょう。

設定は各 repo の Settings → Actions の中にある GeneralArtifact and log retention で保存期間を設定できます。設定した期間を超過すると自動で消えます。

GitHub Enterprise Cloud だと Organization レベルの Settings → Actions の中にある General から同様の設定ができます。ここで設定すると、その Organization 配下の repo に設定が継承されます。継承されるのは保存期間の最大の日数なので、repo 毎に Organization で設定した日数よりも短い日数を設定することは可能です。

時間の制限を超過した場合

リセットされるまでは、課金するしかないです。時間がどれくらいかかるかはいかのドキュメントに書いていますが、個人的な所感では、自分で VM たてて CI/CD やる手間やコストよりは断然安いと思う程度の金額です。

課金をするというのは、利用上限の金額を設定して、その金額まで使えるようにするということになります。設定方法は以下のドキュメントです。

GitHub Actions の利用上限を管理する - GitHub Docs

🌏まとめ

さらっとまとめようと思ったら意外と長くなってしまいましたが、私が思う大事なことは以下の2点です。

  • Storage の無料枠を使い切ってエラーが出たら、焦らず状況を確認して無駄なリソースを削除する。
  • ログや Artifacts の保存期間を設定して、焦る機会を減らす
  • 時間を超過したら諦めて課金する、そして超過しないよう実行時間を短くするための Actions の工夫を調べる)

去年にも似たような記事書いたのですがそれの詳細版って感じですね。

blog.beachside.dev