GitHub Community
try to fix task cancled cause 360 min time limitThe log show task have run 600 minutes, but actually it only run 360 minute
|
Replies: 6 comments 1 reply
Build software better, togetherGitHub is where people build software. More than 65 million people use GitHub to discover, fork, and contribute to over 200 million projects.
|
|
Isn’t it the second job?
Anyway, 6 * 60 minutes = 360 minutes. That is the actual limit for a job as per the documentation:
https://docs.github.com/en/actions/reference/usage-limits-billing-and-administration#usage-limits The error message
might simply be outdated, not reflecting the actual limit. |
|
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes The limit can be changed by config, I have change it to 600, that is why the log show the limit is 600 |
|
It doesn’t say anything about the hard maximum in the documentation you linked to. Is there any source for it being 600 minutes? Does it only apply to self-hosted runners perhaps? |
|
Yes, you can change the limit. For GitHub hosted runners, the default value corresponds to the maximum value. You can thus only lower the limit, which you’d do to prevent a runaway job from burning through your free or paid minutes. For self-hosted runners (which you aren’t using), you can set it to a higher (or lower) value. But you aren’t using them, so this is irrelevant to you. Filed: jobs.<job_id>.timeout-minutes description is misleading### What article on docs.github.com is affected? https://docs.github.com/en…/actions/reference/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes What part(s) of the article would you like to see updated?> jobs.<job_id>.timeout-minutes Additional informationThe text isn't technically wrong, but it's misleading. Yes, if you use a self-hosted runner, you can set a value that's larger than 360, but if you are using GitHub hosted runners, then this limit is actually a hard limit: https://docs.github.com/en/actions/reference/usage-limits-billing-and-administration#usage-limits 6*60 = 360 Problems:
I believe that the confusion you’re experiencing is a likely outcome of the current documentation. |
|
Is 600 minutes the hard limit for self-hosted runners? I wonder if higher values might get ignored and the default used instead. There’s another topic where someone says that 360 would be the maximum for self-hosted runners, which may or may not be a bug: In my CI/CD setup, one step is to retrain a deep learning model. We setup our own GPU-box as a self-hosted runner to run this step. However, the training takes about one day, which is much longer than the current 6-hours cap GitHub Actions allowed. Is there any way to workaround this limitation? |
|
based on my experience these couple days, higher value (>6 hrs) will be ignored |
Yes, you can change the limit. For GitHub hosted runners, the default value corresponds to the maximum value. You can thus only lower the limit, which you’d do to prevent a runaway job from burning through your free or paid minutes.
For self-hosted runners (which you aren’t using), you can set it to a higher (or lower) value. But you aren’t using them, so this is irrelevant to you.
Filed:
jobs.<job_id>.timeout-minutes description is misleading