Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[feature] Granular timeout management

Đang mở
  • Có gì không ổn?
#11 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, python
Lĩnh vực
ci-cd, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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) }}
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
6
Fork
2
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tox-dev/workflow

Tất cả issue của tox-dev/workflow

Issue tương tự

Thêm issue về DevOps

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.