So it sounds like it would be valuable to add try syntax to trigger
this, as well as produce periodic reports. Most of the work needed is
the same.
I'll file a bug to track this; I don't have an ETA for starting work on
it, but we want to get to it before things bitrot.
Jonathan
On 7/7/2014 12:49 PM, Joshua Cranmer 🐧 wrote:
On 7/7/2014 1:11 PM, Jonathan Griffin wrote:
I guess a related question is, if we could run this periodically on
TBPL, what would be the right frequency?
Several years ago, I did a project where I ran code-coverage on
roughly every nightly build of Thunderbird [1] (and I still have those
results!). When I talked about this issue back then, people seemed to
think that weekly was a good metric. I think Christian Holler was
doing builds roughly monthly a few years ago based on an earlier
version of my code-coverage-on-try technique until those builds fell
apart [2].
On 7/7/2014 11:18 AM, Brian Smith wrote:
Ideally, you would be able to trigger it on a try run for specific
test suites or even specific subsets of tests. For example, for
certificate verification changes and SSL changes, it would be great
for the reviewer to be able to insist on seeing code coverage reports
on the try run that preceded the review request, for xpcshell,
cppunit, and GTest, without doing coverage for all test suites.
To minimize the performance impact of it further, ideally it would be
possible to scope the try runs to "cppunit, GTest, and xpcshell tests
under the security/ directory in the tree."
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
