Error message from ci_resources_unittest.sh when /etc/hosts is wrong is not very useful

[bzbarsky]

It just says:

Exception: Could not start wptserve on http://web-platform.test:8000

By contrast, running wpt serve directly gives:

CRITICAL:web-platform-tests:Failed probing domain www1.xn--n8j6ds53lwwkrqhv28a.web-platform.test. Please ensure all the necessary WPT subdomains are mapped to a loopback device in /etc/hosts. See https://github.com/web-platform-tests/wpt#running-the-tests for instructions.

which has the right problem pointed out as well as a place to start fixing it.

Can we get the former to say something more like the latter, or at least not hide that error from the wpt serve it runs internally?

@stephenmcgruer @jgraham

[stephenmcgruer]

So the code is in resources/test/wptserver.py:

        logging.info('Executing %s' % ' '.join(wptserve_cmd))
        self.proc = subprocess.Popen(
            wptserve_cmd,
            stderr=self.devnull,
            cwd=self.wpt_root)

        for retry in range(5):
            # Exponential backoff.
            time.sleep(2 ** retry)
            exit_code = self.proc.poll()
            if exit_code != None:
                logging.warn('Command "%s" exited with %s', ' '.join(wptserve_cmd), exit_code)
                break
            try:
                urllib.request.urlopen(self.base_url, timeout=1)
                return
            except urllib.error.URLError:
                pass

        raise Exception('Could not start wptserve on %s' % self.base_url)

So it currently explicitly sends stderr to /dev/null, probably because wpt serve spews a lot of stuff when it runs.

I wonder if the correct fix might be to give wpt serve a log-level flag, and then set it to ERROR/CRITICAL for this code. (Most of the spam from wpt serve is DEBUG/INFO). Alternatively, we could capture stderr rather than pipe it to /dev/null, and then report it if the program fails to start.