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
{{ message }}
Repository navigation
Linux_android hot_mode_dev_cycle_linux__benchmark runs in presubmit, only one bot available in try pool #145242
@yusuf-goog this is correct. I went and checked the other pools and there are 13 of these bots in postsubmit. Do you recall if there was a reason for this imbalance between the pools?
The understanding was this bot was for testing out changes in the try pool and was not meant to be a blocker to presubmit changes. I'm going to move the bot to prod and change the target to prod as well.
If you still want to run benchmarks that are non-blocking to the tree (since we do not have the required minimum capacity in try) we would need to move this testsetup back in.
I see that there's one Linux/MotoG4 set up in staging on flutter-devicelab-linux-14, so if one of the prod Linux/MotoG4 tests becomes flaky we will be okay there. There aren't currently enough devicelab bots of any configuration in the try pool to run in presubmit reliably on every PR, so moving this test off of presubmit (that is, out of the try pool) makes sense to me. After the devicelab moves and the new low-end device is hooked up, let's revisit whether we can get enough devicelab bots of some configuration to run in presub.
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
ricardoamador commentedon Mar 18, 2024
@yusuf-goog this is correct. I went and checked the other pools and there are 13 of these bots in postsubmit. Do you recall if there was a reason for this imbalance between the pools?
ricardoamador commentedon Mar 18, 2024
The understanding was this bot was for testing out changes in the try pool and was not meant to be a blocker to presubmit changes. I'm going to move the bot to prod and change the target to prod as well.
Switch target to prod: #145343
Switch bot to prod: https://chrome-internal-review.googlesource.com/c/infradata/config/+/7078725
Switch hot_mode_dev_cycle_linux__benchmark to run in postsubmit (#145343
jmagman commentedon Mar 18, 2024
Note this will likely need to be moved back if
hot_mode_dev_cycle_linux__benchmarkis ever marked flaky, and run in the staging pool.ricardoamador commentedon Mar 18, 2024
@jmagman the flaky bot will take care of this if the test ever becomes flaky. 👍🏼
yusuf-goog commentedon Mar 19, 2024
FYI @zanderso . The one linux-moto G4 in
tryhas been moved out: https://chrome-internal-review.googlesource.com/c/infradata/config/+/7078725If you still want to run benchmarks that are non-blocking to the tree (since we do not have the required minimum capacity in
try) we would need to move this testsetup back in.zanderso commentedon Mar 20, 2024
I see that there's one Linux/MotoG4 set up in staging on flutter-devicelab-linux-14, so if one of the prod Linux/MotoG4 tests becomes flaky we will be okay there. There aren't currently enough devicelab bots of any configuration in the try pool to run in presubmit reliably on every PR, so moving this test off of presubmit (that is, out of the try pool) makes sense to me. After the devicelab moves and the new low-end device is hooked up, let's revisit whether we can get enough devicelab bots of some configuration to run in presub.
ricardoamador commentedon Mar 20, 2024
@zanderso thanks for clarifying Zach, I will open a tracking issue for this so we can make sure to circle back.
ricardoamador commentedon Mar 20, 2024
Created #145480 for tracking purposes.
Switch hot_mode_dev_cycle_linux__benchmark to run in postsubmit (flut…
github-actions commentedon Apr 3, 2024
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.