GitHub ActionsでNo space left on deviceが出たら、失敗pathと、そのpathがあるfilesystemを確認します。空きbyteの不足だけでなく、小さなファイルの増加によるinode不足、Docker daemon側の使用量、runner初期化時の失敗も分けます。cacheやartifactの保存上限と、job中に使うrunnerのdiskは別の容量です。
ここでは主にUbuntu系runnerで読めるGNU df/duの例を使います。WindowsやmacOSのoption、container内の見え方は、その環境の手順で確認してください。実workflow、runner、Dockerの実行や削除操作は行っていません。以下の観測例は架空です。
目次
runner種別と、失敗する前の段階を確認する
run ID、job、runner label、OS/image情報、失敗step、pathを記録します。GitHub-hostedとself-hostedでは、環境や残存データの責任範囲が異なります。ubuntu-latestというlabelだけを、常に同じimage内容・空き容量の証拠にはしません。
表は横にスクロールできます
| 失敗段階 | 調査する場所 | 区別すること |
|---|---|---|
| workflow step前の初期化 | runnerの診断情報・時刻 | cleanup stepが実行できる状態か |
| checkout・依存install | workspace・package cache | どの段階で増えたか |
| build・test | 中間生成物・展開先 | 最終成果物だけの容量ではない |
| Docker build/pull | daemonのimage・layer・cache | workspace集計だけでは見えない |
| artifactのremote保存 | 保存側のエラー条件 | runner filesystem不足と別 |
GitHub-hosted runner資料（新しいタブで開く）で、対象runnerの仕様とfilesystemを確認します。runnerの種類や契約でresource条件が異なるため、古いissueのdisk数値を現在の自分の保証値にしません。
失敗pathがあるfilesystemの空きとinodeを見る
Ubuntu系でGNU coreutilsがある場合、失敗pathまたは存在する親directoryを指定して確認します。掲載オプションの意味は、Debianが公開するGNU coreutilsのman資料で照合しています。実際のrunnerでもGNU版であることと、利用可能なオプションを確認してください。次はworkspaceを調べる例です。GITHUB_WORKSPACEが設定されたworkflowのshell内を前提とし、ローカルterminalへそのまま流用しません。
df -h "$GITHUB_WORKSPACE"
df -i "$GITHUB_WORKSPACE"
du -x -h --max-depth=1 "$GITHUB_WORKSPACE"
dfは対象pathがあるfilesystemの空き、df -iはinode、duは指定directory以下の使用量の把握に使います。du -xは別filesystemへまたがる集計を避ける例です。読めないファイルや権限で集計が欠けた場合、見えた値だけを全使用量としません。ファイル名やpathの共有範囲にも注意します。
表は横にスクロールできます
| 架空の観測 | 次の確認 | 言えないこと |
|---|---|---|
| byteの空きが少ない | 大きく増えたdirectory | inodeにも余裕がある |
| inodeの空きが少ない | 多数の小ファイル・展開物 | 大ファイル一つの削除だけで解決 |
| workspaceは小さい | 失敗pathのmount先・他領域 | runner全体も小さい |
| hostとcontainerで値が違う | mount・overlay・daemon | 片側のdfが全領域を示す |
増えたstepを前後の差で特定する
許可された検証runでは、job開始時、依存取得後、build前後、成果物圧縮前後など、必要な境界だけで同じ対象を観測します。最終的なdisk使用量だけでは、途中で最大になった瞬間を見落とします。
たとえば元データ、展開済みデータ、中間出力、圧縮成果物を同時に保持すると、最終ZIPより大きな空きが必要です。どこまでが後続stepに必要かを表にし、不要になったjob固有の一時物をいつ片付けられるか判断します。診断前にすべて消すと、原因と再現条件を失います。
表は横にスクロールできます
| データの種類 | 確認する責任 | 見直し候補 |
|---|---|---|
| source・必要依存 | 後続stepが使うもの | 必要範囲・重複取得 |
| test一時出力 | 再生成可能か・診断に必要か | 出力量と保持期間 |
| 展開物と圧縮物 | 同時に必要な区間 | 処理順と一時保存先 |
| cache | 再利用範囲とrestore先 | 不要な重複・対象過大 |
Docker使用量は別に確認する
対象runnerでDocker daemonが利用でき、jobがDockerを使っている場合は、docker system dfなどの読取でimage、container、volume、build cacheを調べます。Docker公式資料（新しいタブで開く）は、このコマンドをdaemonのdisk使用量表示と説明しています。
大きい表示を見て、volumeや全imageを無条件にpruneしません。self-hosted runnerでは別jobやserviceが利用している可能性もあります。cacheを消すと次のbuildで再取得が増えるため、一回だけ通るcleanupと、再発しない生成量の設計を分けます。
step前の失敗や責任範囲外なら診断情報を渡す
workflow stepが始まる前にrunnerの診断log書込で失敗しているなら、先頭へ追加したdfやcleanupが動かない場合があります。run ID、UTC時刻、runner label、image情報、最初の失敗path、step未実行という観測を揃えます。自分のbuildが原因と決めず、runner管理者やsupportが確認できる情報へ絞ります。
runner容量を変える場合も、利用可能なrunner種別、費用、必要なpeak使用量を別に判断します。課金のあるrunnerへ無断で切り替えることを、診断の標準手順にはしません。
修正後も同じ負荷で余裕を確認する
変更は一つずつ記録し、同じ入力と生成条件で失敗stepを越えられるか、必要成果物が欠けていないか、途中の空きとinodeに余裕があるかを確認します。ログが残ったこととbuild・test成功は別です。
出力量制限やcleanupで必要なファイルを消していたら、その変更を戻せるようにします。完了記録には、原因の領域、増加step、peakの観測、保持・削除の責任、未確認のrunner条件を残します。成功した一回だけで、すべての将来runの容量を保証しません。