Closed
Bug 828670
Opened 11 years ago
Closed 11 years ago
Make emulator tests specify emulator version in tree
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jgriffin, Assigned: jgriffin)
Details
(Whiteboard: [mozharness][leave open])
Attachments
(2 files, 2 obsolete files)
715 bytes,
patch
|
mozilla
:
review+
|
Details | Diff | Splinter Review |
4.59 KB,
patch
|
jgriffin
:
review+
|
Details | Diff | Splinter Review |
Currently, the version of the emulator used in emulator tests is specified in the mozharness config for those tests. When we change this, it can cause tests to go orange (e.g., bug 828633) without leaving an obvious reason to sheriffs and others who are watching the tree. Instead, we should store the version of the emulator to use in a file in tree (ala talos.json) and use that instead of a mozharness config variable. This way, we'll need to land a patch per tree to update the emulator, and the cause of any breakage should be more discernible.
Updated•11 years ago
|
Whiteboard: [mozharness]
Comment 1•11 years ago
|
||
We can check in this manifest directly: http://hg.mozilla.org/build/mozharness/file/2bc3da1331eb/configs/marionette/automation_emulator_config.py#l3 (the contents between the """'s) Then we can grab that file from hgweb and point tooltool at it in EmulatorMixin.install_emulator(). http://hg.mozilla.org/build/mozharness/file/2bc3da1331eb/mozharness/mozilla/testing/unittest.py#l159
Comment 2•11 years ago
|
||
Thank you for filing this :-D
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → jgriffin
Assignee | ||
Comment 3•11 years ago
|
||
This might work; I'll try it out on ash.
Assignee | ||
Comment 4•11 years ago
|
||
Assignee | ||
Comment 5•11 years ago
|
||
This successfully worked on ash: https://tbpl.mozilla.org/php/getParsedLog.php?id=18695161&tree=Ash&full=1; running a rull re-trigger now.
Attachment #701181 -
Flags: review?(aki)
Assignee | ||
Updated•11 years ago
|
Attachment #700743 -
Attachment is obsolete: true
Assignee | ||
Updated•11 years ago
|
Attachment #700744 -
Flags: review?(aki)
Updated•11 years ago
|
Attachment #700744 -
Flags: review?(aki) → review+
Comment 6•11 years ago
|
||
Comment on attachment 701181 [details] [diff] [review] Install emulator from in-tree manifest, Hm. Do we really need create_tooltool_manifest() here? It's basically taking text and creating a plaintext .tt file. In essence we're downloading a file to 'emulator.manifest', reading it, then writing the contents to 'tooltool.tt'. I think it might be easiest to just download the file to 'tooltool.tt'. r=me with that change.
Attachment #701181 -
Flags: review?(aki) → review+
Assignee | ||
Comment 7•11 years ago
|
||
Landed the manifest: https://hg.mozilla.org/integration/mozilla-inbound/rev/350692e88e4c This will need to be landed on every tree that runs emulator tests before the mozharness changes.
Whiteboard: [mozharness] → [mozharness][leave open]
Assignee | ||
Comment 8•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/e03fc3e18dfc https://hg.mozilla.org/releases/mozilla-b2g18/rev/73992309b6dc I'll let this propagate normally into m-c, fx-team, and services-central before landing the mozharness change.
Assignee | ||
Comment 9•11 years ago
|
||
Updated per review comments; ash run was green.
Assignee | ||
Updated•11 years ago
|
Attachment #701181 -
Attachment is obsolete: true
Assignee | ||
Comment 10•11 years ago
|
||
Comment on attachment 701220 [details] [diff] [review] Install emulator from in-tree manifest, Carry r+ forward.
Attachment #701220 -
Flags: review+
Assignee | ||
Comment 12•11 years ago
|
||
The gecko change has made its way into both fx-team and services-central, so I've landed the mozharness change: http://hg.mozilla.org/build/mozharness/rev/4fe45d726b2b
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•