798238 - Diff from the "previous" log for codesighs broken by bug 561198

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Phil Ringnalda (:philor)]

Even though the concept of the "previous" log makes zero sense on try, where there's no way of knowing what that previous build was, and may or may not make sense, purely by happenstance, in the modern world where there's more than one slave doing builds for a platform, since the last build that uploaded a log may be from a later push which happened to finish earlier, we still do codesighs diffs, where we download the last uploaded log and tell codesighs to compare it to our log from the current build.

http://hg.mozilla.org/build/buildbotcustom/annotate/8c9b2da3088b/steps/test.py#l263 does that, by calling http://mxr.mozilla.org/mozilla-central/source/tools/codesighs/autosummary.unix.bash as "autosummary.unix.bash -o obj-firefox -s . ../codesize-auto.log ../codesize-auto-old.log ../codesize-auto-diff.log". autosummary.unix.bash shifts off the objdir and the srcdir, and then calls $1 COPYSORTTSV, $2 OLDTSVFILE, and $3 SUMMARYFILE.

Prior to bug 561198, we did "command=['wget', '-O', 'codesize-auto-old.log', '%s/codesize-auto.log' % self.logBaseUrl]" and so we had a file named codesize-auto-old.log, which was whatever happened to be the last uploaded codesize-auto.log.

In http://hg.mozilla.org/build/buildbotcustom/rev/49d4de28d17f#l1.97 for non-Try trees that changed to being "wget_unpack.sh self.logBaseUrl + ' codesize-auto.tar.gz '+'codesize-auto.log:codesize-auto.log.old'", which in a build log results in

Executing: ['wget', '-O', 'wget_unpack.tar.gz', 'http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux//codesize-auto.tar.gz']
Saving to: `wget_unpack.tar.gz'
codesize-auto.log
Got the packed files
mv ./codesize-auto.log ./codesize-auto.log.old

and so we have a file named codesize-auto.log.old and no file named codesize-auto-old.log, OLDTSVFILE does not exist, so we don't generate a diff.

Convenient in a way, since the diff is apparently the cause of it taking 20 or 30 minutes on try, where we still use the old code to fetch the uncompressed file and name it correctly, so that'll have to be fixed before we'll want to start having a correctly named file on non-Try.

Comment 1

[Phil Ringnalda (:philor)]

wontfix in favor of bug 798798 turning it off, and bug 668219 deleting it