On 03/15/2013 11:33 AM, Gregory Szorc wrote:
Our build config has a number of areas where metadata is centrally
defined and a module or component's "configuration" is fragmented in
the source tree. Here are some examples:
<snip/>
3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini
defines every xpcshell.ini that exists in the tree.
http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/xpcshell.ini
Not sure if this is meant in terms of how the submanifests or laid out
or precisely what the issue is here or what is desired; this isn't
really addressed in the rest of the email (ABICT).
Our plan is to get more testing frameworks on manifests. See
https://bugzilla.mozilla.org/show_bug.cgi?id=852418 . This allows
fine-grained control of what is run on what platform (and whatever other
conditionals are encountered), notation for the reason tests are
disabled, and whatever other notations are desired. In addition, we are
gearing towards the ability to use and manipulate manifests via tools
and automation, such as on-the-fly generation of manifests and
information harvesting from manifests convolved with other sources.
While xpcshell currently has one "top-level" manifest (I think?), there
is no reason we couldn't have more.
Docs are at https://mozbase.readthedocs.org/en/latest/ . Please file
bugs at the Testing:Mozbase component and if you CC me (:jhammel) I'll
make sure they get triaged. We (=Automation + Tools) certainly welcome
ideas, feedback, and of course patches to the end of a better testing
environment. (And I apologize for the outstanding bugs; we are and have
been swamped! More info + STR = 90% of fixing for most bugs.)
<TL;DR>The main complaint we've heard, outside of "it feels clunky"
without more concrete example, is that it is .ini and not <insert format
here=JSON/reftest/something_more_obscure; it is worth noting since it is
a common suggestion that reftest manifests as they stand are suitable
for comparing of two images and much less suitable as a list of tests
and also that one of our main goals is to not have Turing complete e.g.
JS as part of a conditional>. Ultimately, .ini is a vehicle for what is
essentially in the backend a list of tests, where a test is an
(unsorted) set of (string) key-value pairs.</TL;DR>
Jeff
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
