You're missing the --busybox parameter. Without busybox, the harness
has to transfer each file individually, which takes a long time.
You can download busybox from e.g.,
http://busybox.net/downloads/binaries/1.19.0/busybox-armv6l
Jonathan
On 10/3/2014 4:18 AM, Fernando Jiménez Moreno wrote:
artinez-Winter
wrote:
stop me if I'm totally out of scope...
would it make sense in the future to have a (peer-to-peer ?) solution to
run tests on devices across the world (especially from the community, tests
running at night when devices are not being used) ?
On Tue Jun 3 20:23:39 2014, Jon
Hi all,
There have been a couple of threads related to test automation in B2G,
asking why we haven't caught some especially egregious regressions; the
kind that basically "break the phone".
To answer that, I'd like to describe how our on-device automation
currently works, and what we're doin
Gaia linter tests are now running in TBPL; they appear as "Li" and
belong to B2G Desktop Linux x64 Opt builds.
You can include them in try runs by specifying -u gaia-linter (or -u all).
Example logfile:
https://tbpl.mozilla.org/php/getParsedLog.php?id=38525022&tree=B2g-Inbound&full=1
Regards
Hi all,
As of last Friday, we have all of our on-device performance automation
for B2G running against Tarakos:
* b2gperf and 'make test-perf' are both reporting to Datazilla:
https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=7
=> These tools report per-app memory consumpti
Want to find out what the A*Team is up to for B2G? Check out the
meeting notes from yesterday's B2G Automation Meeting:
https://wiki.mozilla.org/Auto-tools/B2GAutomation/Meetings/2014-04-17
Highlights: what's happening for Tarako performance automation, and
plans for Firefox Mulet
Jonathan
Hi all,
Thanks to the efforts of Dave Hunt and others, we are now able to run
b2gperf on Tarako devices. This means we have app launch times
reporting to datazilla on the 1.3T branch:
https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=30&test=cold_load_time&app_list=browser,
Also possibly relevant: Andrew Halberstadt and Gareth Aye are currently
working on a socket-based generic harness for Marionette-based tests.
This will support structured logging. I think this could potentially
act as the consumer for this event stream of "interesting" events. You
might wan
Great news, thanks catlee.
Jonathan
On 4/4/2014 12:34 PM, Chris AtLee
wrote:
Hi
all,
Just a quick note to say that nightly Tarako builds are now
building & flashing properly.
Get 'em while they're hot
Curious about what the A-team is up to for B2G automation? Check out
notes from today's weekly meeting:
https://wiki.mozilla.org/Auto-tools/B2GAutomation/Meetings/2014-03-27
If you'd like to participate, you can join us Thursdays, @3pm PST in SFO
7-NoisePop.
Jonathan
__
ozilla.com || @chrisdavidmills
On 14 Feb 2014, at 00:53, Jonathan Griffin wrote:
We know that Gaia developers have long wanted the ability to use custom Gaia
builds in TBPL try jobs, mostly to help debug TBPL-specific failures in Gaia
tests. This has been a challenge, given the tight coupling of m
We know that Gaia developers have long wanted the ability to use custom
Gaia builds in TBPL try jobs, mostly to help debug TBPL-specific
failures in Gaia tests. This has been a challenge, given the tight
coupling of much of the related tooling with hg.
We now have a partial solution to this;
You can only return objects from Marionette that can be JSON-serialized; the
battery object cannot (it's a
https://developer.mozilla.org/en-US/docs/Web/API/BatteryManager instance).
This is why you can return navigator.battery.level, but not navigator.battery.
Jonathan
- Original Message
Yep, thanks!
On 1/17/2014 10:12 AM, Chris AtLee wrote:
Desktop builds continue to use gaia.json. We've added some checks to
try and ensure that the git revision of gaia in the device manifests
is the equivalent of the hg revision of gaia in gaia.json for the
desktop builds.
Desktop builds us
Thanks Catlee, this should indeed be a huge help to sheriffs.
How does the new mechanism interact with gaia.json, if it does?
Will builds other than b2g desktop now utilize gaia.json as well?
Jonathan
On 1/17/2014 7:58 AM, Chris AtLee
wrote:
e b2g code path seems feasible
If anyone better than me at reading tbpl could see if there was
any point in the last day in which gaia tests got less stable,
that would be useful information
On 27 November 2013
also?
On Wed, Nov 27, 2013 at 2:39
PM, Jonathan Griffin <jgrif...@mozilla.com>
wrote:
The
only Marionette change to have gone in recently
is:
The only Marionette change to have gone in recently is:
http://hg.mozilla.org/mozilla-central/rev/9cc147e1d222
Jonathan
On 11/27/2013 11:28 AM, Gareth Aye wrote:
Also fwiw I don't understand how this could have landed if the python tests
are running on tbpl...
On Wed, Nov 27, 2013 at 2:16 PM,
arent process, you can
already do that with WebAPI JS tests, although these are currently only
running on the emulator. If you need something else, then
browser-chrome probably isn't the right framework anyway.
Ping me if you'd like so we can figure this out.
Jonathan Griffin
On
speed cannot be certained?
They sounds like hypothesis, but without these tests in the suite, we
probably cannot do any heavy lifting in System app without realizing
we break something. Thanks.
On Tue, Oct 29, 2013 at 11:56 PM, Jonathan Griffin wrote:
Do the tests you need to write need to inte
n the critical launch path of the phone. If it breaks the
phone won't boot, and it did due to many suspectable race conditions
we found previously...
On Tue, Oct 29, 2013 at 5:53 AM, Jonathan Griffin wrote:
We currently do not support browser_chrome_tests in B2G, and there are no
current pl
We currently do not support browser_chrome_tests in B2G, and there are
no current plans to add support for it - all the existing browser_chrome
tests are Firefox-specific.
If there is a need for some hybrid gecko/gaia tests (and I believe there
likely is), we should carefully define what the c
There is a problem impacting emulator WebAPI tests randomly that results
in sporadic failures. This happens frequently enough that it negatively
impacts the ability of the sheriffs to deal with these tests, and we'd
like help in resolving it.
The bug is https://bugzilla.mozilla.org/show_bug.c
At the last work week, Jonas indicated it was important to get
mochitests (and other tests) running on debug builds, since tests
running against debug builds catch assertions, which are silently
ignored on opt builds. These assertions indicate some unexpected state
was reached in the code, whi
We're currently running the tests on TBPL on emulators, but we decided
at Oslo to start running them (as well as many other tests) on b2g
desktop builds as well, since it's important to prevent that platform
from breaking. So, we will be turning mochitests on for b2g desktop
builds in the near
We did resolve this. It turns out a copy of ssltunnel from an earlier
(failed) invocation was still running, so the (new) copy of ssltunnel
couldn't bind to its port. There were some other issues we had to sort
out as well, but eventually we got them going.
Jonathan
On 9/16/2013 12:19 PM, G
Yes, I can. :) What problems are you having?
Jonathan
On 9/10/13 9:57 PM, Dietrich Ayala wrote:
If you figure this out, can you post back here?
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
_
Does the situation improve if you use a regular gaia profile, rather
than a debug one? I'm not sure that the kind of profile modifications
that mochitest performs are compatible with debug profiles.
Jonathan
On 8/30/2013 5:02 AM, Jan Jongboom wrote:
I can't get this shit to work, and already
For --xre-path, you can specify the "bin" dir of a local Firefox build,
if you have one. Otherwise, you can download
http://people.mozilla.com/~ahalberstadt/getb2g/xre.zip, and use the
"bin" directory of that, after extracting.
Jonathan
On 8/21/2013 6:28 AM, pratikspawar...@gmail.com wrote:
On 8/1/2013 1:18 AM, Jonas Sicking wrote:
Given the fact that the failing code here appears to be the marionette
code itself (unless I'm misunderstanding the bug), I had assumed that
this fell on the a-teams responsibility. Not sure if that's incorrect
or not?
/ Jonas
Part of the difficulty wit
On 7/29/2013 11:41 PM, L. David Baron wrote:
On Monday 2013-07-29 18:03 -0700, Jonathan Griffin wrote:
We're currently running a very limited set of tests on debug builds
on mozilla-b2g18.
We'd like to run a larger set on m-c. We've had them running on
cedar for some while
We're currently running a very limited set of tests on debug builds on
mozilla-b2g18.
We'd like to run a larger set on m-c. We've had them running on cedar
for some while, but the tests have been failing ever since they were
first enabled due to various problems that would likely require
dev
te:
On 7/25/13 11:52 AM, Jonathan Griffin wrote:
I think it needs to become an engineering priority to deal with these
issues before they become critical. We need engineering owners for these
types of bugs who can be responsible for debugging and fixing them before
they get out of control.
T
There are probably multiple reasons why this has occurred, but one of
them is the fact that bugs filed due to TBPL intermittent oranges are
usually ignored for B2G. This causes our intermittent failures to build
up in aggregate until they reach a critical point and tests become
almost unsherif
ats timing out is causing lots of CPU to
be consumed and this winds up holding up the log data from being delivered?
Dave Hylands
- Original Message -
From: "Jonathan Griffin"
To: dev-b2g@lists.mozilla.org
Cc: "Lucas Adamski" , "Ryan Vandermeulen"
Sent:
We're seeing a frequent problem in which a random mochitest will take
orders of magnitude longer to execute than it normally does, causing the
testrun to timeout.
For example, in this log, the test
"/tests/content/html/content/test/test_track_disabled.html" takes 4635ms
to complete:
https:/
ent to automatically generate a series
of try builds that would span a list of gecko and/or gaia commits,
however. Is that something that would be generally useful?
Jonathan
On 7/12/2013 1:01 PM, Nicolas B. Pierron wrote:
On 07/12/2013 11:54 AM, Jonathan Griffin wrote:
I think there's
I think there's some confusion here. The tests that are reporting to
datazilla have nothing to do with TBPL or tryserver, and little to do
with buildbot, except that it uses buildbot nightly builds. These perf
tests are run using a completely separate system.
Are you trying to reproduce the s
Hi Gabriele,
I think, in order to support your use case, we'd need to modify the
testrunner to explicitly know how to run these on devices (rather than
emulators), which would involve restarting B2G before running the tests
so we could prevent a full load of Gaia.
If you'd like this, please
Hi Grabriele,
Can you file a bug about moznetwork.get_ip() not working correctly, so
we can figure out what the problem is and fix it? You can use a
component of Testing:Mozbase.
Thanks!
Regarding the other problem, the key lines of the log are this:
I/Gecko ( 105): MARIONETTE TEST RESU
I believe you'd need to use a mozilla-central eng build. There doesn't
seem to be any such build, so we'd need to request one from rel-eng.
Jonathan
On 6/3/2013 3:54 AM, Zac Campbell wrote:
.. and it be representative of a future shipping build, which build
should I be using?
Outside of v1
On 5/1/2013 4:35 PM, Jonas Sicking wrote:
On Mon, Apr 29, 2013 at 2:51 PM, Jonathan Griffin wrote:
TL;DR - The a-team and rel-eng are currently preparing to get gaia unit
tests running in TBPL (https://bugzilla.mozilla.org/show_bug.cgi?id=833666),
on both trunk gecko branches and gaia branches
for TBPL.
[1] https://github.com/mozilla-b2g/gaia/blob/master/tools/ci/unit/travis.sh
[2] https://travis-ci.org/mozilla-b2g/gaia/builds
2013/4/30 Jonathan Griffin <jgrif...@mozilla.com>
TL;DR - The a-team and rel-eng are currently preparing to get gaia unit
tests running in TBPL
(https://bugzilla.mozilla.org/show_bug.cgi?id=833666), on both trunk
gecko branches and gaia branches (e.g.,
https://tbpl.mozilla.org/?tree=Gaia-Master). We have a plan to
integrate these tests into
All of the issues involved are crashes of B2G. They only occur on
inbound/central/try, they don't occur on mozilla-b2g18.
Jonathan
On 3/20/2013 10:12 AM, Andrew Halberstadt wrote:
See https://bugzilla.mozilla.org/show_bug.cgi?id=853024
Due to too much instability, these tests are no longer
It's possibly a bug, can you please file a bug in bugzilla under
Testing:Marionette for this, and include as much information as you can?
Thanks,
Jonathan
On 3/6/2013 7:22 AM, Roy Collings wrote:
Can anyone explain this:
(code snippet)
...
x=self.marionette.find_element("xpath", "//*[@id='fr
Hi Roy,
That is the correct url. There are several touch-related methods which
are currently being added to Marionette, and the docs haven't caught up
with them yet. We will update them soon.
Jonathan
On 2/25/2013 7:09 AM, Roy Collings wrote:
Hi - currently I'm using this:
https://develo
We occasionally have seen the inverse problem, but we haven't seen a
case where an element is visible but Marionette claims it is not. The
best thing would be to file a bug (Testing:Marionette) with as much
information as you can gather.
Jonathan
On 2/18/2013 11:48 AM, royd...@gmail.com wrote
replacement for a nightly branch commit id?
John
On Feb 1, 2013, at 1:26 PM, Jonathan Griffin wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=834354
On 2/1/2013 1:22 PM, John Ford wrote:
That only works if code gets uplifted to nightly regularly, which it isn't any
more.
What&#x
https://bugzilla.mozilla.org/show_bug.cgi?id=834354
On 2/1/2013 1:22 PM, John Ford wrote:
That only works if code gets uplifted to nightly regularly, which it isn't any
more.
What's the bug tracking the fixes to automation -- can we prioritize these
fixes?
On Feb 1, 2013, at 1:11 PM, jonall
See
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Building_and_installing_Firefox_OS
On 2/1/2013 10:17 AM, royd...@gmail.com wrote:
Really? I'm after B2G ... so where would I run make -f from then?
On Friday, February 1, 2013 6:52:30 PM UTC+1, Jonathan Griffin wrote:
&#x
'make -f ...' from B2G/gecko will result in a Firefox build, not a B2G
build. Are you interested in using Marionette for Firefox or B2G?
Jonathan
On 2/1/2013 7:19 AM, royd...@gmail.com wrote:
Okay - installed Ubuntu (VM), restarted the instructions on
https://developer.mozilla.org/en-US/docs
Does this affect eng builds as well?
Jonathan
On 1/30/2013 7:11 PM, Dave Hylands wrote:
Hi everyone,
Bug 836103 has landed on b2g18 (earlier today). What this means is that in order to get
adb access to your phone, you now need to enable Remote debugging (under
Settings->Device Information->
It's now possible to run mochitests on B2G desktop builds. Instructions
are at
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/B2G_Mochitests.
If you run into any problems, please ping jgriffin on #ateam, or file
bugs under Testing:Mochitest.
Jonathan
___
On 1/4/2013 2:03 PM, Jonas Sicking wrote:
I'm not sure I understand what you are proposing. There is currently
no problem with Marionette that I know of. Other than the fact that
it's B2G specific and I don't expect that we will ever be able to use
the marionette test harness to test desktop b
Hi Jonas,
I don't think it would take much work to add support for running b2g
mochitests on the b2g desktop build, it just hasn't been a priority
since we're not running tests in that environment for TBPL, and there
hasn't been much interest from developers, at least that I've heard.
Howeve
Note that the B2G nightly manifests will need to be updated to point to
this new repo; is that on anyone's radar?
Jonathan
On 12/11/2012 7:36 PM, Hal Wine wrote:
All - the cutover to mozilla-b2g18 has been completed.
B2G's Gecko checkin repository is now
hg.mozilla.org/releases/mozilla-b2g18
We've recently had to make a change to Marionette to make it load later
in the B2G startup process in order to work around a networking problem
on the pandas. See bugs 800138 and 815807 for all the gory details.
The one negative side-effect of this is that it breaks WebAPI tests on
the emulat
We are now running a small set of mochitests on B2G emulators on all
trunk trees. We'll be expanding this set of tests as quickly as we can.
Meanwhile, if you'd like to run tests through try, here's how you can do it:
- Use a platform field of ics_armv7a_gecko
- Use a build type of 'o' (opt)
-
Reposting since this didn't make it to the mailing list, only the newsgroup.
On 10/11/2012 11:46 AM, Clint Talbert wrote:
With the new changes to develop b2g on aurora, how do we want to handle
automation and test changes to the tree? In the past, when we first
brought up mobile automation for t
Alex,
Jonathan will need to move Nightly/Stable builds over to
mozilla-aurora from mozilla-central for tonight's build, given the
FF18 base.
The nightly builds utilize the build manifests at
https://github.com/mozilla-b2g/b2g-manifest to select repos. I believe
these likely need to chang
This change seems to have broken builds for the unagi (dogfooding) device:
+ ./config.sh unagi config/default-otoro.xml
Initialized empty Git repository in
/data/jenkins/jobs/build-unagi/workspace/tmp_manifest_repo/.git/
[master (root-commit) 2c6c728] manifest
Committer: Jenkins Continuous Buil
62 matches
Mail list logo
