635357 - mochitest harness shouldn't hardcode port number

Status: RESOLVED DUPLICATE of bug 572572

(Testing :: Mochitest, defect)

Description

[[e-mail] (:bhearsum)]

In Tegra-land, we use a single host as a proxy for multiple devices. When running mochitests, this means that the HTTP server is started on the proxy host, and the device connects back to it. Because the Mochitest harness hardcodes a port number, we end up timing out when starting the server on a ton of jobs.

Is there any way to remove the hardcoding of the port number?

Comment 1

[Aki Sasaki (not active)]

Partially fixed by bug 544097 ?, partially exacerbated by bug 541117 ?

My conjecture, without really understanding, is that we replace mochi.test with 127.0.0.1 or a specified ip.  I would hope we could do the same thing with the port... and maybe we already can but don't know it.

Comment 2

[[e-mail] (:bhearsum)]

Aki points out that this is a dupe of bug 572572.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

actually this is implemented in a roundabout way.  First, if we are using a remote webserver (not serving to 127.0.0.1), we do not start the websocketserver, ssltunnel or the webserver from the normal scripts:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/runtests.py#440

In our remote version of the script we overload the startWebServer and we do launch a webserver on the host machine with a designated port (--http-port).  Technically we have --ssl-port as well, but that isn't used (there are other problems to solve first before supporting ssl remotely).

I believe :bear was going to start up the webserver using a port number scheme similar to --http-port=8xxx, where xxx is the tegra number (i.e. 017).  This is the only port we need for remote testing and it is configurable via the cli.

I think bug 572572 is designed to automatically detect an open port which would be smoother and probably required when we have ssl and websocket stuff fully working remotely and on mobile.