moblab-generic-vm-paladin failed but CQ passed |
||
Issue descriptionhttps://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/17524 moblab-generic-vm-paladin failed at HWTest stage due to the following erorr:The MoblabVMTest stage failed: Moblab run_suite succeeded, but did not successfully run dummy_PassServer Then CQ chose to destructed itself and stopped waiting for the following slaves: caroline-paladin: aborted by self-destruction veyron_minnie-paladin: aborted by self-destruction cyan-paladin: aborted by self-destruction cave-paladin: aborted by self-destruction auron_yuna-paladin: aborted by self-destruction At the end, the CQ marked itself as passed. Is this expected? How could a slave fail but master pass?
,
Jan 19 2018
nxia@, do we have that kind of smart CQ mechanism as #2 mentioned?
,
Jan 19 2018
Yes, all the relevant slaves of the CLs to test passed, so the CQ destructed itself with success. 09:12:44: INFO: Moving CL:*546618 CL:*549938 CL:*549978 CL:872457 CL:874760 CL:874761 to will_submit set, because their relevant builds completed successfully or all failures are ignorable or passed in CQ history. 09:12:44: INFO: will_submit set contains 6 changes: [CL:*546618 CL:*549938 CL:*549978 CL:872457 CL:874760 CL:874761] might_submit set contains 0 changes: [] will_not_submit set contains 0 changes: [] [1;33m09:12:44: WARNING: This build will self-destruct given the results of relevant change triages.[0m 09:12:44: INFO: This build will self-destruct with success.
,
Jan 19 2018
Good to know |
||
►
Sign in to add a comment |
||
Comment 1 by lannmar...@gmail.com
, Jan 19 2018