the version of mozmill (1.4.1) in mozilla-central is outdated. In fact, it won't even run. Once mozmill 1.4.2 is released, mozilla-central should be updated to 1.4.2 and a current copy of the tests.

You should wait some days until we have updated our tests to the latest changes brought with Mozmill 1.4.2.

Yes, this (In reply to comment #1) > You should wait some days until we have updated our tests to the latest changes > brought with Mozmill 1.4.2. Yes this is effectively blocked by 1.4.2, but there is no tracking bug for that.

I would say that we can do it in multiple steps. There are no changes for 1.4.2 which would break test completely. So we will update the tests to use the new API functions 1 or 2 weeks after Mozmill 1.4.2 has been released and proofed to be stable and secure for our tests. In the meantime you can still push a current copy of the tests to m-c. Once bug 579965 has been fixed a lot more of our tests will use local test files. When dependencies are fixed we can push another update. But then we have to sort out on bug 562106 which tests we can have on m-c and how to sync those.

Yeah, there's no reason to try to improve on what we have for the purposes of this bug. This is just about updating what is there now (mozmill + a naive copy of the tests).

Note also that at least the log parser for buildbot (bug 516984) will have to be improved. See http://k0s.org/mozilla/hg/buildbotcustom-patches/file/tip/bug-516984-2#l205

Breaking up into two pieces: - updating mozmill on m-c - updating mozmill-tests on m-c (bug 596023) Changing title to reflect this

Are all of these dependencies really blockers for landing this? Or even bug 596023? They all seem like nice to haves more than blockers

(In reply to comment #7) > Are all of these dependencies really blockers for landing this? Or even bug > 596023? They all seem like nice to haves more than blockers The first 3 in the list will help us resolve recurring failures in the testruns. A green testrun is a dependency, AFAIK.

(In reply to comment #8) > (In reply to comment #7) > > Are all of these dependencies really blockers for landing this? Or even bug > > 596023? They all seem like nice to haves more than blockers > > The first 3 in the list will help us resolve recurring failures in the > testruns. A green testrun is a dependency, AFAIK. Should these deps be moved to the bug tracking updating tests on mozilla central (bug 596023)? The criteria is that the tests that land should be green, but there is no intention of landing all tests initially, and in fact we can't because the tests that land should only touch mozilla URLs. This discussion -- and perhaps the dependencies -- should be moved to bug 596023

Patch is here for review: http://k0s.org/mozilla/hg/mozilla-central-patches/file/67cc150d298d/bug-585086 Not sure how to flag as a review patch as it is bigger than the 2M limit

This will allow us to remove the debug addons from mozilla-central without any repercussions on jsbridge. We don't want those addons in mozilla-central because they are redundant and useless and just take up space. (I'd make the same argument about having them in github too, but I tend to lose that one).

Comment on attachment 475117 [details] [diff] [review] fix jsbridge to disregard debug addons if they are deleted >diff --git a/jsbridge/jsbridge/__init__.py b/jsbridge/jsbridge/__init__.py >index e2c4745..aca17e1 100644 >--- a/jsbridge/jsbridge/__init__.py >+++ b/jsbridge/jsbridge/__init__.py >@@ -105,7 +105,9 @@ class CLI(mozrunner.CLI): > parser_options[('-P', '--port')] = dict(dest="port", default="24242", > help="TCP port to run jsbridge on.") > >- debug_addons = [os.path.join(parent,'xpi', x) for x >+ debug_addons = [] >+ if (os.path.exists(os.path.join(parent, 'xpi'))): >+ debug_addons = [os.path.join(parent,'xpi', x) for x > in os.listdir(os.path.join(parent,'xpi'))] > > def get_profile(self, *args, **kwargs): This is fine, though I'd tend to avoid repeating the os.path.join(parent, xpi) in three places especially since we already make a global variable for resource path. See my solution here: http://k0s.org/mozilla/hg/mozilla-central-patches/rev/ca0078d3a0c1 We can take this one, or we can take the one from my patch queue.

(In reply to comment #12) > Comment on attachment 475117 [details] [diff] [review] > fix jsbridge to disregard debug addons if they are deleted > > >diff --git a/jsbridge/jsbridge/__init__.py b/jsbridge/jsbridge/__init__.py > >index e2c4745..aca17e1 100644 > >--- a/jsbridge/jsbridge/__init__.py > >+++ b/jsbridge/jsbridge/__init__.py > >@@ -105,7 +105,9 @@ class CLI(mozrunner.CLI): > > parser_options[('-P', '--port')] = dict(dest="port", default="24242", > > help="TCP port to run jsbridge on.") > > > >- debug_addons = [os.path.join(parent,'xpi', x) for x > >+ debug_addons = [] > >+ if (os.path.exists(os.path.join(parent, 'xpi'))): > >+ debug_addons = [os.path.join(parent,'xpi', x) for x > > in os.listdir(os.path.join(parent,'xpi'))] > > > > def get_profile(self, *args, **kwargs): > > This is fine, though I'd tend to avoid repeating the os.path.join(parent, xpi) > in three places especially since we already make a global variable for resource > path. See my solution here: > > http://k0s.org/mozilla/hg/mozilla-central-patches/rev/ca0078d3a0c1 > > We can take this one, or we can take the one from my patch queue. Note that I've already updated this in my patch and have tested it.