Open Bug 1768092 Opened 5 months ago Updated 5 months ago

Local run of `mach raptor -t sunspider` fails

Categories

(Testing :: Raptor, defect, P2)

Default
defect

Tracking

(Not tracked)

People

(Reporter: sfink, Unassigned)

References

Details

How do you run a raptor test locally? When I do mach raptor -t sunspider, for example, it fails with CRITICAL - raptor-perftest Critical: Failed to run sunspider: NetworkError when attempting to fetch resource.. This is preceded by many error messages saying raptor-control-server Info: received request for unknown file: /json/sunspider.json.

There are two problems with that: first, why is it trying to fetch that file from the control server instead of the content server or whatever it's called? Second, even if I try manually making an HTTP request to the content server, it fails because it looks for $objdir/testing/raptor/benchmarks/json/sunspider.json which does not exist. The relevant file appears to be $srcdir/testing/raptor/raptor/tests/json/sunspider.json.

I will note that while raptor is running (stalled in a pdb prompt, actually), $srcdir/testing/raptor/webext/raptor/auto_gen_test_config.js contains:

// this file is auto-generated by raptor, do not edit directly
function getTestConfig() {
  return {
    "cs_port": "56091",
    "test_name": "sunspider",
    "test_settings_url": "http://127.0.0.1:56091/json/sunspider.json",
    "post_startup_delay": "30000",
    "benchmark_port": "35091",
    "host": "127.0.0.1",
    "debug_mode": "0",
    "browser_cycle": "1"
  };
}

Those port numbers are correct; 56091 does seem to be the control port, and I can get content back from port 35091 if I do symlink tricks to put the data where it's looking.

Anyway, STR:

  • make a local build
  • run mach raptor -t sunspider

Hm, maybe that is supposed to be coming from the control server? I just noticed the test_settings_url, which has the control port in it. So perhaps the control server isn't serving from the right place? But I got to here because do_GET() in control_server.py insists:

            if tail.startswith("raptor") and tail.endswith(".json"):

and "sunspider.json" does not start with "raptor". It looks like it wants something like "/raptor/sunspider.json" that it'll turn into "json/sunspider.json"? So confused.

I don't know how that would work given gen_test_config.py has:

    "test_settings_url": "http://{host}:{control_server_port}/json/{test}.json",

No "raptor" in sight.

It all works if I remove the tail.startswith("raptor") clause.

Blocks: dev-pain
Severity: -- → S3
Priority: -- → P2

:sfink, can you try this command: ./mach raptor -t sunspider --browsertime

I think the issue here is that raptor thinks you want to run the test through the webextension but that is no longer supported for the most part.

Flags: needinfo?(sphink)

I've got a patch here to deal with this issue: https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=513d08c4a2b7cbf514019a635a6cf3acdce4e6e5

We should be running browsertime by default now and not the webextension.

(In reply to Greg Mierzwinski [:sparky] from comment #4)

:sfink, can you try this command: ./mach raptor -t sunspider --browsertime

I think the issue here is that raptor thinks you want to run the test through the webextension but that is no longer supported for the most part.

That's what I ended up doing. I naively thought that I should start with the seemingly most basic form of the command, but for what I want to do, I need --browsertime anyway.

Should the webext mechanism be removed, or at least the local run portion of it? Or fail unless you pass --yes-i-know-its-deprecated-run-it-anyway?

Ah, it looks like it's still used for a few tests.

Flags: needinfo?(sphink)
Depends on: 1768204
No longer blocks: dev-pain

(In reply to Steve Fink [:sfink] [:s:] from comment #6)

(In reply to Greg Mierzwinski [:sparky] from comment #4)

:sfink, can you try this command: ./mach raptor -t sunspider --browsertime

I think the issue here is that raptor thinks you want to run the test through the webextension but that is no longer supported for the most part.

That's what I ended up doing. I naively thought that I should start with the seemingly most basic form of the command, but for what I want to do, I need --browsertime anyway.

Should the webext mechanism be removed, or at least the local run portion of it? Or fail unless you pass --yes-i-know-its-deprecated-run-it-anyway?

As you noticed, there are still some tests which use it unfortunately. There's still a couple outstanding issues we need to work out before we can turn off or port those tests. I've made a patch that resolves the issue for me locally but we'll likely have some discussions before going further with it. It's possible that we get rid of those cpu/memory/power tests in the very near future allowing us to make a patch to fully disable webext.

You need to log in before you can comment on or make changes to this bug.