I want to set the timeout for GitHub actions at the organization level so that it gets applied to all GitHub Actions in All Repos in the organization. Is this possible? If yes, how and where is this setting?
I don’t believe you can do that at this time. I would argue that you would not want to do this, as different workflows with different actions could have longer time requirements.
Thank you for your response. However, it is certainly a requirement, since these minutes get counted for billing. What I want is a Max limit (like 6 hrs default), which should be configurable at org level to say 30 minutes max. Also, if there is an incident affecting GitHub Actions (which happens very frequently), then some workflows get stuck forever and billing minutes get added unnecessarily. Please correct me if I am wrong.
Hey! You are correct in that using hosted runners you do pay via minutes, so yes, I can understand you concern and reason for wanting to restrict that. I just wanted to mention there may be scenarios where that could impact you as well. I’m gonna go ask a couple of questions about this. be back.
@mickeygousset What about the best of both worlds?
- ability to change the default timeout at the org level from 6 hours to something shorter
- for jobs expected to run longer, opt-in to a longer timeout via the already existing
To put it another way, we want to “opt in” to very long runtimes in the very few cases we need them, rather than every team needing to remember to “opt out” of them.
Dude what a great idea with the timeout-minutes! I didn’t realize that option was there. While there isn’t any way to set the timeout for the entire workflow file yet (but I’ll put it in as a request), you could use the job/step timeout to emulate the same thing.
@mickeygousset it will be a perpetual cat-and-mouse game if we need to put
timeout-minutes in every single step (or even if it’s implemented at the workflow level), as eventually someone will forget to add it and we’ll wind up with the 6 hour default, leading to billing overages if a job hangs.
What we need is the ability to change the default 6 hour timeout at the org level to something that makes sense for 99% of our use cases, and then if we need to override it to something larger, we can use timeout-minutes for that on a case-by-case basis.
Thanks for your help!