Support for organization-level default timeout setting for GitHub Actions

[noritada]

When using GitHub Actions, it would be nice if we can set timeouts at the organization level to prevent someone in the organization from accidentally setting up a workflow that runs for a long time.

Currently, if I understand correctly, there is no setting that imposes an upper limit on execution time at the organization level. Also, the default timeout configuration of 360 minutes should apply if not explicitly stated in the settings within each workflow. However, if we accidentally run a job heavy enough to use this timeout time (especially if we run it on a macOS runner), the impact on the total runtime of the organization is quite significant. My suggestion is to reduce this risk.

As long as we are using GitHub Actions with one user account, you should be able to manage all workflows, so there is little risk. However, in an organization, different people will share the total free execution time of the GitHub Actions workflows, so it is preferable if there is a way to reduce the risk. We would appreciate your consideration.

[jay-w-opus]

When running an organization, a rookie engineer may implement an workflow job that usually takes 10 minutes but one day, some bad change make it stuck for 6 hours. This feature is needed by an org admin.

[froblesmartin]

Even though it is not a solution, and just a (maybe) workaround to cover part of the functionality of having a default GitHub Actions timeout time, what I did so far is create a variable at the organization level, and then refer to it in all the jobs. At least in this way I can have a default global timeout, and then if I want to do exceptions per project or repository, you can create further variables at the organization or repository level.

One point happening at least as of now, is that variables are returned as String, and the timeout configuration expects a number. The workaround for that, as even documented by GitHub at https://docs.github.com/en/actions/learn-github-actions/expressions#example-returning-a-json-data-type, is to use the function fromJSON()

So I ended up with:

timeout-minutes: ${{ fromJSON(vars.DEFAULT_JOB_TIMEOUT) }}

[peetjvv]

Love the suggestion. Little annoying to have to remember to add the timeout in all jobs though. But still a good workaround until the feature gets added to GitHub Actions someday.

[froblesmartin]

Yep, the main problem, is not being able to ensure that any new pipeline gets limited by it, but still better than nothing 😅

[mvz]

I was unpleasantly surprised by one job running 6h on a dependabot PR during the weekend because the initial Ruby install didn't finish. Normal job run is under 10 minutes. So this can be a problem even if no changes are made to the action.

[yashshanker]

a workflow in my org was just discovered to have been running for last 4 months.
wasn't even able to cancel the run, had to delete the run itself.

[Cypher1]

Just had two jobs run for over an hour each. Fortunately I was paying attention, but really how is there no default timeout? (Let alone the default settings requested here which makes a bunch of sense).

[m1chu-alle]

I will be very grateful for introducing such functionality. From the perspective of an administrator of a very large organization (thousands of repositories), it would be extremely useful.

[marco-carvalho]

this is a very needed functionality

[luisortiz-unsw-admin]

It will be great to have a functionality like this.

[acrandal]

I use GitHub classroom for a DevOps class. We have students making their own workflows for projects, including their own yaml configs. I ask them to put limits on each job, but all it takes is one to forget and get something stuck forever. A global limit would be a huge upgrade for our class to not burn massive $$$ when students just start running a workflow over and over when each one is stuck so we're then burning massive minutes for no reason.

[AnkeshThakur]

Recently I ran into the same problem of workflow getting stuck for a very long time. Ultimately, I had to use force-cancel api to cancel it. No other options worked for me. A global timeout at repository level should be good fail-safe to have.

API that I used: https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run

[bsloan-icl]

This would be a great idea. We've had many instances where users have been using MacOs runners not realising they're billed at 10x the number of minutes as Ubuntu. All it takes is a few of these MacOs jobs to timeout after 360 minutes and the costs can easily add up.

Being able to set this at the organisation/enterprise level would help us better control compute costs.

[daniddelrio]

+1 on this. There's also a similar discussion here (but on the workflow level): https://github.com/orgs/community/discussions/10690