Add a testbed test to the CQ |
||||||||||
Issue descriptionProbably via moblab's suite? I'm making changes to the way host objects are used and have had to revert CLs mutiple times now because I didn't test testbed locally. Testing changes to testbed locally is hard. Can I haz some CQ coverage? What would be involved? See issue 699188 . The problem itself was trivial (I had a fix in < 10 minutes), but this was blocking a test_push which was blocking a push needed to fix another P-0 in prod. So, I chose to revert my CL instead of landing the trivial fix. I really don't want to do this. :(
,
Mar 7 2017
This is seriously slowing me down.
,
Mar 7 2017
,
Mar 7 2017
q1) Can this be made reliable enough for the CQ? q2) Can this coverage be gained by unit tests or virtualization? q3) If the answer to above 2 is no, then does this even belong in the push to prod test?
,
Mar 7 2017
Re #4.q3) In the specific case of issue 699188 , test_push did it's job. Without the test in the push to prod test, I would have broken android testing in prod...
,
Mar 7 2017
The reason we have this in test_push is to prevent outages, which is significantly better having nothing at all. q2) Adding unittests is a good first step but I think a lot of the DB/RPC interactions may have to be mocked out and not have covered this. But we can investigate this. q1) We already have a fair amount of flake with Moblab testing... this adds more complexity say should the android test devices get stuck or power down, etc. The main reason there was a forced revert rather than wait for a simple fix was b/c there was another big outage due to the lack of AFE UI testing in the CQ and test_push. Do we plan to address that as well?
,
Mar 7 2017
I write provide a functional end-to-end MobLab+Testbed integration test. Whether or not it will be ran in the lab or used just locally at one's desk for verification is still open for debate.
,
Mar 7 2017
,
Jul 17 2017
ChromeOS Infra P1 Bugscrub. P1 Bugs in this component should be important enough to get weekly status updates. Is this already fixed? -> Fixed Is this no longer relevant? -> Archived or WontFix Is this not a P1, based on go/chromeos-infra-bug-slo rubric? -> lower priority. Is this a Feature Request rather than a bug? Type -> Feature Is this missing important information or scope needed to decide how to proceed? -> Ask question on bug, possibly reassign. Does this bug have the wrong owner? -> reassign. Bugs that remain in this state next week will be downgraded to P2.
,
Jul 24 2017
ChromeOS Infra P1 Bugscrub. Issue untouched in a week after previous message. Downgrading to P2.
,
Jun 8 2018
Hi, this bug has not been updated recently. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be archived. Thank you.
,
Aug 2
,
Aug 22
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by sbasi@chromium.org
, Mar 7 2017