Bug 37898 – REGRESSION(r57924): It broke 3-4 test on all bot (Requested by Ossy on #webkit).

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[WebKit Review Bot]

http://trac.webkit.org/changeset/57924 broke the build:
It broke 3-4 test on all bot (Requested by Ossy on #webkit).

This is an automatic bug report generated by the sheriff-bot. If this bug
report was created because of a flaky test, please file a bug for the flaky
test (if we don't already have one on file) and dup this bug against that bug
so that we can track how often these flaky tests case pain.

"Only you can prevent forest fires." -- Smokey the Bear

[WebKit Review Bot]

Created attachment 53898 [details]
ROLLOUT of r57924

Any committer can land this patch automatically by marking it commit-queue+.  The commit-queue will build and test the patch before landing to ensure that the rollout will be successful.  This process takes approximately 15 minutes.

If you would like to land the rollout faster, you can use the following command:

  webkit-patch land-attachment ATTACHMENT_ID --ignore-builders

where ATTACHMENT_ID is the ID of this attachment.

[Adam Barth]

Insert nastygram about not running the tests before committing...

[Csaba Osztrogonác]

Leopard, SL: http://build.webkit.org/results/Leopard%20Intel%20Release%20%28Tests%29/r57928%20%2813367%29/results.html

Qt: http://build.webkit.org/results/Qt%20Linux%20Release/r57932%20%2810428%29/results.html

Tiger and other work.

rollout landed in: https://bugs.webkit.org/attachment.cgi?id=53898

[Kenneth Rohde Christiansen]

(In reply to comment #3)
> Leopard, SL:
> http://build.webkit.org/results/Leopard%20Intel%20Release%20%28Tests%29/r57928%20%2813367%29/results.html
> 
> Qt:
> http://build.webkit.org/results/Qt%20Linux%20Release/r57932%20%2810428%29/results.html
> 
> Tiger and other work.
> 
> rollout landed in: https://bugs.webkit.org/attachment.cgi?id=53898

Thanks Ossy, I will fix those tests thursday.

It is so sad that I cannot just run all our tests locally and trust the result, currently I get tons of failures, hiding the real errors.

[Kenneth Rohde Christiansen]

(In reply to comment #2)
> Insert nastygram about not running the tests before committing...

I did do that actually, but as I currently get tons of failures locally due to font differences, I had to try to isolate the failures manually.

[Kenneth Rohde Christiansen]

(In reply to comment #5)
> (In reply to comment #2)
> > Insert nastygram about not running the tests before committing...
> 
> I did do that actually, but as I currently get tons of failures locally due to
> font differences, I had to try to isolate the failures manually.

I did that by grepped though all the tests for .media, and found the relevant ones. (.media is still used for MediaList, and thus some shouldn't be changed to styleMedia)

The failing tests were not catched by me as they are based on introspection. They are also all correct; the expected result just needs to be updated.

[Adam Barth]

> I did do that actually, but as I currently get tons of failures locally due to
> font differences, I had to try to isolate the failures manually.

Are you on Windows?  We need to fix our Windows testing story.  It might require rebaselining all those tests so that a normal human being can run the tests on Windows.

[Adam Barth]

BTW, another approach is to land via the commit-queue.  It will run all the tests for you if you're unsure.

[Kenneth Rohde Christiansen]

(In reply to comment #8)
> BTW, another approach is to land via the commit-queue.  It will run all the
> tests for you if you're unsure.

Basically what happened is that I found a test update that I missed and didn't wanted to bother the reviewer to review again for such a minimality, but I guess next time I can just upload a patch with the reviewer field already set and just cq+ it. Do you think that would be alright?

[Adam Barth]

> I guess next time I can just upload a patch with the reviewer field already
> set and just cq+ it. Do you think that would be alright?

Yeah, there's even a command to help you do that:

webkit-patch land-safely

You can run that command when you'd otherwise run "land", but it will upload the patch to the bug and land it through the commit queue.

[Kenneth Rohde Christiansen]

(In reply to comment #10)
> Yeah, there's even a command to help you do that:
> 
> webkit-patch land-safely
> 
> You can run that command when you'd otherwise run "land", but it will upload
> the patch to the bug and land it through the commit queue.

I really need to look more into that webkit-patch thing; that seems really useful.

[Kenneth Rohde Christiansen]

(In reply to comment #11)
> (In reply to comment #10)
> > Yeah, there's even a command to help you do that:
> > 
> > webkit-patch land-safely
> > 
> > You can run that command when you'd otherwise run "land", but it will upload
> > the patch to the bug and land it through the commit queue.
> 
> I really need to look more into that webkit-patch thing; that seems really
> useful.

Why doesn't webkit-patch help show that feature? also land-safely seems to only work with bugids.

[Adam Barth]

It's an experimental feature.  We have a lot of experimental features that you can look at with --all-commands.  It should work with a bug id on the command line or autodetecting the bug id from the change log.  It should also fill out the reviewer for you if the patch is r+ on the bug.

[Kenneth Rohde Christiansen]

Was rolled out and re-added later.