Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2045043002:
Allow multiple devices on bisects hosts (Closed)
|
Created:
4 years, 6 months ago by Ziqi Xiong Modified:
4 years, 4 months ago CC:
chromium-reviews, infra-reviews+build_chromium.org, kjellander-cc_chromium.org Base URL:
https://chromium.googlesource.com/chromium/tools/build.git@master Target Ref:
refs/heads/master Project:
build Visibility:
Public. |
DescriptionAllow multiple devices on bisects hosts
Right now, when an android device connected to a bisect linux host goes offline,
we still send bisects to that host, and the bisects fail.
So the device needs to be fixed with extremely urgent priority.
This CL aims to allow multiple devices to be connected to a linux host and if a device failed,
the job would be retried with a device that is still working.
Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f47c8d806ffe988c46415
Patch Set 1 #
Total comments: 5
Patch Set 2 : Keep track of devices already tested to avoid retrying failed devices #
Total comments: 2
Patch Set 3 : Move device_to_test and devices_tested variables to auto_bisect api #
Total comments: 6
Patch Set 4 : Move device_to_test and devices_tested to bisect_tester #Patch Set 5 : rebase against master #Patch Set 6 : solve coverage problem #
Total comments: 2
Patch Set 7 : Fix command error #Patch Set 8 : rebase against master #Patch Set 9 : rebase again #Patch Set 10 : Retrain simulation test #
Total comments: 1
Patch Set 11 : Remove unnecessary changes #Patch Set 12 : Update unexpected files #
Total comments: 4
Messages
Total messages: 48 (24 generated)
robertocn@chromium.org changed reviewers: + robertocn@chromium.org
I think the approach is headed in the right direction. Please edit this issue's description to match the convention. Note that this description becomes the commit message once the changelist lands. I suggest running `git log` on this directory for examples of how to structure a commit message. https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except api.m.step.StepFailure: Eventually we'd want to make this more specific that just StepFailure. We need to determine if the failure was due to a device going offline. I think as a first attempt, this should work anyway. https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:36: serial_number = available_devices[0] Since we do not know for a fact that the StepFailure was due to a device going offline, we might need to check that we are not retrying with the same devices over and over again. Maybe we could keep a running list of devices already tested and stop when all those have been tried? https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... File scripts/slave/recipe_modules/bisect_tester/perf_test.py (right): https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... scripts/slave/recipe_modules/bisect_tester/perf_test.py:98: command += '--device ' + device_serial_number I think this flag can only be appended to telemetry commands, might be worth it to check for it (use the _is_telemetry boolean from line 92)
Description was changed from ========== Attempt at project 2: redo test after step failure if multiple android devices are connected to linux host Redo test after failure if another device is connected BUG= ========== to ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ==========
Description was changed from ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ========== to ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ==========
Description was changed from ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ========== to ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ==========
Description was changed from ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ========== to ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ==========
https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/chromium_android/api.py (right): https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/chromium_android/api.py:25: self.device_to_test = None Maybe these belong on the auto_bisect api. (since chromium_android is not test-specific)
This looks better, how about expectation changes? https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/auto_bisect/api.py (right): https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/auto_bisect/api.py:49: self.device_tested = [] Nit: devices_tested https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/auto_bisect/api.py:336: env=self.m.chromium.get_env()) Thanks for fixing this. https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/chromium_android/api.py (right): https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/chromium_android/api.py:1009: "name": "testA", if the only changes in this file are whitespace fixes, then we shouldn't have this file in this CL.
I moved devices_tested and device_to_test to bisect_tester module to avoid circular dependency. I ran the simulation test and no new expectation files were generated. https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except api.m.step.StepFailure: On 2016/06/07 22:00:39, RobertoCN wrote: > Eventually we'd want to make this more specific that just StepFailure. We need > to determine if the failure was due to a device going offline. > I think as a first attempt, this should work anyway. Done. https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:36: serial_number = available_devices[0] On 2016/06/07 22:00:39, RobertoCN wrote: > Since we do not know for a fact that the StepFailure was due to a device going > offline, we might need to check that we are not retrying with the same devices > over and over again. Maybe we could keep a running list of devices already > tested and stop when all those have been tried? Done. https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/chromium_android/api.py (right): https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/chromium_android/api.py:25: self.device_to_test = None On 2016/06/10 15:50:17, RobertoCN wrote: > Maybe these belong on the auto_bisect api. (since chromium_android is not > test-specific) Done. https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/auto_bisect/api.py (right): https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/auto_bisect/api.py:49: self.device_tested = [] On 2016/06/21 22:47:01, RobertoCN wrote: > Nit: devices_tested Done. https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/auto_bisect/api.py:336: env=self.m.chromium.get_env()) On 2016/06/21 22:47:01, RobertoCN wrote: > Thanks for fixing this. Done. https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... File scripts/slave/recipe_modules/chromium_android/api.py (right): https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... scripts/slave/recipe_modules/chromium_android/api.py:1009: "name": "testA", On 2016/06/21 22:47:01, RobertoCN wrote: > if the only changes in this file are whitespace fixes, then we shouldn't have > this file in this CL. Done.
On 2016/06/22 17:38:22, Ziqi Xiong wrote: > I moved devices_tested and device_to_test to bisect_tester module to avoid > circular dependency. I ran the simulation test and no new expectation files were > generated. > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except > api.m.step.StepFailure: > On 2016/06/07 22:00:39, RobertoCN wrote: > > Eventually we'd want to make this more specific that just StepFailure. We need > > to determine if the failure was due to a device going offline. > > I think as a first attempt, this should work anyway. > > Done. > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > scripts/slave/recipe_modules/auto_bisect/local_bisect.py:36: serial_number = > available_devices[0] > On 2016/06/07 22:00:39, RobertoCN wrote: > > Since we do not know for a fact that the StepFailure was due to a device going > > offline, we might need to check that we are not retrying with the same devices > > over and over again. Maybe we could keep a running list of devices already > > tested and stop when all those have been tried? > > Done. > > https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... > File scripts/slave/recipe_modules/chromium_android/api.py (right): > > https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... > scripts/slave/recipe_modules/chromium_android/api.py:25: self.device_to_test = > None > On 2016/06/10 15:50:17, RobertoCN wrote: > > Maybe these belong on the auto_bisect api. (since chromium_android is not > > test-specific) > > Done. > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > File scripts/slave/recipe_modules/auto_bisect/api.py (right): > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > scripts/slave/recipe_modules/auto_bisect/api.py:49: self.device_tested = [] > On 2016/06/21 22:47:01, RobertoCN wrote: > > Nit: devices_tested > > Done. > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > scripts/slave/recipe_modules/auto_bisect/api.py:336: > env=self.m.chromium.get_env()) > On 2016/06/21 22:47:01, RobertoCN wrote: > > Thanks for fixing this. > > Done. > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > File scripts/slave/recipe_modules/chromium_android/api.py (right): > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > scripts/slave/recipe_modules/chromium_android/api.py:1009: "name": "testA", > On 2016/06/21 22:47:01, RobertoCN wrote: > > if the only changes in this file are whitespace fixes, then we shouldn't have > > this file in this CL. > > Done. Dry run failed because you are missing coverage of one line. Easiest thing to do at this point is run recipe simulation test, look at the output of missing coverage and locate the line that is not covered (bisect_tester/perf_test it seems) and append ` # pragma: no cover` to that line.
On 2016/06/22 18:46:04, RobertoCN wrote: > On 2016/06/22 17:38:22, Ziqi Xiong wrote: > > I moved devices_tested and device_to_test to bisect_tester module to avoid > > circular dependency. I ran the simulation test and no new expectation files > were > > generated. > > > > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > > File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): > > > > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > > scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except > > api.m.step.StepFailure: > > On 2016/06/07 22:00:39, RobertoCN wrote: > > > Eventually we'd want to make this more specific that just StepFailure. We > need > > > to determine if the failure was due to a device going offline. > > > I think as a first attempt, this should work anyway. > > > > Done. > > > > > https://codereview.chromium.org/2045043002/diff/1/scripts/slave/recipe_module... > > scripts/slave/recipe_modules/auto_bisect/local_bisect.py:36: serial_number = > > available_devices[0] > > On 2016/06/07 22:00:39, RobertoCN wrote: > > > Since we do not know for a fact that the StepFailure was due to a device > going > > > offline, we might need to check that we are not retrying with the same > devices > > > over and over again. Maybe we could keep a running list of devices already > > > tested and stop when all those have been tried? > > > > Done. > > > > > https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... > > File scripts/slave/recipe_modules/chromium_android/api.py (right): > > > > > https://codereview.chromium.org/2045043002/diff/20001/scripts/slave/recipe_mo... > > scripts/slave/recipe_modules/chromium_android/api.py:25: self.device_to_test = > > None > > On 2016/06/10 15:50:17, RobertoCN wrote: > > > Maybe these belong on the auto_bisect api. (since chromium_android is not > > > test-specific) > > > > Done. > > > > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > > File scripts/slave/recipe_modules/auto_bisect/api.py (right): > > > > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > > scripts/slave/recipe_modules/auto_bisect/api.py:49: self.device_tested = [] > > On 2016/06/21 22:47:01, RobertoCN wrote: > > > Nit: devices_tested > > > > Done. > > > > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > > scripts/slave/recipe_modules/auto_bisect/api.py:336: > > env=self.m.chromium.get_env()) > > On 2016/06/21 22:47:01, RobertoCN wrote: > > > Thanks for fixing this. > > > > Done. > > > > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > > File scripts/slave/recipe_modules/chromium_android/api.py (right): > > > > > https://codereview.chromium.org/2045043002/diff/40001/scripts/slave/recipe_mo... > > scripts/slave/recipe_modules/chromium_android/api.py:1009: "name": "testA", > > On 2016/06/21 22:47:01, RobertoCN wrote: > > > if the only changes in this file are whitespace fixes, then we shouldn't > have > > > this file in this CL. > > > > Done. > > Dry run failed because you are missing coverage of one line. Easiest thing to do > at this point is run recipe simulation test, look at the output of missing > coverage and locate the line that is not covered (bisect_tester/perf_test it > seems) and append ` # pragma: no cover` to that line. Build presubmit passed.
https://codereview.chromium.org/2045043002/diff/100001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/bisect_tester/perf_test.py (right): https://codereview.chromium.org/2045043002/diff/100001/scripts/slave/recipe_m... scripts/slave/recipe_modules/bisect_tester/perf_test.py:98: command += '--device ' + device_serial_number # pragma: no cover shouldn't it be ' --device ' ?
https://codereview.chromium.org/2045043002/diff/100001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/bisect_tester/perf_test.py (right): https://codereview.chromium.org/2045043002/diff/100001/scripts/slave/recipe_m... scripts/slave/recipe_modules/bisect_tester/perf_test.py:98: command += '--device ' + device_serial_number # pragma: no cover On 2016/06/22 21:34:40, RobertoCN wrote: > shouldn't it be ' --device ' ? Nice catch, thanks!
The CQ bit was checked by zxiong@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
No L-G-T-M from a valid reviewer yet. CQ run can only be started by full committers or once the patch has received an L-G-T-M from a full committer. Even if an L-G-T-M may have been provided, it was from a non-committer, _not_ a full super star committer. Committers are members of the group "project-infra-committers". Note that this has nothing to do with OWNERS files.
The CQ bit was checked by zxiong@google.com
The CQ bit was unchecked by zxiong@google.com
The CQ bit was checked by zxiong@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
No L-G-T-M from a valid reviewer yet. CQ run can only be started by full committers or once the patch has received an L-G-T-M from a full committer. Even if an L-G-T-M may have been provided, it was from a non-committer, _not_ a full super star committer. Committers are members of the group "project-infra-committers". Note that this has nothing to do with OWNERS files.
The CQ bit was checked by robertocn@chromium.org
lgtm
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: Build Presubmit on master.tryserver.infra (JOB_FAILED, https://build.chromium.org/p/tryserver.infra/builders/Build%20Presubmit/build...)
https://codereview.chromium.org/2045043002/diff/180001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/chromium_android/api.py (right): https://codereview.chromium.org/2045043002/diff/180001/scripts/slave/recipe_m... scripts/slave/recipe_modules/chromium_android/api.py:1070: "name": "testA", Undo this change and retrain. Otherwise we'll need lgtms from the owners of these.
The CQ bit was checked by zxiong@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from robertocn@chromium.org Link to the patchset: https://codereview.chromium.org/2045043002/#ps200001 (title: "Remove unnecessary changes")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: Build Presubmit on master.tryserver.infra (JOB_FAILED, https://build.chromium.org/p/tryserver.infra/builders/Build%20Presubmit/build...)
The CQ bit was checked by zxiong@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from robertocn@chromium.org Link to the patchset: https://codereview.chromium.org/2045043002/#ps220001 (title: "Update unexpected files")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by zxiong@google.com
The CQ bit was checked by zxiong@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= ========== to ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f... ==========
Message was sent while issue was closed.
Committed patchset #12 (id:220001) as https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f...
Message was sent while issue was closed.
A revert of this CL (patchset #12 id:220001) has been created in https://codereview.chromium.org/2112553005/ by zxiong@google.com. The reason for reverting is: Broke bisect jobs, android_chromium.api.devices() should be changed to android_chromium.api.devices.
Message was sent while issue was closed.
dtu@chromium.org changed reviewers: + dtu@chromium.org
Message was sent while issue was closed.
https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except api.m.step.StepFailure: Can you detect in advance which devices are online and start out by using those specifically? Better to be proactive than wait for a failure! Also step failures could happen for a lot of reasons, so we could be spending significant resources to retry something that's not working because of a test failure. It may be better to not include retry logic here after all. https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/bisect_tester/api.py (right): https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... scripts/slave/recipe_modules/bisect_tester/api.py:20: self.device_to_test = None Call me an OOP purist, but I dislike having public fields here. These should be accessed with member functions instead.
Message was sent while issue was closed.
https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right): https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... scripts/slave/recipe_modules/auto_bisect/local_bisect.py:31: except api.m.step.StepFailure: On 2016/07/06 21:14:09, dtu wrote: > Can you detect in advance which devices are online and start out by using those > specifically? Better to be proactive than wait for a failure! > > Also step failures could happen for a lot of reasons, so we could be spending > significant resources to retry something that's not working because of a test > failure. It may be better to not include retry logic here after all. See new issue: https://codereview.chromium.org/2119483003/#ps20001 https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... File scripts/slave/recipe_modules/bisect_tester/api.py (right): https://codereview.chromium.org/2045043002/diff/220001/scripts/slave/recipe_m... scripts/slave/recipe_modules/bisect_tester/api.py:20: self.device_to_test = None On 2016/07/06 21:14:09, dtu wrote: > Call me an OOP purist, but I dislike having public fields here. These should be > accessed with member functions instead. See new issue: https://codereview.chromium.org/2119483003/#ps20001
Message was sent while issue was closed.
Description was changed from ========== Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f... ========== to ========== Allow multiple devices on bisects hosts Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f... ==========
Message was sent while issue was closed.
Description was changed from ========== Allow multiple devices on bisects hosts Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. BUG= Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f... ========== to ========== Allow multiple devices on bisects hosts Right now, when an android device connected to a bisect linux host goes offline, we still send bisects to that host, and the bisects fail. So the device needs to be fixed with extremely urgent priority. This CL aims to allow multiple devices to be connected to a linux host and if a device failed, the job would be retried with a device that is still working. Committed: https://chromium.googlesource.com/chromium/tools/build/+/ad6bb0da9b1a53daae0f... ========== |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
