GitHub Actions・2026年11月3日に確認

GitHub Actions：ホストランナーの「No space left on device」

ランナーのルートのディスクがいっぱいになった、という意味です（「デバイスに空きが無い」）。GitHub のホストの Ubuntu ランナーには最初から多くのツールチェーンが入っているので、大きなビルドや大きな Docker イメージで残りを使い切ることがあります。よくある直し方は、ジョブの最初に、そのジョブで使わない入りっぱなしのソフトを消すことです。

見え方

• ステップが自分のメッセージで失敗します。たとえば actions/cache が、同じディスクにある $RUNNER_TEMP でアーカイブを作っているとき（nixfiles #157）：

  zstd: ... No space left on device

• 空きが GitHub の決めたしきい値を下回ると、ランナーが警告の注釈を付けます。確かめるのは10秒ごとで、ランナーのコードには既定が 100 MB とあります。10月の公開の実行では（cratestack #1239）：

  You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 74 MB

• ランナー自体が自分のログを書けずに落ち、ジョブが失敗します（pmacs #450）。ジョブのログがまったく残らないこともあります（coding-adventures #17652）：

  System.IO.IOException: No space left on device : '/home/runner/actions-runner/cached/2.338.2/_diag/Worker_20261102-200058-utc.log'

ホストランナーにある容量

• GitHub のドキュメントは、標準のホストランナーのどれにも 14 GB の SSD と書いています。保証されているのはこの量だけです。
• 実際の量はリポジトリで変わります。runner-images の担当者は2026年8月5日に、公開のリポジトリは 150 GB のディスクで空き約 90 GB の4コアの VM、非公開のリポジトリは 75 GB のディスクで空き約 14 GB の2コアの VM と書き、保証はどちらも 14 GB だけだと添えています（runner-images #14492）。
• 公開のリポジトリでも、大きいディスクが当たるとは限りません。10月31日、ある公開のプロジェクトでは、同じマージキューの中で、ubuntu-latest のジョブの一部は空き約 19 GB、ほかは約 89.5 GB で始まっていました（ravel #3564）。

ジョブの最初に出しておくと、失敗した実行がどちらに当たったかが分かります：

- run: df -h /

空きを作る

2026年9月17日、公開のリポジトリの ubuntu-24.04 のランナーで、入りっぱなしのツールチェーンをそれぞれ消して空いた量です（jlumbroso/free-disk-space の CI のログから）。使える量は 87 GB から 119 GB になりました。ubuntu-latest の移り先の Ubuntu 26.04 のイメージにも、同じツールチェーンが入っています（10月26日のイメージの README）：

• Android SDK（/usr/local/lib/android）：11 GiB
• .NET（/usr/share/dotnet）：5.4 GiB
• Haskell（/opt/ghc と /usr/local/.ghcup）：3.6 GiB
• setup-python・setup-node などが最初に見るツールキャッシュ（/opt/hostedtoolcache）：5.3 GiB
• 大きな apt のパッケージ（LLVM・PHP・MySQL・MongoDB・ブラウザー・Azure CLI・Google Cloud CLI など）：4.5 GiB
• キャッシュ済みの Docker イメージ：1.9 GiB

- name: Free disk space
  run: |
    df -h /
    sudo rm -rf /usr/local/lib/android /usr/share/dotnet /opt/ghc /usr/local/.ghcup
    docker image prune --all --force
    df -h /

• 消すのは、あとのステップで使わないものだけにします。Android のビルドには SDK が要ります。ツールキャッシュが無いと、setup のアクションはそのバージョンをダウンロードします。遅くはなりますが動きます。
• 消すのには時間がかかります。そのログでは、Android のディレクトリだけで約1分でした。
• container: で動くジョブは、コンテナーの中で消すので、ホストには何も空きません。あるプロジェクトのジョブは10月19日から空き約 12 GB で始まっていて、片づけをホストで動かすようにして直しました（uno.chefs #1778）。
• /mnt に別のディスクがあるランナーもありますが、すべてではありません。あるプロジェクトでは、24.04 のランナーにはあり、26.04 には無かったそうです（continuum #5650）。そこでビルドする前に df -h で確かめます。

使う量を減らす

• あとのステップで要らないビルドの出力（テストの実行ファイルや途中のイメージなど）を、ジョブの区切りごとに消します。
• 大きな部品をいくつもビルドしてテストするジョブは、別々のジョブに分けます。ジョブごとに新しいランナーが来ます。
• キャッシュのぶんの空きを残します。actions/cache は、アップロードの前にアーカイブ全体をルートのディスクに書きます。
• それでも足りなければ、大きいランナー（有料・ディスクの大きさが決まっている）か、セルフホストランナーなら、使える量がはっきりします。

見分け方

• ジョブが「The runner has received a shutdown signal」や「lost communication with the server」で終わる：ディスクが満杯でもそうなりますが、ほかの過負荷でも起きます（停止の合図・通信が切れたランナー）。
• アップロードが「Artifact storage quota has been hit」で失敗する：これは GitHub にあるアカウントのアーティファクトの保存容量で、ランナーのディスクではありません（アーティファクトの保存容量）。
• セルフホストランナーなら、容量は自分のマシンのものです。そのマシンで作業ディレクトリと古いチェックアウトを片づけます。

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：ubuntu-latest の Ubuntu 26.04 への移行 · 通信が切れたランナー · 「Artifact storage quota has been hit」 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English