cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: medic
Date Thu, 25 Jul 2013 18:07:49 GMT

On Thu, Jul 25, 2013 at 2:03 PM, David Kemp <> wrote:

> Hi all,
> In the spirit of trying to share the goods, I would like to see if we can
> co-ordinate some of the efforts, and more importantly some of the data.
> With the changes in 3.0, I don't think the data structure used previously
> is sufficient.
> I would like to see results that:
> * for mobilespec: include the platform, platform version, js version,
> plugin list (with versions)
> * include results for cordova-cli
> * include results for cordova-coho
> * include results for cordova-js tests
> * include results for other tools that are testable
> The current medic structure tags tests with <platform><sha>.
> A possible solution is to add an additional dataset that ties a Test_ID to
> a test description. The test description could be a a structured object
> indicating the list of <component><sha> that was in the test. If we expand
> the <platform> to mean <component>, then the test results get saved with
> tag of <component><test_id>.
> So you would get a test like:
> test_id=ANDROID_1234
> results="270 passed, 0 failed"
> components="
> cordova-android: 980c4699b0993b1718c2f0a1761f7d3cc49a0c9b
> cordova-cli: 1fe77b0be1997c42da31606cdbca9eb9e90a954e
> cordova-js: d716e31b39bd39a06f1db80040e2c8a6a78a34e8
> cordova-mobile-spec: f5c0a54d056c6e9b76f59eac2b2908ddbfed3e65
> cordova-plugin-battery-status: f52824aba6aa0f470d2ee5b3d53466fd8668ac56
> cordova-plugin-camera: 5d747c739ddd41b731f77fb531481a709ea497cd
> cordova-plugin-console: 3cb1165a3f95e86045e9800ba3e8b4ffb0ef5a91
> cordova-plugin-contacts: 5f0847d4a13a90df5b37bdcbabae6936610a5345
> cordova-plugin-device: 3c5832d2cca354bb1309eef738a848e2d4b87e3e
> cordova-plugin-device-motion: 43e653378bb3bc98ffd39c1b8d0e2a0a3d412c6c
> cordova-plugin-device-orientation: a522c97336d859a57c89d11a2dde7cb9a5771b15
> cordova-plugin-dialogs: 96c52b4d8411f7745fec5e154ad75474a4fc4d07
> cordova-plugin-file: 698d7f6d2d2f2e9364451d5c0b4c763eae97c192
> cordova-plugin-file-transfer: e37895a56e314832d8480dfde221a1f72d915140
> cordova-plugin-geolocation: d8f8aa5beef0b16d656662d59b31a0bee1b69b0d
> cordova-plugin-globalization: 8caedd2c6674e485dd46941f3f0106f7b17f1bbf
> cordova-plugin-inappbrowser: dd7b20543f20660b4be71721e404e4ba7219aa7c
> cordova-plugin-media: 9538b8c10d01fac785b3764985e7d836046802fb
> cordova-plugin-media-capture: ba76f1121b34376fe11c58bb30ebe8ab8481281a
> cordova-plugin-network-information:
> e45286df35487a4414756d8fb93597ea454cb1ff
> cordova-plugin-splashscreen: 33f353d2e9684e189f8b7d59c066253f2fe73f48
> cordova-plugin-vibration: 5c08769e83a09e900fe301f140bbe143390e8eb0 "
> Better ideas anyone?
> On Fri, Jul 19, 2013 at 2:38 PM, David Kemp <> wrote:
>> Hi Mike,
>> So, we are on much the same road. I also had medic working briefly
>> pre-3.0.
>> When the 3.0 structure changed, I put it aside for a while since it was
>> clearly going to take a bit of effort to change medic to run with 3.0.
>> Today, while the dust settles a bit I have been looking at the idea of
>> using buildbot for the primary tooling, and using coho and cordova-cli for
>> a bunch of the build steps.
>> My goal was to include coho and cli in the test chain so we can detect
>> failures there too.
>> I also looked at the issue of tracking versions and had not yet decided
>> on any good way to describe a test set in a similar way to the simple
>> <platform><sha>. In the case of 3.X, it seems like it should be:
>>  <platform><sha><mobile-spec><sha>[..<plugin><sha>..]
>> David
>> On Fri, Jul 19, 2013 at 2:01 PM, Mike Billau <>wrote:
>>> Hi,
>>> Initially I was just working on understanding what medic was doing and
>>> how. It's a pretty neat piece of code, Fil did a great job. I am new to
>>> node so this step has taken a bit longer than expected.
>>> You'll notice that the code is pretty old, so at first I was just
>>> updating it to work with the 2.X stream - doing things like removing the
>>> -VERSION suffix from cordova.js file, figuring out how to write my couchdb
>>> URL into the whitelist, etc. I was able to get medic to work for a few
>>> hours with three different Android devices, it was cool.
>>> Things are a bit different now though with the 3.X stream and having
>>> everything split apart. The last few days I have been working on
>>> integrating the CLI. On one hand, using the CLI seems to simplify a lot of
>>> the code, especially with the mobile spec create script that Andrew checked
>>> in yesterday (haven't integrated this yet but seems simple enough.)  On the
>>> other hand, with everything split out I am not sure if it is going to be
>>> possible to pull down the code from a specific SHA and test it out - at
>>> least not until the medic tests themselves get added into their specific
>>> repos. (How would you know which version of mobile spec matches the current
>>> SHA? By timestamp?)  I don't really think this is an issue though because
>>> it is a CI...if we just pull the HEAD of every repo when a new commit comes
>>> in and run the test, then it should be fine. (If there is a need to test
>>> old SHA, one could build that specific version of mobile spec, run through
>>> the automated tests, and hit a "Report to DB" button or something.)
>>> My current goals are to 1. integrate Andrew's script so I can have a
>>> single node command instead of 15 nested .exec callbacks, 2. Figure out why
>>> the gitpubsub always gives me JSON errors when a new commit goes in, 3. Get
>>> it running and reporting data to the couchdb, 4. Clean up the code / remove
>>> the specific SHA part 5. Check in with Ryan Willoughby who has been working
>>> on integrating PhoneGapBuild and see if he has done any 3.0 work 6. Poke
>>> the apache infra guys to see if they have set up a couch db machine for us
>>> I have also been researching types of USB hubs to use - the Adobe guys a
>>> while back told me about their huge 42 port hub. So far I have been testing
>>> the 4 port powered Pluggable devices and they daisy chain well and can do
>>> data+power with all of our devices save Samsung tablets and some iDevices.
>>> I have been compiling a table internally of the device/hub compatibility
>>> that I'd like to share/collaborate on.
>>> Hopefully we can collaborate and get this thing running. A few days ago
>>> we talked about how it'd be cool to add a "-ci" parameter to the CLI so
>>> that other offices can easily get medic up and running with whatever
>>> devices they have. I think this would be a pretty useful thing to add.
>>> Hope ya'ller having fun at the conference!
>>> Mike

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message