CI: increase timeout from 4h to 6h

[Kobzol]

Our CI got a bit slower since the last time we lowered the timeout, and if e.g. Docker build cache is broken, the timeout can be triggered.

Discussed here.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ehuss]

Is there a particular reason to have a timeout longer than the bors timeout?

[Kobzol]

(For context: the homu timeout is configured here.)

Normally, I would say "no", but I wonder if the homu timeout even works. I vaguely remember that I lowered the timeout because we had some 6 or even 8 hour jobs due to some issue with slow tests on CI. But the homu timeout was 4.25 hours for the last four years, according to git, so it seems unlikely that we'd hit these durations if the homu timeout has worked. But maybe I remember it wrong.

[ehuss]

I think it is working. Here is a recent example: #131397 (comment)

It may not show up very often now because homu's timeout is 4.25 hours, but the Actions timeout is set to 4.

[Kobzol]

I see, thanks for the example. What is interesting there is that an individual job timed out after 4 hours, but the job took ~15 minutes to start, so the whole workflow was actually timed out by homu sooner than that. However, it does not seem like homu actually cancelled that workflow! It posted the "timed out" comment at 10:27, but the workflow finished normally (with a failure) at 10:28. So it looks like homu does not in fact cancel timed out workflows? (new bors does this).

If that is the case, then we should perhaps also increase the homu timeout (but any homu change and redeploy is quite scary, the last one was 9 months ago 🥶) and configure the GHA timeout to be similar-ish to the homu timeout.

[ehuss]

Yea, I was going to say I don't think homu actually cancels the workflow right away. However, I think that maybe when it force-pushes a new commit to the branch (when it moves to the next PR), GitHub will cancel it? I don't remember. It may also depend on cancel-in-progress. I do recall cancellation was a little strange.

[Kobzol]

It does not cancel it, because we explicitly allow parallel try builds, even on the same PR (https://github.com/rust-lang/rust/blob/master/.github/workflows/ci.yml#L37).

[Kobzol]

Also, this is relevant (again, I remembered this now...): https://docs.github.com/en/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits The maximum job runtime is actually 6 hours.

[workingjubilee]

#132919 (comment) time explosion

[Mark-Simulacrum]

@bors r+

Seems OK - and easily reversible. In general 4 vs 6 hours doesn't seem particularly meaningful.

[bors]

📌 Commit b910e97 has been approved by Mark-Simulacrum

It is now in the queue for this repository.