この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
ActionsのWorkflow内でバッチ経由でのCloudFormationによるスタック更新を行っていた時、動作時間が50分を超えたステップの存在に気が付きました。
念の為にとCloudFormationを管理コンソールから見てみるとERRORで止まっている状態を発見。Workflow側には反映されなかったようです。
定期的に管理コンソールを見つつ状況に応じてWorkflowを止める必要があるのかと思いきや、timeout-minutesの設定が存在しました。動作枠浪費を防ぐためには必須なこの設定について書いてみました。
timeout-minutesについて
Actions側で更新が発生しなかった場合の動作が打ち切られる時間上限で、JobとStepそれぞれで設定可能です。未設定時にWorkflowで実施したコマンド内部でエラーを起こした場合に出力更新をしなければ、Workflowは最大6時間(360 min)何もせずただ動き続けます。
The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360
Workflow syntax for GitHub Actions - GitHub Help
実際の設定
標準機能であるため、Actionsの追加は不要です。
jobs:
my-job:
runs-on: ubuntu-latest
timeout-minutes: 30 # job全体
steps:
- run: sleep 300
timeout-minutes: 20 # step個別Step数が多い場合、job全体で「Step全体を通して、この時間までには完了させたい」という数値を設定するという手があります。
プラン毎の利用可能枠に対する標準タイムアウト可能回数と枠補充時の費用
利用可能時間は以下の通りです。Proプランであっても360分の標準設定のみでは約10回の見逃しで枯渇する計算になります。複数のWorkflowが動いていた場合には1日で尽きる可能性もありますね。
| プラン | 初期利用可能時間 | timeout標準可能回数 |
|---|---|---|
| Free | 2000分 | 5回 |
| Pro | 3000分 | 8回 |
| Team | 10000分 | 27回 |
| Enterprise | 50000分 | 138回 |
360分枠の追加購入にかかるコストは、
- Linux $2.28 (=$0.008 x 360)
- Windows $5.76 (=$0.016 x 360)
- macOS $28.8 (=$0.08 x 360)
となっており、特にmacOS環境の場合は大きくなるため要注意です。尚セルフホスト時にはコストが掛かりません。
注意事項
- timeout-minutesの設定は通知を兼ねていません。あくまでも中断されるだけです。
- timeoutではなく明示的に中断させたい場合は、実行させている処理からエラーを明確に返しましょう。
あとがき
標準に含まれている設定ですが、設定されているサンプルが少ないためかフォーラムで質問が発生しやすい項目となっています。
continuous integration - Set default Timeout on Github action pipeline - Stack Overflow
少し気をつけるだけで利用時間浪費を防止できるため、忘れずに設定しておきましょう。
3
