hostinfo changes broke test_for_push |
|||||
Issue description[chromeos-autotest.hot.corp.google.com] out: testbed_DummyTest [ FAILED ] [chromeos-autotest.hot.corp.google.com] out: testbed_DummyTest FAIL: Unhandled AutoservError: The host android1758-row1-rack7-test-station-4.cros has no attribute job_repo_url_84B7N16625000441. `install_apk_from_build` only works for test with image specified. Error logs: http://shortn/_HUsgtIknoc
,
Mar 7 2017
Found it: http://shortn/_lFL5gMUmxc testbed creates adbhost without going through the factory methods, so it doesn't get the HostInfoStore correctly.
,
Mar 7 2017
,
Mar 7 2017
This could potentially break testbed tests that need even labels (not just attributes). But the only relevant CL since the last push can be reverted to unblock us: https://chromium-review.googlesource.com/c/450845/
,
Mar 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a commit b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a Author: Prathmesh Prabhu <pprabhu@chromium.org> Date: Tue Mar 07 19:14:48 2017 Revert "Use HostInfo to obtain host attributes" This reverts commit 838f89f628e404bd3d657e5eb4b45c02bfb363b9. Original change's description: > Use HostInfo to obtain host attributes > > BUG= chromium:678430 > TEST=unittests > > Change-Id: I4ae2d4ee0c19eae5545eeb9ff01a7fe8853bc34d > Reviewed-on: https://chromium-review.googlesource.com/440366 > Commit-Ready: Prathmesh Prabhu <pprabhu@chromium.org> > Tested-by: Prathmesh Prabhu <pprabhu@chromium.org> > Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org> > TBR=pprabhu@chromium.org,ayatane@chromium.org BUG= chromium:678430 BUG= chromium:699188 Change-Id: I36b47500518ef4a710145f35f730e53d40cdb0a0 Reviewed-on: https://chromium-review.googlesource.com/450845 Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org> Tested-by: Prathmesh Prabhu <pprabhu@chromium.org> [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/site_tests/android_ACTS/android_ACTS.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/afe_utils.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/hosts/cros_host.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/site_tests/autoupdate_EndToEndTest/autoupdate_EndToEndTest.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/adb_utils.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/cros/autoupdate_utils.py [modify] https://crrev.com/b9d7adf07aec05db6a3f1a8b74f45abd7a87c74a/server/hosts/adb_host.py
,
Mar 7 2017
http://chromeos-autotest.hot.corp.google.com/afe/#tab_id=view_job&object_id=6195 I manually updated the repos on push servers and cloned the failed job. It passed. So we're in the clear. I've also manually kicked a test_push again.
,
Mar 7 2017
Follow ups (why did this happen): - We need testbed coverage in the CQ: issue 699211 - I must admit that there was some lapse of testing on my part: I test my changes against a CrOS DUT locally using a local autotest setup. I don't currently intend to add a testbed to that setup. Should I? Are we suggesting that all infra team members working on autotest test their changes against a local testbed? - There's clearly lacking unittest coverage of the host classes.
,
Mar 7 2017
Re #7 For such changes, usually I will borrow the test push environment, cherrypick the change to drone and run a test_push run.
,
Mar 7 2017
I could start doing #8, but I think we don't want to encourage that. We often end up leaving the push environment in weird states that in the best case cause the following test_push to fail (happens almost every other week) and in the worst case silently pass in an environment that no longer reflects prod.
,
Mar 7 2017
Not fixed. We still see the same issue. And guess what, this CL is in git log cros/prod..cros/master at this point: commit c239c0a22120c7a50177bb3243ec3e8267290b4f Author: Dan Shi <dshi@google.com> Date: Wed Mar 1 21:50:54 2017 +0000 Revert "[autotest] Disable testbed in test push before testbed is restored" This reverts commit ff92802456f39d7b939b841318021d65e38f3ff6. Change-Id: I49541bc19b2504e8bb3b3fd4619c1324722968f3 Reviewed-on: https://chromium-review.googlesource.com/447855 Tested-by: Dan Shi <dshi@google.com> Trybot-Ready: Dan Shi <dshi@google.com> Reviewed-by: Shuqian Zhao <shuqianz@chromium.org> Commit-Queue: Dan Shi <dshi@google.com> So, we just restarted testbed testing in test_push after a couple weeks. So, my assumption that the bad CL had to be something since last push is incorrect. It could be an older CL. Also, this means that it is possible testbed testing is currently broken in prod....? At this point, it's better to just chump the fix that I already have in the CQ: https://chromium-review.googlesource.com/c/450866/
,
Mar 7 2017
False alarm. This one is really issue 699254
,
Mar 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/8456cb61eea2e6e9173f457ba351755876da8fce commit 8456cb61eea2e6e9173f457ba351755876da8fce Author: Prathmesh Prabhu <pprabhu@chromium.org> Date: Wed Mar 08 00:18:22 2017 [autotest] Pass in HostInfoStore from TestBed to it's children BUG= chromium:699188 BUG= chromium:678430 TEST=unittests, test_push passes. Change-Id: I08c75151e8b8e2aeaac76ae1151dcb1759d8c935 Reviewed-on: https://chromium-review.googlesource.com/450866 Commit-Ready: Prathmesh Prabhu <pprabhu@chromium.org> Tested-by: Prathmesh Prabhu <pprabhu@chromium.org> Reviewed-by: Dan Shi <dshi@google.com> [modify] https://crrev.com/8456cb61eea2e6e9173f457ba351755876da8fce/server/hosts/testbed.py |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pprabhu@chromium.org
, Mar 7 2017