W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2017

Re: |wpt| command has now landed

From: Philip Jägenstedt <foolip@google.com>
Date: Mon, 31 Jul 2017 09:55:18 +0000
Message-ID: <CAARdPYcNT86q5qoTM79z0xtvoOzkEVZ9zPCTvaBxUc3AvOU9tQ@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>, James Graham <james@hoppipolla.co.uk>
Cc: "public-test-infra@w3.org" <public-test-infra@w3.org>
Awesome indeed, in particular doing less work in CI.

On Thu, Jul 27, 2017 at 9:04 PM Rick Byers <rbyers@chromium.org> wrote:

> Sounds awesome, thanks James!
> I see this is all now captured in the README
> <https://github.com/w3c/web-platform-tests/blob/master/README.md#command-line-tools>
> too, perfect!
> On Thu, Jul 27, 2017 at 1:23 PM, James Graham <james@hoppipolla.co.uk>
> wrote:
>> The wpt command has landed in web-platform-tests. This is a generic
>> command dispatch framework that's intended as a frontend to a lot of useful
>> tools for working with wpt. So, for example
>> ./wpt run firefox dom/historical.html
>> will run the given test in a local copy of firefox (note: this replaces
>> the |wptrun| command, although that is still present for legacy cpmpat
>> reasons).
>> Similarly
>> ./wpt check-stability chrome dom/historical.html
>> will run the test 10x in chrome and check for consistent results; much
>> like the job on travis.
>> The "serve", "manifest" and "lint" commands are now available through wpt
>> i.e.
>> ./wpt serve
>> ./wpt manifest
>> ./wpt lint
>> In addition we also have commands for installing browser/webdriver
>> binaries (wpt install), checking which files are affected by the current
>> branch (wpt files-affected), checking which tests are affected by changes
>> to the current branch (wpt tests-affected) and checking which test jobs
>> should run for the current branch (wpt test-jobs).
>> The last command is notable because it is part of some work I have done
>> to speed up our CI infrastructure; travis now aborts early for jobs that
>> shouldn't be relevant to a given PR (e.g. unittests for tools on a test
>> change); canceled jobs take about 30s (and there is probably some room for
>> improvement here, although unfortunately travis doesn't yet allow us to
>> avoid scheduling jobs entirely when we know they won't be necessary).
>> In addition we are now caching the wpt manifest on travis, and there is a
>> PR in flight to cache the output of the lint. I'm hopeful this will cause a
>> significant improvement in the end to end time for a typical PR. Of course
>> this won't help changes that require stability checking of slow-running
>> tests. It is less clear how to make improvements in that case.
Received on Monday, 31 July 2017 09:55:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:13 UTC