Closed
Bug 1242682
Opened 8 years ago
Closed 8 years ago
Separate dom/media into its own subsuite
Categories
(Testing :: General, defect)
Testing
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: armenzg, Assigned: jmaher)
References
Details
Attachments
(3 files, 10 obsolete files)
<jmaher> armenzg: with the 15 chunks, dom/media dominated 37 of the 57 minutes <jmaher> dom/media/* <armenzg> jmaher, maybe subsuite? <jmaher> armenzg: that might be a good thing- if we did that, we would need to add buildbot jobs for it <armenzg> this happens to us for looking too closely <armenzg> let them run! let them run! <armenzg> :) <jmaher> heh <jmaher> if dom/media was a subsuite (like gl), then it would solve a lot of the other runtime issues and we would have more balanced chunks overall
Assignee | ||
Comment 1•8 years ago
|
||
:cpearce, do you know who would be the best person to contact about any organizational or other issues with moving the /dom/media mochitests into their own job? We can handle the treeherder/buildbot/mochitest work, just wanted to ensure this is not going to confuse developers.
Flags: needinfo?(cpearce)
Comment 2•8 years ago
|
||
I am the module owner for media playback, so most of the affected tests in dom/media/test are owned by my team. I'd be fine with those mochitests being their own mochitest job. Splitting them into multiple jobs on Android would result in better turn-around, as these tests span multiple jobs there already. The WebRTC mochitests are in dom/media/tests (with an 's', confusingly). Those tests would also be affected, so ni? jesup. I think it makes sense for the media playback and WebRTC tests to be run together, since we share some underlying infrastructure.
Flags: needinfo?(cpearce) → needinfo?(rjesup)
Assignee | ||
Comment 3•8 years ago
|
||
thanks Chris! I would assume all the media playback and webrtc would be together in the same job. Splitting up on Android seems like a good idea.
Comment 4•8 years ago
|
||
Sounds good to me. Also easier to know which tests to push in Try!
Flags: needinfo?(rjesup)
Reporter | ||
Updated•8 years ago
|
No longer blocks: tc-linux64-debug
Assignee | ||
Comment 5•8 years ago
|
||
Assignee | ||
Comment 6•8 years ago
|
||
Assignee | ||
Comment 7•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/33681/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/33681/
Attachment #8716018 -
Flags: review?(armenzg)
Reporter | ||
Comment 8•8 years ago
|
||
Comment on attachment 8716015 [details] [diff] [review] buildbot patch for running --subsuite=media Review of attachment 8716015 [details] [diff] [review]: ----------------------------------------------------------------- Only the fix of the comment. ::: mozilla-tests/config.py @@ +2627,5 @@ > > > +### Tests Enabled in Gecko 47+ ### > + > +# Bug 1156357 - Enable mochitest-push to ride the trains I don't think this comment is accurate.
Attachment #8716015 -
Flags: review?(armenzg) → review+
Reporter | ||
Updated•8 years ago
|
Attachment #8716018 -
Flags: review?(armenzg) → review+
Reporter | ||
Comment 9•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown https://reviewboard.mozilla.org/r/33681/#review30405 That's awesome! thank you!
Assignee | ||
Comment 10•8 years ago
|
||
this will need to land on m-c first (and get merged around), then land a buildbot change. While it is landed we will be without coverage for the few hours until buildbot reconfig is completed. Looking at try, all is well- a few extra things I need to sort out though: 1) e10s- I didn't account for that in buildbot or taskcluster 2) android - need to figure out what we run and ensure we have a job for android able to run. 3) b2g - I am not sure if we run on b2g- I don't plan to test on there, but would like to make someone aware of this is needed. :cpearce, the items mentioned above ^, do you have any concerns? Are you fine with us having a job letter 'm' in treeherder? Think to a future with more tests and it might be m1 m2, would that still be good?
Flags: needinfo?(cpearce)
Comment 11•8 years ago
|
||
I think this would be a good change for Android too. dom/media makes M9 one of the slowest mochitest chunks on Android 2.3 especially. I think you would just need to make corresponding buildbot (mozilla-tests/mobile_config.py) and mozharness config (configs/android) changes for Android.
Comment 12•8 years ago
|
||
Just so I understand what's being proposed, will there be a 'm' job as a subjob of the jobs in the 'M' group, i.e. for the 'M' mochitest group on treeherder, we'll have: M( 1, 2, 3.., JP, bc1, m) ... where 'm' is he new media job? That sounds fine to me. My only concern is that 'm' for media would be confused with 'M' for mochitest... Given that Treeherder now collapses job names by default, can we just call the job 'media', or 'mda', or something like that to disambiguate it?
Flags: needinfo?(cpearce)
Assignee | ||
Comment 13•8 years ago
|
||
'mda' sounds good!
Assignee | ||
Comment 14•8 years ago
|
||
updated patch including: * android 2.3 and 4.3 * e10s The only question here is if we should chunk the android tests.
Attachment #8716015 -
Attachment is obsolete: true
Attachment #8716615 -
Flags: review?(kmoir)
Assignee | ||
Comment 15•8 years ago
|
||
Attachment #8716016 -
Attachment is obsolete: true
Assignee | ||
Comment 16•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown Review request updated; see interdiff: https://reviewboard.mozilla.org/r/33681/diff/1-2/
Assignee | ||
Comment 17•8 years ago
|
||
:armen, I asked you for review again as I updated the patch for e10s and for android.
Flags: needinfo?(armenzg)
Comment 18•8 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #14) > The only question here is if we should chunk the android tests. I think Android 2.3 opt should run as 2 chunks; it looks to me like dom/media takes about 90 minutes there. On 4.3 opt, it's about 50 minutes and on 4.3 debug, about 70 minutes.
Comment 19•8 years ago
|
||
jmaher: I don't understand this part BRANCHES[name]['platforms'][platform]['ubuntu64_vm_armv7_large']['opt_unittest_suites'] += ANDROID_4_3_MOCHITEST_MEDIA + BRANCHES[name]['platforms'][platform]['ubuntu64_vm_armv7_large']['debug_unittest_suites'] += ANDROID_4_3_MOCHITEST_MEDIA + BRANCHES[name]['platforms'][platform]['ubuntu64_vm_armv7_mobile']['opt_unittest_suites'] += ANDROID_4_3_MOCHITEST_MEDIA + BRANCHES[name]['platforms'][platform]['ubuntu64_vm_armv7_mobile']['debug_unittest_suites'] += ANDROID_4_3_MOCHITEST_MEDIA why are we running the tests on both types of instances? Shouldn't they just be assigned to one?
Flags: needinfo?(jmaher)
Reporter | ||
Updated•8 years ago
|
Attachment #8716018 -
Flags: review+
Reporter | ||
Comment 20•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown https://reviewboard.mozilla.org/r/33681/#review30627 ::: testing/taskcluster/tasks/branches/base_job_flags.yml:148 (Diff revision 2) > + - mochitest-media This will enable it across all trunk trees, are we ready to enable it? If you're not adding the e10s version, is that because we're not ready? Close the issue at your own. ::: testing/taskcluster/tasks/branches/try/job_flags.yml:210 (Diff revision 2) > + task: tasks/tests/fx_linux64_mochitest_media_e10s.yml The gecko decision task will fail if fx_linux64_mochitest_media_e10s.yml does not exist.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(armenzg)
Comment 21•8 years ago
|
||
(In reply to Kim Moir [:kmoir] from comment #19) > why are we running the tests on both types of instances? Shouldn't they > just be assigned to one? The split between ubuntu64_vm_armv7_mobile and the more powerful ubuntu64_vm_armv7_large for Android mochitests is a little complicated. I believe it is: 2.3 opt plain-mochitest ubuntu64_vm_armv7_mobile 2.3 opt mochitest-gl ubuntu64_vm_armv7_mobile 4.3 opt plain-mochitest ubuntu64_vm_armv7_large 4.3 opt mochitest-gl ubuntu64_vm_armv7_mobile 4.3 debug plain-mochitest ubuntu64_vm_armv7_large 4.3 debug mochitest-gl ubuntu64_vm_armv7_large For this bug, we shouldn't care about mochitest-gl. To keep media running on the same aws instance types, we should want: 2.3 opt media ubuntu64_vm_armv7_mobile 4.3 opt media ubuntu64_vm_armv7_large 4.3 debug media ubuntu64_vm_armv7_large *I* don't know how that translates into those BRANCHES arrays!
Updated•8 years ago
|
Attachment #8716615 -
Flags: review?(kmoir)
Assignee | ||
Updated•8 years ago
|
Attachment #8716018 -
Flags: review?(armenzg)
Assignee | ||
Comment 22•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown Review request updated; see interdiff: https://reviewboard.mozilla.org/r/33681/diff/2-3/
Assignee | ||
Comment 23•8 years ago
|
||
updated with proper vm types, and as we all know the linux64 builder limits are at the limit :) because of that, I am ignoring linux64 e10s media tests for now. Ideally next week these will all be running in taskcluster and we can disable some tests, and before long many more tests. I can rearrange as needed.
Attachment #8716615 -
Attachment is obsolete: true
Flags: needinfo?(jmaher)
Attachment #8721445 -
Flags: review?(kmoir)
Assignee | ||
Comment 24•8 years ago
|
||
to go along with the buildbot patch :kmoir!
Attachment #8716616 -
Attachment is obsolete: true
Updated•8 years ago
|
Attachment #8721445 -
Flags: review?(kmoir) → review+
Reporter | ||
Updated•8 years ago
|
Attachment #8716018 -
Flags: review?(armenzg) → review+
Reporter | ||
Comment 25•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown https://reviewboard.mozilla.org/r/33681/#review32333 Address the comment and feel free to land. ::: testing/taskcluster/tasks/branches/base_job_flags.yml:151 (Diff revision 3) > + - mochitest-media You also need mochitest-media-e10s.
Comment 26•8 years ago
|
||
I just remembered that we should check the regexes here to see that they match for the new tests, but it seems to be okay since they are all mochitests https://github.com/mozilla/build-cloud-tools/blob/master/configs/watch_pending.cfg
Comment 28•8 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #10) > this will need to land on m-c first (and get merged around), then land a > buildbot change. While it is landed we will be without coverage for the few > hours until buildbot reconfig is completed. And you almost got away with not doing that and instead having mozilla-inbound not run them for most of a day, despite the fact that Sunday evening is when most of the patches which need dom/media/ coverage land as NZ wakes up Monday morning and lands stuff. Alas, https://treeherder.mozilla.org/logviewer.html#?job_id=22084742&repo=mozilla-inbound - the shuffling around of remaining things on Android exposed that test_mozpaymentprovider.html apparently has some dependency on running after something else it was running after and now is not, which made me look at what you were doing and realize that you were shutting off tests at the single worst possible time to shut them off. Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/08d7af2bfe30
Assignee | ||
Comment 29•8 years ago
|
||
I am not aware of another way to do this. We need the changes to propagate to all trunk branches before doing the buildbot reconfig- is there a magic trick I am not aware of? I saw the android failure on try, I assumed it was a known issue. I need to figure that out before sorting this out again.
Flags: needinfo?(philringnalda)
Comment 30•8 years ago
|
||
The other way is to arrange to have a relenger and a sheriff handy, land on m-c and land the configs patch, have your sheriff merge m-c around, have your relenger merge to prod and reconfig, or for a perhaps-workable DIY which I wouldn't do without talking to a relenger, land it yourself on m-c at 10 minutes before the hour, merge it around yourself since https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Merges isn't rocket science, land the configs patch and merge it to production and let the automatic reconfig on the hour which I think, maybe, perhaps exists do the reconfig for you if it does in fact exist. Or, don't land the in-tree part, just arrange for a reconfig when you have a sheriff available, and let the empty jobs burn and hide them - the sheriff will have to resave the exclusion after a job burns because a matching exclusion doesn't actually match until it's saved after the job has run once (on every platform), but known meaningless red isn't _that_ big a deal, as long as it's known and happening when a sheriff is actually going to be available for several hours. Then when you again have a sheriff available who knows what to expect, land on m-i, star the hidden reds for 20 pushes back (20 seconds work), unhide on m-i (5 seconds work), then do the same on m-c and f-t and try when it's merged around. Slightly more work, but it has the advantage of producing fewer jobs without test coverage since only old-parent pushes to try after the reconfig have no dom/media/ tests run at all (unless they are aurora-as-beta simulations which import this patch to be able to still get coverage, Ryan).
Flags: needinfo?(philringnalda)
Assignee | ||
Comment 31•8 years ago
|
||
As this was backed out for a failure in dom/payment/tests/mochitest/test_mozpaymentprovider.html, I need to understand why that test fails and dom/payment/tests/mochitest/test_mozpay_callbacks.html passes. here is a log file: http://archive.mozilla.org/pub/mobile/try-builds/jmaher@mozilla.com-60bf1da5132adc964855e4f7668534117ca3d57c/try-android-api-15/try_ubuntu64_vm_armv7_large_test-mochitest-9-bm122-tests1-linux64-build279.txt.gz here is a try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=60bf1da5132a Some how dom/media/* is a pre-requisite for running this test on android*. :ferjm, :fabrice- as you two have written this test, can you help me figure out why this depends on something from dom/media/* ? Is this test still useful? Can it be rewritten to be more reliable?
Flags: needinfo?(ferjmoreno)
Flags: needinfo?(fabrice)
Comment 32•8 years ago
|
||
Why is that test running on Android at all? There is a default skip-if for Android in dom/payment/tests/mochitest/mochitest.ini.
Comment 33•8 years ago
|
||
Oops, nevermind -- that's skip-if...toolkit != 'Android'. It looks like it should be running.
Assignee | ||
Comment 34•8 years ago
|
||
mozpayment tests are not needed on android, I am going to disable them for android.
Flags: needinfo?(ferjmoreno)
Flags: needinfo?(fabrice)
Assignee | ||
Comment 35•8 years ago
|
||
removing mozpayment and pushing this patch to try, I end up with new failure: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c2982ac8fa7d in android 2.3 m14: TEST-UNEXPECTED-FAIL | layout/forms/test/test_bug346043.html | application timed out after 330 seconds with no output PROCESS-CRASH | layout/forms/test/test_bug346043.html | application crashed [None] :gbrown, do you have any ideas here? Why is this only on android 2.3?
Flags: needinfo?(gbrown)
Comment 36•8 years ago
|
||
I don't know that this explains the failure, but I notice something else that I don't understand: Why didn't layout/forms/test/test_bug1111995.html run in your android 2.3 m14? It runs in your android 2.3 m15. But on central, in 2.3 m15, test_bug1111995.html runs before test_bug346043.html. I expect chunks to be re-balanced when tests are added/removed, but it looks like some were re-ordered also.
Flags: needinfo?(gbrown)
Comment 37•8 years ago
|
||
...some *tests* were re-ordered...
Comment 38•8 years ago
|
||
As Geoff alluded to, I have to believe that the failures are due to chunking boundary changes. Yay Android.
Assignee | ||
Comment 39•8 years ago
|
||
I agree 100% that this is related to chunking boundaries or pre-requisites. I know --run-by-dir would be a lot of work on android, but it would solve most of this headache. Let me disable until success and see where we are left at.
Comment 40•8 years ago
|
||
(In reply to Geoff Brown [:gbrown] from comment #36) > I expect chunks to be re-balanced when tests are added/removed, but it looks > like some were re-ordered also. I checked into this a little. At least when running mochitests by chunk (chunk_by_slice filter for manifestparser), the manifestparser seems to return a chunk of tests ordered as found in the manifest; the mochitest harness then sorts the tests within the chunk: http://hg.mozilla.org/mozilla-central/file/tip/testing/mochitest/runtests.py#l1098. The content in layout/forms/test/mochitest.ini is not fully sorted, so any change to the chunk boundaries can result in tests being re-ordered. I also noticed that other tests in this manifest have been disabled for similar issues: http://hg.mozilla.org/mozilla-central/file/tip/layout/forms/test/mochitest.ini#l54
Assignee | ||
Comment 41•8 years ago
|
||
ack, that is no fun, but makes sense. What is sad is that I see other layout/forms tests failing on android when pushing to try after disabling the one that popped up. Maybe we should do a run-by-dir push on android for future proofing it? To solve this specific problem, I would like to disable until I know the scope, then look at the tests which fail and maybe find a common thread- we could probably clean up these layout/forms tests with little work.
Assignee | ||
Comment 42•8 years ago
|
||
to get this green, we would need to comment out 5 test cases in layout/forms/test/mochitest.ini: [test_bug287446.html] -skip-if = (buildapp == 'b2g' && toolkit != 'gonk') #bug 947789 +skip-if = (buildapp == 'b2g' && toolkit != 'gonk') || (toolkit == 'android') #bug 947789 [test_bug345267.html] -skip-if = e10s +skip-if = e10s || (toolkit == 'android') [test_bug346043.html] +skip-if = toolkit == 'android' [test_bug348236.html] skip-if = buildapp == 'mulet' || buildapp == 'b2g' || toolkit == 'android' || e10s # b2g(select form control popup) b2g-debug(select form control popup) b2g-desktop(select form control popup) [test_bug353539.html] +skip-if = toolkit == 'android' [test_bug365410.html] +skip-if = toolkit == 'android' all these tests don't have anything obvious in common, nor do they have similar authors or components. :gbrown, do you have any other ideas of how to find a root cause of this?
Flags: needinfo?(gbrown)
Comment 43•8 years ago
|
||
I tried running these tests locally, individually, on the 2.3 emulator -- they passed, as though they do not depend on what was run earlier. Strange. I don't know what's going on.
Flags: needinfo?(gbrown)
Assignee | ||
Comment 44•8 years ago
|
||
Then most likely we have some test which runs prior to these tests changing the state and causing a failure. One possibility would be something earlier on which changes the state, then dom/media (or some other test) corrects that state, and finally layout/forms run great- remove dom/media and it fails. A second possibility is that we are shuffling around enough tests that something is now run in M14 which wasn't before and that is affecting layout/forms/*, and has nothing to do with dom/media.
Assignee | ||
Comment 45•8 years ago
|
||
and the culprit is (https://treeherder.mozilla.org/#/jobs?repo=try&revision=f6f693d7b13e): gfx/layers/apz/test/mochitest/test_basic_pan.html gfx/layers/apz/test/mochitest/test_tap.html commenting those two tests out allow layout/forms to work great. these are both new tests added this past week. :kats, can you help us figure out how these two new tests can cause layout/forms tests to fail on android 2.3?
Flags: needinfo?(bugmail.mozilla)
Comment 46•8 years ago
|
||
I looked at the try push in comment 35, which has one of the failures. First thing I noticed is that layout/forms/test/test_bug346043.html which is the one that "timed out" actually completed just fine - you can see the TEST-OK line in the full log, and the logcat output also shows it running to completion. So the problem isn't actually in the test itself. The logcat shows a lot of this output: SharedBufferStack: waitForCondition(LockCondition) timed out (identity=16, status=0). CPU may be pegged. trying again. and it seems to start right after layout/forms/test/test_bug345267.html starts. The other piece of relevant info I found was the ANR report (looking at [1] specifically) which shows the android main thread stuck in GLController.syncResumeResizeCompositor in Java-land. That function is a native function and if you look at the C++ stack traces below, you can see that the function is blocked waiting on the compositor thread (thread 31). The Gecko main thread (thread 10) is also blocked waiting on the compositor thread. The compositor thread is somewhere in the bowels of Android SurfaceFlinger code, doing who knows waht. So it seems to me that there's some interaction between tests that causes a deadlock or infinite loop in the compositor thread, and that's causing this problem. If you want you can disable test_tap and test_basic_pan on Android for now, if it helps. Those tests are running on Linux as well so we still have some coverage for them. I'll try to reproduce this locally but don't have a lot of cycles right now so it may be a week or two before I get to it. [1] http://archive.mozilla.org/pub/mobile/try-builds/jmaher@mozilla.com-c2982ac8fa7dbbc39c882e429c3d1c0e2fdff16e/try-android-api-9/try_ubuntu64_vm_mobile_test-mochitest-14-bm113-tests1-linux64-build87.txt.gz
Flags: needinfo?(bugmail.mozilla)
Assignee | ||
Comment 47•8 years ago
|
||
Thanks :kats. That is a much more logical explanation here. :gbrown, what are your thoughts here in terms of android coverage? I would be fine with disabling, and getting this split out- I would want to make sure we all can remember to look into this and try to fix it. Maybe you have other factors to consider.
Flags: needinfo?(gbrown)
Comment 48•8 years ago
|
||
Looking through the other M-14 failures on that try push, a bunch of them have the compositor thread in a SwapBuffers call rather than a MakeCurrent call, so most likely this is not a deadlock. It's still hanging somewhere in the SurfaceFlinger code though. The last of the M-14 failures (at [1]) is different in that it is actually timing out inside test_bug345267.html - we see the test start but not execute any of the assertions inside the test. Looking at the test I don't see anything out of the ordinary there, certainly no reason it should be hanging. The output in the logcat looks a little fishy (see [2] starting at the 19:28:04.449 timestamp). Based on the timestamps it looks like fennec is dying/being killed pretty much right after the test starts, so it's the crash causing the failure rather than a timeout causing the crash. The crash stack points again to something in surface flinger. [1] https://treeherder.mozilla.org/logviewer.html#?job_id=17137880&repo=try [2] http://mozilla-releng-blobs.s3.amazonaws.com/blobs/try/sha512/464b43c07052ce033d7b1450050f7c1fe073512b9f10e22583e05cbcf322651652ea150909cfdfefaeb2e55d2ba88246e6dabc7e197f1f0fb7e29b81924c2bbf
Comment 49•8 years ago
|
||
Some of :kats remarks bring to mind bug 1025968, which remains open and only affects Android 2.3. I suggest disabling these tests only on Android 2.3. Once Gingerbread support is dropped, we won't even notice!
Flags: needinfo?(gbrown)
Comment 51•8 years ago
|
||
marking as fixed since this landed on m-c (and the integration trees)
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment 52•8 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/bf7f47ae7e0f
Assignee | ||
Comment 53•8 years ago
|
||
backed out releng bits: https://hg.mozilla.org/build/buildbot-configs/rev/db2228175e4b
Comment 54•8 years ago
|
||
Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/4142e6d622f8
Assignee | ||
Comment 55•8 years ago
|
||
updated patch to have --cfg specified!
Attachment #8721445 -
Attachment is obsolete: true
Attachment #8725705 -
Flags: review?(kmoir)
Assignee | ||
Comment 56•8 years ago
|
||
Comment on attachment 8725705 [details] [diff] [review] buildbot patch for dom/media subsuite cancelling the review for now, I need to look deeper into android before asking for review.
Attachment #8725705 -
Flags: review?(kmoir)
Assignee | ||
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 57•8 years ago
|
||
ok, this has all the android changes as well!
Attachment #8725705 -
Attachment is obsolete: true
Attachment #8725867 -
Flags: review?(kmoir)
Assignee | ||
Comment 58•8 years ago
|
||
and the differences, this shows the two chunks on android as well!
Attachment #8721447 -
Attachment is obsolete: true
Updated•8 years ago
|
Attachment #8725867 -
Flags: review?(kmoir) → review+
Comment 61•8 years ago
|
||
Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/e5d1a341c37a
Comment 62•8 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/ad171d57880d
Comment 63•8 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/f0acc9241544
Backed out for real in https://hg.mozilla.org/mozilla-central/rev/5a2e0878d6c2 and cherry-picked that to inbound/fx-team.
Comment 65•8 years ago
|
||
Backout: https://hg.mozilla.org/integration/fx-team/rev/269d8cec9a9b
Comment 66•8 years ago
|
||
Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/2dfd64d1fc70
Assignee | ||
Comment 67•8 years ago
|
||
with 2 failed attempts, I need to figure out how to get this turned on for try and hidden by default there- then I can iterate as needed without causing emergencies for reconfigs, etc.
Reporter | ||
Comment 68•8 years ago
|
||
I believe one of the disposable repos will be better suited.
Assignee | ||
Comment 69•8 years ago
|
||
do we know which repos are used for what? I am fine with that vs try. Why would try not be a better choice? My thoughts were to enable it and hide all jobs by default- maybe they would get scheduled as failures?
Reporter | ||
Comment 70•8 years ago
|
||
From looking at the patch it seems that you're only adding new builders. I get confused as to why the buildbot-configs change has got backed out instead of the builders getting hidden. 'try' might just be fine. I was worried it would affect other people's try pushes. Could you also remove loopbackAudio from the tasks unless it is actually required? (I recently removed it from all of our fx tasks since it was not needed).
Assignee | ||
Comment 71•8 years ago
|
||
and the list of builders: Builders added: + Android 4.3 armv7 API 15+ try debug test mochitest-media-1 + Android 4.3 armv7 API 15+ try debug test mochitest-media-2 + Android 4.3 armv7 API 15+ try opt test mochitest-media-1 + Android 4.3 armv7 API 15+ try opt test mochitest-media-2 + Android armv7 API 9 try opt test mochitest-media-1 + Android armv7 API 9 try opt test mochitest-media-2 + Rev4 MacOSX Snow Leopard 10.6 try debug test mochitest-media + Rev4 MacOSX Snow Leopard 10.6 try opt test mochitest-media + Rev7 MacOSX Yosemite 10.10.5 try debug test mochitest-media + Rev7 MacOSX Yosemite 10.10.5 try opt test mochitest-media + Ubuntu ASAN VM 12.04 x64 try opt test mochitest-media + Ubuntu ASAN VM 12.04 x64 try opt test mochitest-media-e10s + Ubuntu Code Coverage VM 12.04 x64 try opt test mochitest-media + Ubuntu TSAN VM 12.04 x64 try opt test mochitest-media + Ubuntu VM 12.04 try debug test mochitest-media + Ubuntu VM 12.04 try debug test mochitest-media-e10s + Ubuntu VM 12.04 try opt test mochitest-media + Ubuntu VM 12.04 try opt test mochitest-media-e10s + Ubuntu VM 12.04 x64 try debug test mochitest-media + Ubuntu VM 12.04 x64 try debug test mochitest-media-e10s + Ubuntu VM 12.04 x64 try opt test mochitest-media + Ubuntu VM 12.04 x64 try opt test mochitest-media-e10s + Windows 10 64-bit try debug test mochitest-media + Windows 10 64-bit try opt test mochitest-media + Windows 7 32-bit try debug test mochitest-media + Windows 7 32-bit try opt test mochitest-media + Windows 8 64-bit try debug test mochitest-media + Windows 8 64-bit try opt test mochitest-media + Windows XP 32-bit try debug test mochitest-media + Windows XP 32-bit try opt test mochitest-media
Attachment #8725867 -
Attachment is obsolete: true
Attachment #8725868 -
Attachment is obsolete: true
Attachment #8728084 -
Flags: review?(armenzg)
Reporter | ||
Comment 72•8 years ago
|
||
Comment on attachment 8728084 [details] [diff] [review] add 'mda' jobs to try branch only Review of attachment 8728084 [details] [diff] [review]: ----------------------------------------------------------------- I only see the e10s jobs being added to the Linux platforms. If that is intentional, r=me
Attachment #8728084 -
Flags: review?(armenzg) → review+
Assignee | ||
Comment 73•8 years ago
|
||
Builders added: + Android 4.3 armv7 API 15+ try debug test mochitest-media-1 + Android 4.3 armv7 API 15+ try debug test mochitest-media-2 + Android 4.3 armv7 API 15+ try opt test mochitest-media-1 + Android 4.3 armv7 API 15+ try opt test mochitest-media-2 + Android armv7 API 9 try opt test mochitest-media-1 + Android armv7 API 9 try opt test mochitest-media-2 + Rev4 MacOSX Snow Leopard 10.6 try debug test mochitest-media + Rev4 MacOSX Snow Leopard 10.6 try opt test mochitest-media + Rev7 MacOSX Yosemite 10.10.5 try debug test mochitest-media + Rev7 MacOSX Yosemite 10.10.5 try opt test mochitest-media + Rev7 MacOSX Yosemite 10.10.5 try opt test mochitest-media-e10s + Ubuntu ASAN VM 12.04 x64 try opt test mochitest-media + Ubuntu ASAN VM 12.04 x64 try opt test mochitest-media-e10s + Ubuntu Code Coverage VM 12.04 x64 try opt test mochitest-media + Ubuntu TSAN VM 12.04 x64 try opt test mochitest-media + Ubuntu VM 12.04 try debug test mochitest-media + Ubuntu VM 12.04 try debug test mochitest-media-e10s + Ubuntu VM 12.04 try opt test mochitest-media + Ubuntu VM 12.04 try opt test mochitest-media-e10s + Ubuntu VM 12.04 x64 try debug test mochitest-media + Ubuntu VM 12.04 x64 try debug test mochitest-media-e10s + Ubuntu VM 12.04 x64 try opt test mochitest-media + Ubuntu VM 12.04 x64 try opt test mochitest-media-e10s + Windows 10 64-bit try debug test mochitest-media + Windows 10 64-bit try opt test mochitest-media + Windows 7 32-bit try debug test mochitest-media + Windows 7 32-bit try opt test mochitest-media + Windows 7 32-bit try opt test mochitest-media-e10s + Windows 8 64-bit try debug test mochitest-media + Windows 8 64-bit try opt test mochitest-media + Windows XP 32-bit try debug test mochitest-media + Windows XP 32-bit try opt test mochitest-media e10s is for osx 10.10 opt and win7 opt- matching the configs on trunk.
Attachment #8728084 -
Attachment is obsolete: true
Attachment #8728095 -
Flags: review?(armenzg)
Reporter | ||
Comment 74•8 years ago
|
||
Comment on attachment 8728095 [details] [diff] [review] buildbot patch for dom/media subsuite on try only The interdiff [1] adds 'slave_platform in ('win7-ix', 'win7-all', 'yosemite_r7')' to the condition which adds these builders: + Rev7 MacOSX Yosemite 10.10.5 try opt test mochitest-media-e10s + Windows 7 32-bit try opt test mochitest-media-e10s Good luck! [1] https://bugzilla.mozilla.org/attachment.cgi?oldid=8728084&action=interdiff&newid=8728095&headers=1
Attachment #8728095 -
Flags: review?(armenzg) → review+
Assignee | ||
Comment 75•8 years ago
|
||
buildbot changes for the try only jobs: https://hg.mozilla.org/build/buildbot-configs/rev/dd518a784a46 no rush on a buildbot reconfig, but when it happens, I will hide the jobs in treeherder for the try branch
Comment 76•8 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/dd518a784a46
Assignee | ||
Comment 77•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown Review request updated; see interdiff: https://reviewboard.mozilla.org/r/33681/diff/3-4/
Attachment #8716018 -
Attachment description: MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?armenzg → MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown
Attachment #8716018 -
Flags: review?(gbrown)
Assignee | ||
Comment 78•8 years ago
|
||
:gbrown, if you look at the interdiff you can see the main changes since the last r+ (a few we chatted about on irc). There are a handful of changes which are rebase related (the .ini files for example).
Comment 79•8 years ago
|
||
Comment on attachment 8716018 [details] MozReview Request: Bug 1242682 - Separate dom/media into its own subsuite. r?gbrown https://reviewboard.mozilla.org/r/33681/#review35953
Attachment #8716018 -
Flags: review?(gbrown) → review+
Assignee | ||
Comment 80•8 years ago
|
||
now that this has been on try and I have green jobs for all platforms/configs, I want to try this again!
Attachment #8729162 -
Flags: review?(kmoir)
Updated•8 years ago
|
Attachment #8729162 -
Flags: review?(kmoir) → review+
Comment 82•8 years ago
|
||
In production: https://hg.mozilla.org/build/buildbot-configs/rev/cc9e268a0036
Assignee | ||
Comment 83•8 years ago
|
||
this is live and appears to be running reliably on all platforms. Going to mark this as resolved despite a few instance types remaining to complete :)
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•