You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cirrus has a hard limit of 1 hour for tests to complete - we can bump that as high as 90 minutes, but have resisted doing so (because we should really shard rather than doing that). I'm not sure what the exact timeout is for LUCI, but it's longer - I've seen tests run for at least a couple hours before finally being killed by the agent when things go bad. On the devicelab it's 15 minutes - I don't know if you're proposing removing that as well though.
I'm concerned that this change will have a few undesired consequences on CI infra:
Tests that are broken or flaky will still fail to complete, but they'll just exhaust the entirety of the remaining duration on CI.
CI machines will be less available for running new commits. This is particularly troubling on LUCI and the devicelab, where we're constrained to a few machines available for all testing.
These problems (1 and 2) will compound as we shard things out. Tests should get shorter over all, but badly behaving tests (or environments) could end up getting booked for hours without the tester killing them.
That's better, but it would still mean that one misbehaving test could tie up a machine for 30 minutes instead of the current limit of something like 5.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
dnfield commentedon Jun 5, 2019
Cirrus has a hard limit of 1 hour for tests to complete - we can bump that as high as 90 minutes, but have resisted doing so (because we should really shard rather than doing that). I'm not sure what the exact timeout is for LUCI, but it's longer - I've seen tests run for at least a couple hours before finally being killed by the agent when things go bad. On the devicelab it's 15 minutes - I don't know if you're proposing removing that as well though.
I'm concerned that this change will have a few undesired consequences on CI infra:
dnfield commentedon Jun 5, 2019
It's entirely possible that these concerns are based on a misunderstanding of the role of
initialTimeout.Hixie commentedon Jun 6, 2019
That's fair. Maybe we should set the
package:testtimeout to 30 minutes or some such?dnfield commentedon Jun 6, 2019
That's better, but it would still mean that one misbehaving test could tie up a machine for 30 minutes instead of the current limit of something like 5.
Hixie commentedon Jun 7, 2019
The current limit is 2 minutes.
How do we know if 2 minutes (or 30 minutes) is enough to avoid flakes?
Hixie commentedon Jun 7, 2019
I guess my problem is I have no idea how to pick the timeout to avoid the race condition.
github-actions commentedon Aug 29, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.