Bug 52617

Summary: commit-queue dies when test archiving fails
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: New BugsAssignee: Eric Seidel (no email) <eric>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, commit-queue, eric, levin, ojan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Attachments:
Description Flags
Patch none

Description Eric Seidel (no email) 2011-01-18 03:25:39 PST
commit-queue dies when test archiving fails
Comment 1 Eric Seidel (no email) 2011-01-18 03:46:13 PST
Created attachment 79257 [details]
Patch
Comment 2 Eric Seidel (no email) 2011-01-18 03:49:03 PST
This is why we currently have 3 patches stuck in the cq.  I could land this w/o review, but I figured it would be good for others to see (and there is little rush, the cq will right itself as soon as this lands).
Comment 3 Adam Barth 2011-01-18 14:26:44 PST
Comment on attachment 79257 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=79257&action=review

> Tools/ChangeLog:9
> +        I looked at the machine and it had 10 archives already
> +        thus find_unused_name was returning None.  I've upped

Does that mean it will have 100 soon?  Are we not cleaning out the files?
Comment 4 WebKit Commit Bot 2011-01-18 14:55:47 PST
The commit-queue encountered the following flaky tests while processing attachment 79257 [details]:

animations/dynamic-stylesheet-loading.html bug 52669 (author: cmarrin@apple.com)
The commit-queue is continuing to process your patch.
Comment 5 WebKit Commit Bot 2011-01-18 14:59:59 PST
Comment on attachment 79257 [details]
Patch

Clearing flags on attachment: 79257

Committed r76071: <http://trac.webkit.org/changeset/76071>
Comment 6 WebKit Commit Bot 2011-01-18 15:00:04 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Eric Seidel (no email) 2011-01-18 15:23:30 PST
(In reply to comment #3)
> (From update of attachment 79257 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=79257&action=review
> 
> > Tools/ChangeLog:9
> > +        I looked at the machine and it had 10 archives already
> > +        thus find_unused_name was returning None.  I've upped
> 
> Does that mean it will have 100 soon?  Are we not cleaning out the files?

Yup.  I've learned more about this bug.

Seems we save the archives after any failure, and if the bots are red, we'll just keep saving the archives until we hit the limit. :)

So perhaps I should drop the limit back to 10 (and make it explicit in the archiving code, not just implicit in the workspace code).

I also might want to consider not saving another copy of the archives if an identical one already exists?  Or just purge ones if we don't see flaky tests?