Those failures have been started recently and seem to happen more frequently but not permanent across platforms.
New wizard page has been selected - got downloading, expected finished
For better results:
*** Updating to branch 'default'
pulling from mozmill-tests
searching for changes
no changes found
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
TEST-START | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test1.js | setupModule
TEST-PASS | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test1.js | test1.js::setupModule
TEST-START | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | setupModule
TEST-PASS | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | test2.js::setupModule
TEST-START | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | testDirectUpdate_Download
TEST-UNEXPECTED-FAIL | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | test2.js::testDirectUpdate_Download
TEST-START | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | teardownModule
TEST-PASS | /var/folders/vq/bds4whmx4jg5n19nm5p_9xfr0000gp/T/tmpUaJnjZ.mozmill-tests/tests/update/testDirectUpdate/test2.js | test2.js::teardownModule
The regression has been started on May 23rd and is most likely because of the background updates.
Passed: 20120522145033 (http://mozmill-ci.blargon7.com/#/update/report/f87375a634b1a5ba746e5f763a6e3512)
Failed: 20120523112744 (http://mozmill-ci.blargon7.com/#/update/report/f87375a634b1a5ba746e5f763a7386b1)
Ehsan, which of the patches could have regressed this? As what I can see it's because of applying the patch in the old updater ui. There should have probably been a new wizard page but now we re-use the 'downloading' one.
Simplest solution for us would be to wait a bit longer for the finished pane once the download has been finished.
FWIW, there are no background updates related patches in that range. If this is indeed caused by background updates, the correct solution is to increase the timeout, as I think I noted to Anthony some time ago. Otherwise, you need to bisect the range to see what is causing this failure to happen.
Sorry forgot that the updates were disabled for a couple of days last week. So the regression range is wrong. In fact it is a fallout from bug 307181, especially:
Given that no new pane has been used for the 'apply' state, waiting until the current pane is not the downloading pane should be sufficient for our case. I will attach a patch in a minute which works fine for me.
Created attachment 627976 [details] [diff] [review]
Created attachment 627978 [details] [diff] [review]
Fixed the alphabetical order in the declaration section and a single typo.
Comment on attachment 627978 [details] [diff] [review]
Looks good, and tests are passing for me. Landed as:
Do we need to transplant this?
Thanks Dave for landing this patch! No I do not think that we want to transplant it because it would need a different patch for the other branches, and once we have to merge one more patch is necessary. So lets bake it on mozilla-central and let it flow with the usual merge process.