Closed Bug 1242682 Opened 8 years ago Closed 8 years ago

Separate dom/media into its own subsuite

Categories

(Testing :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: jmaher)

References

Details

Attachments

(3 files, 10 obsolete files)

58 bytes, text/x-review-board-request
armenzg
: review+
gbrown
: review+
Details
23.67 KB, patch
armenzg
: review+
Details | Diff | Splinter Review
4.13 KB, patch
kmoir
: review+
Details | Diff | Splinter Review
<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
: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)
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)
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.
Sounds good to me.  Also easier to know which tests to push in Try!
Flags: needinfo?(rjesup)
No longer blocks: tc-linux64-debug
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8716015 - Flags: review?(armenzg)
Attached file builder differences.txt (obsolete) —
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+
Attachment #8716018 - Flags: review?(armenzg) → review+
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!
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)
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.
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)
'mda' sounds good!
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)
Attached file builder differences.txt (obsolete) —
Attachment #8716016 - Attachment is obsolete: true
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/
:armen, I asked you for review again as I updated the patch for e10s and for android.
Flags: needinfo?(armenzg)
(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.
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)
Attachment #8716018 - Flags: review+
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.
Flags: needinfo?(armenzg)
(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!
Attachment #8716615 - Flags: review?(kmoir)
Attachment #8716018 - Flags: review?(armenzg)
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/
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)
Attached file builder differences.txt (obsolete) —
to go along with the buildbot patch :kmoir!
Attachment #8716616 - Attachment is obsolete: true
Attachment #8721445 - Flags: review?(kmoir) → review+
Attachment #8716018 - Flags: review?(armenzg) → review+
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.
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
(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
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)
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)
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)
Why is that test running on Android at all? 

There is a default skip-if for Android in dom/payment/tests/mochitest/mochitest.ini.
Oops, nevermind -- that's skip-if...toolkit != 'Android'. It looks like it should be running.
mozpayment tests are not needed on android, I am going to disable them for android.
Flags: needinfo?(ferjmoreno)
Flags: needinfo?(fabrice)
Depends on: 1250650
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)
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)
...some *tests* were re-ordered...
As Geoff alluded to, I have to believe that the failures are due to chunking boundary changes. Yay Android.
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.
(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
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.
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)
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)
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.
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)
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)
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)
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
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)
Depends on: 1252121
marking as fixed since this landed on m-c (and the integration trees)
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Depends on: 1252476
updated patch to have --cfg specified!
Attachment #8721445 - Attachment is obsolete: true
Attachment #8725705 - Flags: review?(kmoir)
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)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ok, this has all the android changes as well!
Attachment #8725705 - Attachment is obsolete: true
Attachment #8725867 - Flags: review?(kmoir)
Attached file buildbot differences differences.txt (obsolete) —
and the differences, this shows the two chunks on android as well!
Attachment #8721447 - Attachment is obsolete: true
Attachment #8725867 - Flags: review?(kmoir) → review+
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.
I believe one of the disposable repos will be better suited.
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?
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).
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)
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+
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)
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+
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 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)
: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 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+
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)
Attachment #8729162 - Flags: review?(kmoir) → review+
Depends on: 1255853
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 ago8 years ago
Resolution: --- → FIXED
Depends on: 1256343
You need to log in before you can comment on or make changes to this bug.