GitHub Actionsがタイムアウトした時の原因と確認手順

タイムアウトとは何が起きた状態？

GitHub Actionsにはジョブ全体の実行時間を制限するtimeout-minutesがあり、利用するアクション側にも接続や転送の時間制限がある場合があります。どちらが先に止めたかで対処が変わります。

SaGaSでも自動公開が25分付近まで進んで止まった事例をきっかけに、時間を延ばす前にログと転送範囲を確認する手順を整理しました。

最初にログのどこを見る？

失敗した実行を開き、赤くなったジョブとステップを確認します。最後に表示された処理、そこから停止までの時間、警告や再試行の有無を保存します。

チェックアウト、ビルド、検査、FTPS転送のどこで止まったかを分けます。「Actionsが遅い」ではなく「FTPS接続後にファイル一覧取得で止まった」のように場所を特定します。

FTP・FTPS転送で時間がかかる主な原因

初回公開や状態ファイルを使わない設定では、変更していないファイルまで毎回確認・転送することがあります。画像やビルド生成物が多いと、ファイル数が少し増えただけでも通信回数が大きく増えます。

接続の再試行、FTPSの暗号化通信、サーバー側の同時接続制限、応答の遅さも候補です。ログが同じ場所で長く止まるのか、少しずつ進むのかを見ます。

• 公開対象フォルダに不要な生成物が入っていないか
• 大きな画像や重複ファイルが増えていないか
• 毎回全件転送になっていないか
• サーバーの接続数・転送制限に達していないか
• FTPSの接続先・ポート・暗号化方式が正しいか

公開範囲を小さくするには？

会社サイト全体ではなく、更新するフォルダだけをリポジトリと公開対象にします。キャッシュ、ログ、ローカル設定、元画像など公開不要なファイルを除外します。

大きな画像は表示サイズに合わせて圧縮し、同じファイルを複数場所へ置かないよう整理します。差分転送を使う場合は、状態ファイルを消さない運用も確認します。

timeout設定はいつ変える？

通常の転送時間が分かり、処理は正常に進んでいるのに少しだけ上限を超える場合に調整します。ジョブ全体のtimeout-minutesと、転送アクションが持つtimeoutは別の設定です。

極端に長くすると、接続不能や無限待ちに気づくのが遅れます。普段の所要時間に余裕を足し、異常時には止まる値を選びます。

再実行する前に何を変える？

何も変えず一度だけ再実行し、一時的な通信問題かを比べることはできます。繰り返し失敗する場合は、公開対象、画像、接続先、サーバー状態のうち一つずつ変更します。

複数項目を同時に変えると、何が効いたか分からなくなります。実行番号、コミット、所要時間、最後のログを記録し、成功時も通常時間を残します。

秘密情報の扱いで注意すること

FTPユーザー名やパスワードをワークフローファイルへ直接書かず、GitHub ActionsのSecretsへ保存します。ログへ秘密情報を表示する確認コマンドも入れません。

調査のために接続情報を変更した場合は、不要な一時アカウントを削除し、権限を公開フォルダへ限定します。