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
|
Beta Was this translation helpful? Give feedback.
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
based on my experience these couple days, higher value (>6 hrs) will be ignored |
Beta Was this translation helpful? Give feedback.
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