New issue
Advanced search Search tips

Issue 654030 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 474273
issue 621599



Sign in to add a comment

Rebaselining may add new all-PASS baselines for testharness.js tests.

Project Member Reported by qyears...@chromium.org, Oct 7 2016

Issue description

For testharness.js tests where all tests pass, we don't keep baselines.

Currently, if a baseline (with some FAIL lines or console errors) exists for a testharness.js test, then a change is made which results in all test methods passing, then the baseline should be deleted, rather than updated to include only PASS lines.

The simplest fix for this may be to check new downloaded baselines after downloading them (maybe in rebaseline-test-internal?), and if they are all-pass testharness baselines, delete them.
 
Labels: -Pri-3 Pri-2
Components: Blink>Infra
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bb11a3670a64f56774881350f8f4b0035ba2eeb

commit 0bb11a3670a64f56774881350f8f4b0035ba2eeb
Author: qyearsley <qyearsley@chromium.org>
Date: Tue Oct 11 19:21:07 2016

When rebaselining testharness tests with new all-PASS results, remove the baseline.

For testharness.js tests where the result just contains PASS lines with no
console errors or warnings, our way of representing that is to have no baseline
(no -expected.txt file). So, when rebaselining, the proper "baseline" for tests
like this is to have no baseline.

Example case for how I think this might work: Let's imagine there's a
testharness test which fails on mac and linux, but passes on windows. The
existing baselines may be:

    LayoutTests/platform/mac/foo/bar-expected.txt
    LayoutTests/platform/linux/foo/bar-expected.txt

If we rebaseline and it now passes on linux, then I imagine
that the copy-existing-baselines baselines step would copy
linux/foo/bar-expected.txt to linux-precise/, and the
baselines in both linux/ and linux-precise/ would be deleted
on the rebaseline-test step. Then, we'd be left with just
LayoutTests/platform/mac/foo/bar-expected.txt.

Although I haven't really tested out this whole flow yet.

This CL also extracts a function import is_all_pass_testharness_result from
webkitpy.layout_tests.models.testharness_results to avoid duplicating code.

BUG= 654030 

Review-Url: https://codereview.chromium.org/2409903002
Cr-Commit-Position: refs/heads/master@{#424509}

[modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/check-testharness-expected-pass
[modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/models/testharness_results.py
[modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/models/testharness_results_unittest.py
[modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline.py
[modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_unittest.py

Status: Started (was: Assigned)
Now testing this out: http://crrev.com/2411173002
Status: Fixed (was: Started)
When I ran webkit-patch rebaseline-cl --only-changed-tests for a CL that changed a testharness test so that it was all-PASS, the baselines were deleted as expected.
Status: Started (was: Fixed)
In the latest runs of w3c-test-runner, it appears that there's a case where there's an old non-platform-specific non-all-PASS baseline, and rebaselining should remove it the generic baseline, but it is not being removed.

Specifically, for these tests:

  imported/wpt/custom-elements/reactions/Document.html
  imported/wpt/custom-elements/reactions/NamedNodeMap.html
  imported/wpt/html/semantics/embedded-content/media-elements/interfaces/TrackEvent/constructor.html

In try jobs for https://codereview.chromium.org/2442983002.
Project Member

Comment 7 by bugdroid1@chromium.org, Oct 25 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad

commit 8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad
Author: qyearsley <qyearsley@chromium.org>
Date: Tue Oct 25 21:13:40 2016

Remove all all-PASS testharness baselines after rebaselining.

In http://crrev.com/2409903002 I added logic to webkit-patch
rebaseline-test-internal so that when rebaselining particular tests,
all-PASS testharness.js test baselines would be removed.

Later, I discovered that if a generic non-all-PASS baseline already
exists, it won't be removed when rebaselining, so that approach
doesn't quite solve the problem.

In general, we don't want any all-PASS baselines for testharness.js,
so this CL takes a different approach: After rebaselining, enumerate
all relevant baselines, and remove any all-PASS testharness.js
baselines. Removing such a baseline should never be incorrect.

BUG= 654030 

Review-Url: https://codereview.chromium.org/2445963002
Cr-Commit-Position: refs/heads/master@{#427470}

[modify] https://crrev.com/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline.py
[modify] https://crrev.com/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_unittest.py

Status: Fixed (was: Started)

Sign in to add a comment