Closed
Bug 567274
Opened 14 years ago
Closed 12 years ago
Talos should halt on download or unzip failure
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: philor, Assigned: edransch)
Details
(Whiteboard: [talos][automation])
Attachments
(2 files, 1 obsolete file)
982 bytes,
patch
|
Details | Diff | Splinter Review | |
10.92 KB,
patch
|
catlee
:
review+
catlee
:
checked-in+
|
Details | Diff | Splinter Review |
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274399232.1274399865.15943.gz Rev3 WINNT 6.1 mozilla-central talos on 2010/05/20 16:47:12 inflating: firefox/xul.dll bad CRC ff3b34a5 (should be f3a57fd9) program finished with exit code 2 ... Running test tdhtml: NOISE: __FAILbrowser non-zero return code (-1073741515)__FAIL While http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274399212.1274399358.13547.gz is an xpcshell test that got the same busted zip, it sensibly gave up when unzipping failed, rather than trying to run some partial, broken browser. Since there's no good that can come from running part of a browser, only red or worse (if it's possible to unzip only part of the browser, but then run it, the perf numbers from that would be... unreliable), it seems like it should bail when it doesn't unzip.
Comment 1•14 years ago
|
||
This will force the step to halt the build if there is an error unpacking the file. The build will still run the reboot step is it has alwaysRun=True.
Comment 2•14 years ago
|
||
If we were to fix bug 557336 we could use the same base class for the setup and tear down of unit tests and talos runs. This seems like a good thing as both are running in the same pool of slaves and avoids code duplication.
Updated•14 years ago
|
Priority: -- → P3
Whiteboard: [talos][automation]
Reporter | ||
Updated•13 years ago
|
Summary: Talos should flunk on unzip failure → Talos should halt on download or unzip failure
Comment 3•13 years ago
|
||
We should probably add haltOnFailure for most, if not all, of the DownloadFile and UnpackFile steps in TalosFactory and RuntimeTalosFactory. The only exception, I think, is for the download/unpack symbols. Because these aren't a _crucial_ part of the test process, I think it'd be better to continue on even if we fail to download or unpack them. We need to go through all the DownloadFile/UnpackFile steps starting from http://hg.mozilla.org/build/buildbotcustom/file/default/process/factory.py#l7004, ending at http://hg.mozilla.org/build/buildbotcustom/file/default/process/factory.py#l7723, and see which ones need this change applied.
Comment 4•13 years ago
|
||
Same goes for the UnittestPackagedBuildFactory: http://hg.mozilla.org/build/buildbotcustom/file/default/process/factory.py#l6576
Assignee | ||
Comment 5•13 years ago
|
||
added haltOnFailure to UnpackFile and DownloadFile in Talos Factory (except for Download/Unpacks of symbols, as mentioned above).
Attachment #586171 -
Flags: review?(catlee)
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → edransch
Assignee | ||
Comment 6•13 years ago
|
||
Attachment #586171 -
Attachment is obsolete: true
Attachment #586487 -
Flags: review?(catlee)
Attachment #586171 -
Flags: review?(catlee)
Assignee | ||
Comment 7•13 years ago
|
||
Comment on attachment 586487 [details] [diff] [review] Revised patch Revised patch to correctly handle post-failure reboot.
Updated•13 years ago
|
Attachment #586487 -
Flags: review?(catlee) → review+
Updated•13 years ago
|
Attachment #586487 -
Flags: checked-in+
Comment 8•12 years ago
|
||
This made it to production yesterday. Yay!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•