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
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.
Insert nastygram about not running the tests before committing...
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
(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.
(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.
(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.
> 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.
BTW, another approach is to land via the commit-queue. It will run all the tests for you if you're unsure.
(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?
> 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.
(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.
(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.
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.
Was rolled out and re-added later.