[feature] Granular timeout management
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
Start by reviewing the GitHub Actions job steps and the linked debug-timeout-minutes-steps-gha-test experiment. Compare tox's --exit-and-dump-after and possible --fail-fast behavior with step-level timeout-minutes, along with the mentioned pytest, ansible-test, CPython, and faulthandler options. Done means proposing a clear timeout interface and identifying how callers can override defaults.
索引モデルが issue の本文から書いたものです。
説明
The current timeout strategy is bound to the overall job duration, which is problematic in cases when we can know early that it is doomed to fail but still proceed with running it.
For example, when a job is cancelled because another matrix job fails, it goes into the rerun mode which buys it 5 minutes of overtime (due to how GH handles cancellations).
Another example is when third party dependencies like PPA are flaky or down. The test dep installation can make the overall job duration longer, thus increasing a chance of hitting the timeout and having the GHA platform killing the job close to its completion. Even if it would've succeeded otherwise.
So we likely need to integrate tox's --exit-and-dump-after (and possibly --fail-fast). And maybe encourage the use of similar features in pytest. ansible-test and CPython's test runners also have features of controlled timeouts. Plus there's faulthandler that can dump current traces, worth mentioning.
Back to GHA's timeouts. I think, we should explore step-level timeouts. We would be able to catch certain parts of jobs getting out of line more predictably, but it's unclear what the interface could be for the callers to override the defaults.
I've tested in https://github.com/webknjaz/debug-timeout-minutes-steps-gha-test/actions/runs/37228799583/job/111513907748 that it's possible to set timeout-minutes for steps dynamically, computed earlier in the job as follows:
jobs:
build:
runs-on: ubuntu-24.04-arm
steps:
- name: Compute step timeouts
id: timer-values
run: |-
echo val1=1 >> "${GITHUB_OUTPUT}"
echo val2=2 >> "${GITHUB_OUTPUT}"
- name: SHOULD stop after a minute
if: always()
run: sleep 300
timeout-minutes: ${{ fromJSON(steps.timer-values.outputs.val1) }}
- name: SHOULD stop after two minutes
if: always()
run: sleep 300
timeout-minutes: ${{ fromJSON(steps.timer-values.outputs.val2) }}
- 主要言語
- 言語のデータがありません
- スター
- 6
- フォーク
- 2
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
tox-dev/workflow のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
enhancement help wanted question
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
tox-dev/workflow の issue をすべて見る
似ている issue
-
Sanity on ansible-core devel fails: ignore-2.23.txt references the removed import-3.9 test対応中かも @yurnov が今日担当しました。 オープンneeds_triage
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
ansible-collections/kubernetes.core#1275 ·
メンテナーはふだん 1 日以内に返信
-
bug milestone-qa
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
lognorman20/monaco#3995 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
gnosis/gnosis_vpn#540 ·
メンテナーはふだん 1 日以内に返信
-
e2e-failure ready-to-code
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
redhat-developer/rhdh-plugin-export-overlays#4261 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信