web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
4.8k stars 2.99k forks source link

Rewrite manifest include/exclude support #15912

Open gsnedders opened 5 years ago

gsnedders commented 5 years ago

Currently, wpt run's --include and --exclude are processed within wptrunner by wptrunner.manifestinclude (via wptrunner.testloader.TestFilter); this essentially implements inclusion/exclusion based on a trie where the longest prefix wins (i.e., if you exclude "/" and include "/foobar/", "/foobar/*" is included as a longer prefix).

--include and --exclude are a bit weird insofar as they sorta support paths and sorta support URLs. Essentially, I believe the goal here is to support scheme-less and host-less URLs and path(-ish) things.

I think what we want to do is convert the string to an absolute (filesystem) path and see if that's within the manifest's tests_root, otherwise treat it as a URL.

Then:

Note that we currently support wildcards when the arguments are filesystem paths; we should at least support that for the final path element (given some directories have thousands of tests in them, especially in CSS), but is it worthwhile supporting them in the entire path (though it complicates walking the trie), for example so you can do webrtc*?

The ultimate goal here is to integrate the include/exclude support closer with the manifest and therefore avoid having to create all the items before filtering in the common case.

jgraham commented 5 years ago

I think this sounds sensible. Generic wildards seem like they come at substantial cost and the only use case for generic wildcards not expanded by the shell would be where there is a URL/path mismatch like webrtc/*.worker.any.html. Which seems possibly useful but probably requires a slow path working like today's path where we construct everything in order to match against it.

gsnedders commented 5 years ago

By "generic wildcards" do you mean anywhere in the path, or even on the final path component? Because there's still a substantial cost regardless of how we implement wildcards, though I do think they're useful.

gsnedders commented 4 years ago

This should now be much more achievable with the new manifest version.

From my memory of looking into this, given the level at which the filtering is applied, wptrunner.testloader applies it over a group of manifests (rather than just one), so we probably want to move some degree of support of "manifest sets" or something into manifest, and then have the ability to do the filtering both there and of individual manifests.

gsnedders commented 4 years ago

https://github.com/web-platform-tests/wpt/compare/manifest-include-exclude is a very early start here, though that branch also contains a very early version of the current manifest version which is outdated. The SkipNode class may be of some help here, though.