-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Added custom timeout to ci #7641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
it sounds good to me. |
The CI failures seem unrelated to the changes, they are in a different yaml file that the one I changed. Is this something intermittent? |
I guess so I saw similar intermittent problems before. |
Seems related to #7433 somehow |
Indeed, it's the same library but not the same error. Should I try commenting out the changes to see if it still fails? |
That might be helpful as a sanity check. |
I saw another PR with the same |
We're up to 8 reruns now, and the failure persists... Elsewhere the CI runs fine. |
Hi @chrchr-github, just did this, let's see what happens. I think you need to approve the workflows to run. |
Change Summary
Added custom timeout for
build_mingw
job of theCI-mingw
workflow based on historical data.More details
Over the last 7456 successful runs, the
build_mingw
job has a maximum runtime of 13 minutes (mean=4, std=2).However, there are failed runs that fail after reaching the threshold of 6 hours that GitHub imposes. In other words, these jobs seem to get stuck, possibly for external or random reasons.
One such example is this job run, that failed after 6 hours. More stuck jobs have been observed over the last six months, the first one on 2025-01-01 and the last one one on 2025-04-09, while more recent occurences are also possible because our dataset has a cutoff date around late May. With the proposed changes, a total of 45 hours would have been saved over the last six months retrospectively, clearing the queue for other workflows and speeding up the CI of the project, while also saving resources in general.
The idea is to set a timeout to stop jobs that run much longer than their historical maximum, because such jobs are probably stuck and will simply fail with a timeout at 6 hours.
Our PR proposes to set the timeout to
max + 3*std = 19 minutes
wheremax
andstd
(standard deviation) are derived from the history of 7456 successful runs. This will provide sufficient margin if the workflow gets naturally slower in the future, but if you would prefer lower/higher threshold we would be happy to do it.Context
Hi,
We are a team of researchers from University of Zurich and we are currently working on energy optimizations in GitHub Actions workflows.
Thanks for your time on this.
Feel free to let us know (here or in the email below) if you have any questions, and thanks for putting in the time to read this.
Best regards,
Konstantinos Kitsios
[email protected]