<br><div class="gmail_quote">On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi all,</div><div><br></div><div>I've made a change to NRWT in <a href="http://trac.webkit.org/changeset/146657" target="_blank">http://trac.webkit.org/changeset/146657</a> so that it always generate pixel results in retries even when pixel tests are disabled by default (on all but Chromium ports).</div>
<div><br></div><div>We now enable pixel tests while we're retrying tests and generate -expected.png results.</div><div><br></div><div>This change has two important implications:</div><div><ul><li>We can now grab -expected.png results from <a href="http://build.webkit.org" target="_blank">build.webkit.org</a> builders for those tests that have resulted in non-image-only failures.</li>
<li>Chromium and Mac EWS bots will now upload ZIP archives with those images (recall <a href="http://trac.webkit.org/changeset/146443" target="_blank">http://trac.webkit.org/changeset/146443</a>)</li></ul></div><div>This will allow us to rebaseline BOTH test and image expected results PRIOR to landing patches.</div>
</blockquote><div><br></div><div>Now that layout-test-results are being attached to their related bugs, I wonder if there is a way to delete these attachments (in BZ) so as not to choke disk space on the BZ server. Otherwise, I have a feeling disk usage will increase rapidly.</div>
<div><br></div><div>For example, after one has reviewed and extracted the useful results from the attachments, it would be useful to delete (and not just make obsolete) those (large) attachments. I also notice that when an EWS has multiple fails on the same patch, that multiple layout-test-results get attached.</div>
<div><br></div><div>It might also be useful to have a cron job on the BZ server go through and delete obsoleted layout-test-result attachments (in case it is not straightforward to permit attachment deletion). At least, then the dev could obsolete result attachments after extracting the useful data and the cron job could do the rest of the work of deleting the attachments.</div>
</div>