We recently enabled metro mochitests on try, inbound, and mc. However when you push a patch to try with '-u mochitests', these tests don't run. Instead you have to run all tests which is a waste of resources. I'd like to request metro mochitests be included with mochitest test try runs. -u mochitests https://tbpl.mozilla.org/?tree=Try&showall=1&rev=a361e7b8bc26 -u all https://tbpl.mozilla.org/?tree=Try&showall=1&rev=94a861c12278

If you use showall=1 you should be able to see it: https://tbpl.mozilla.org/?tree=Try&showall=1&rev=94a861c12278 I think you should also be able to get it with this: try: -b o -p win32 -u metro-immersive -t none You would need to use showall=1 as well. Does this work for you?

(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #1) > If you use showall=1 you should be able to see it: > https://tbpl.mozilla.org/?tree=Try&showall=1&rev=94a861c12278 That's a '-u all' run. With a '-u mochitest' run, it doesn't trigger: https://tbpl.mozilla.org/?tree=Try&showall=1&rev=a361e7b8bc26 > I think you should also be able to get it with this: > try: -b o -p win32 -u metro-immersive -t none Haven't tried that but will, if it works it will be handy to have.

Yeah, I would have said that the core of this bug was two things, "add metro-immersive to trychooser" and "add metro-immersive to http://mxr.mozilla.org/build/source/buildbotcustom/try_parser.py#16" But, if it actually is mochitest-metro, why is it named metro-immersive?

jimm, according to what philor says, should we name the job "mochitest-metro"? would that be more appropriate?

(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #5) > jimm, according to what philor says, should we name the job > "mochitest-metro"? would that be more appropriate? How about mochitest-browser-chrome to match desktop?

(In reply to Jim Mathies [:jimm] from comment #6) > (In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment > #5) > > jimm, according to what philor says, should we name the job > > "mochitest-metro"? would that be more appropriate? > > How about mochitest-browser-chrome to match desktop? We already have that named being used. We can't use the same name... I think.

(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #7) > (In reply to Jim Mathies [:jimm] from comment #6) > > (In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment > > #5) > > > jimm, according to what philor says, should we name the job > > > "mochitest-metro"? would that be more appropriate? > > > > How about mochitest-browser-chrome to match desktop? > > We already have that named being used. We can't use the same name... I think. Doh, I meant mochitest-metro-chrome! :)

Comment on attachment 761493 [details] [diff] [review] [mozharness] rename metro jobs jimm, we would still be calling it with --browser --metro-immersive, correct?

(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #12) > Comment on attachment 761493 [details] [diff] [review] > [mozharness] rename metro jobs > > jimm, we would still be calling it with --browser --metro-immersive, correct? Right. The metro-immersive monicker is a little misleading I know. At one point we had support for running these on the desktop, which would have been metro-desktop, but we took that out a while back. 'metro-immersive' stuck around.

This is working on staging.

Comment on attachment 761492 [details] [diff] [review] [trychooser] add metro jobs lgtm - I tried to come up with some reason for the "mochitest-o" thing to exist, and thus a reason why this ought to be mochitest-mc, but I couldn't come up with anything other than "maybe we used to have narrow columns."

Comment on attachment 761492 [details] [diff] [review] [trychooser] add metro jobs https://hg.mozilla.org/build/tools/rev/db1d47944f57

r=coop

please let us know when this goes live so we can swap out the new try server directive we've been using.

This is live now. I will close it as soon as I see them running. TryChooser has also been updated. [root@relengweb1.dmz.scl3 tools]# hg id c92f9eb6f601 tip [root@relengweb1.dmz.scl3 tools]# hg pull -u && hg up -C && hg id pulling from http://hg.mozilla.org/build/tools searching for changes adding changesets adding manifests adding file changes added 21 changesets with 33 changes to 21 files 21 files updated, 0 files merged, 0 files removed, 0 files unresolved 0 files updated, 0 files merged, 0 files removed, 0 files unresolved db1d47944f57 tip

I *just* merged the changes from default to production on mozharness. Those jobs that happened before this are going to appear green but did not actually run anything. https://tbpl.mozilla.org/?tree=Mozilla-Inbound&showall=1&jobname=metro We can see a passing opt job: https://tbpl.mozilla.org/php/getParsedLog.php?id=24108037&tree=Mozilla-Inbound&full=1

A bunch of timeouts on the debug jobs: https://tbpl.mozilla.org/php/getParsedLog.php?id=24108378&tree=Mozilla-Inbound&full=1 https://tbpl.mozilla.org/?tree=Mozilla-Inbound&showall=1&jobname=debug.*metro

Could you please let us know when this change goes live? (I can't find releng instructions on how to do so). https://hg.mozilla.org/webtools/tbpl/rev/c60dada1c549 Thanks!

(In reply to Armen Zambrano G. [:armenzg] (back in July 7th) from comment #23) > Could you please let us know when this change goes live? (I can't find > releng instructions on how to do so). > https://hg.mozilla.org/webtools/tbpl/rev/c60dada1c549 > > Thanks! Will do a prod push now (preferred option is to ask me to do a prod push to ensure staged but not ready changes don't get pushed along with the rest, but in an emergency webops can do it). Which wiki pages should I update with instructions?