Last Comment Bug 846425 - Compare builds for moz.build switchover regressions
: Compare builds for moz.build switchover regressions
Status: NEW
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 784841 847369 851975
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-28 11:46 PST by Gregory Szorc [:gps]
Modified: 2013-03-23 03:07 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Gregory Szorc [:gps] 2013-02-28 11:46:33 PST
As part of switching to moz.build files, there is the possibility there were errors in the largely mechanical conversion of Makefile.in data to moz.build data.

We should compare a before and after run on TBPL and look for any obvious discrepancies.

Before builds:

https://tbpl.mozilla.org/?rev=1f56495eaa56
https://tbpl.mozilla.org/?rev=b0e08db3bc2a

After build:

https://tbpl.mozilla.org/?rev=c65d59d33aa8

I think a good proxy for "did the build change" is to look at the number of tests run. If there is a difference, we might have accidentally dropped or added a directory.

Over time, I'd like a better way to perform this analysis automatically. I'm not sure if we can leverage the log parsers used to display the numbers on TBPL or what. Longer term, we need tools to emit machine readable files and TBPL should present high-level diffs between builds (test X added, etc).
Comment 1 Phil Ringnalda (:philor, back in August) 2013-02-28 16:01:10 PST
That would only have been reasonably possible if it had gone m-i -> m-c -> b-s -> m-c. Since the merge from b-s merged m-i to m-c, your after includes things which were added on m-i.

For reftests (by which I mean things run by the reftest harness), "number of tests" means "number of lines in the manifest" so before linux32 opt did 8872/0/305 and after linux32 opt did 8873/0/305 and that has nothing to do with you, because either the files in the manifest are there or the suite fails. So m-i added one reftest to what was on your m-c before.

But the unit for mochitests, where you could have disappeared some test files, is not number of test files, it's number of calls to SimpleTest's testing functions, so a before of 223556/0/748 and an after of 223501/0/751 doesn't mean anything, just like it doesn't mean anything that the first winxp opt M1 on your after did 225285/0/711 and when I retriggered it it did 225334/0/711.

So what you need is for someone to write a log parser which will extract unique test filenames from a mochitest log, and to then do a three-way compare between the m-i rev that went to b-s and m-c before and m-c after.

Not it.

Note You need to log in before you can comment on or make changes to this bug.