GitHub Actions タイムアウト問題の修正 (開発日記 No.128)
関連リンク
はじめに
昨日はGitHub Actionsのジョブがタイムアウトでキャンセルされる問題に取り組みました。今日は、この問題を解決するために行った設定変更と、その検証プロセスについて詳しく記録します。
背景と目的
GitHub Actionsのジョブが最大実行時間（6時間）を超過してキャンセルされるというエラーが発生していました。特に、openhands_resolver.yml パイプラインでこの問題が頻発していました。このタイムアウトの原因を特定し、ジョブが正常に完了するように設定を調整することが今回の目的です。
検討内容
当初、openhands_resolver.yml 内の LLM_NUM_RETRIES（リトライ回数）と LLM_RETRY_MAX_WAIT（リトライ間隔の最大待ち時間）が大きな値に設定されていました。これらの値が大きすぎると、ジョブが長時間実行され、タイムアウトに至る可能性があると考えました。
そこで、以下の値を変更することにしました。
-
LLM_NUM_RETRIES:1000から10へ削減 -
LLM_RETRY_MAX_WAIT:3000から300へ削減
これらの変更により、リトライ処理にかかる時間を短縮し、タイムアウトを回避できると期待しました。
実装内容
まず、対象のパイプラインファイルである .github/workflows/openhands_resolver.yml を修正しました。
# .github/workflows/openhands_resolver.yml (抜粋)
env:
LLM_NUM_RETRIES: 10
LLM_RETRY_MAX_WAIT: 300
この変更をGitHubにプッシュし、CIパイプラインが実行されることを確認しました。しかし、直接 main ブランチにプッシュしたため、openhands_resolver.yml のトリガー条件（issues: types: [labeled] など）に合致せず、期待したワークフローが実行されませんでした。
そこで、Issue #14 にラベルを追加してワークフローをトリガーすることを試みました。まず、openhands-trigger というラベルを作成し、Issue #14 に追加しました。
# ラベル作成 (ターミナル)
gh label create openhands-trigger --description "Trigger OpenHands Resolver Workflow" --color FFFFFF
しかし、ワークフローは実行されたものの、auto-fix ジョブが「スキップ済み」として完了しました。これは、再利用可能なワークフロー内部の条件によってジョブがスキップされたためと考えられますが、詳細なコードを確認することはできませんでした。
Issue #14 から openhands-trigger ラベルを削除し、再度追加することで、ワークフローを再トリガーを試みました。しかし、結果は変わらず、auto-fix ジョブは「スキップ済み」のままでした。
技術的なポイント
今回の変更の技術的なポイントは、GitHub Actionsの環境変数とトリガー条件の理解です。LLM_NUM_RETRIES と LLM_RETRY_MAX_WAIT の値を調整することで、リトライ処理の挙動を制御し、タイムアウトを防ぐことを目指しました。
また、ワークフローのトリガー条件を理解し、意図したワークフローを実行させるために、ラベルの追加・削除を試行錯誤しました。
所感
今回の開発では、GitHub Actionsのワークフローが期待通りに動作しない場合に、原因を特定し、解決策を試すことの難しさを改めて感じました。特に、再利用可能なワークフローの内部ロジックがブラックボックスである場合、外部からのトリガー方法やパラメータ調整だけでは、期待する結果を得られないことがあります。
ジョブがスキップされてしまったため、今回の変更が実際にタイムアウト問題を解決したかどうかを検証できませんでしたが、設定変更自体は意図通りに適用されています。
今後の課題
今回の変更がタイムアウト問題を解決したかどうかを検証するために、ジョブがスキップされないようなトリガー条件を見つける必要があります。また、再利用可能なワークフローの内部ロジックを理解するための情報収集も重要です。
まとめ
今回は、GitHub Actionsのタイムアウト問題を解決するために、LLM_NUM_RETRIES と LLM_RETRY_MAX_WAIT の値を調整しました。ワークフローのトリガーに苦労しましたが、設定変更自体は完了しました。今後は、この変更が実際に問題を解決したかどうかを検証し、必要に応じてさらなる改善を行います。
Discussion