cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Billau <mike.bil...@gmail.com>
Subject Re: Medic status and plans
Date Thu, 10 Oct 2013 14:07:28 GMT
Hi Sergey,

We have been using David's Medic++ over here without too many issues.
(Moving the master to a linux box was key.) The setup was pretty easy once
you get Buildbot installed.

I'm not sure how much effort it would take to add Windows platforms
support, but it doesn't seem like that much. I think that you pretty much
just need to follow the examples of the other two platforms and write
BuildBot commands (in Python) to shell out to the lower level dev tools to
create the project and deploy on your devices:
https://github.com/drkemp/bb-test/blob/master/master.cfg#L132

I think the next steps should be something like:

1. Set up a centralized couchDB where we can aggregate data from all of the
CI instances. A few months ago I requested a VM for this purpose and it
looks like we will get it soon:
https://issues.apache.org/jira/browse/INFRA-6422
2. Need a dashboard to view all of the results
3. Set up reporting so that the CI actually gets used (email devs who break
builds, possibly IRC bot, would be nice to have a TravisCI style badge on
the github pages, etc.)
4. Documentation - there should at least be instructions to help others
quickly set up a CI and feed data back to the community (David's readme.md?)
There should also be docs about setting up the device wall, which USB hubs
are the best to buy*, etc

After those three immediate issues get resolved, I think the CI will start
to really provide a lot of value to the community and the project. After
that happens, we can talk about more long term goals and feature
enhancements. The biggest enhancement I can think of would be the ability
to run personal builds against the test devices and get feedback before
checking in code. I'm sure there are a lot of other things we can do too,
like adding in the rest of the platforms, exercising the native tests,
making the system more robust, etc.

David, what do you think about pushing your bb-test branch into the
cordova-medic repo? We can put Fil's old stuff into a branch for safe
keeping, but it seems like we should all be concentrating on the same
version of medic, and your buildbot branch is clearly the most complete and
working version. Having it in the official repo would make it easier for
people to find and contribute to.

Mike Billau

*For USB hubs, we have been daisy chaining these hubs and have only had
charging issues with Samsung tablets:
http://www.amazon.com/Plugable-Charger-Adapter-Charges-Kindle/dp/B005P2BY5I

David has been using these ones that have a 2.1A port for iPad charging (we
haven't yet seen the iPads discharge ):
http://www.amazon.ca/Release-Charging-Adapter-3-5-foot-Included/dp/B00B7FLPBU/ref=cm_cr_pr_product_top
I think part of the medic documentation should definitely have a discussion
about USB hubs because this is a difficult and potentially very expensive
part of setting up medic.


On Thu, Oct 10, 2013 at 9:47 AM, David Kemp <drkemp@google.com> wrote:

> Hi Sergey,
> Yes that is the only change to mobilespec regarding medic. It simply allows
> the automated test components to be installed as a plugin without editing
> any source files other than config.xml.
>
> There is a separate discussion going on about changing mobilespec to a
> wrapper that gets tests out of plugins (since thats mostly what it tests),
> but even that would not significantly change how the CI system operates,
> just how the test app is built.
>
>
>
>
>
>
>
>
>
> On Thu, Oct 10, 2013 at 9:37 AM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > Hi David,
> >
> > Thank you for the very valuable input. As per " I recent made a change to
> > mobilespec to support a medic plugin to make the insertion of testing a
> bit
> > smoother. " Do you refer to the following changes? Are there other
> changes
> > in this direction in mobile-spec?
> >
> >
> https://github.com/apache/cordova-mobile-spec/commit/de23e302daefcfac603fc992e41467d43ae40d87
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: David Kemp [mailto:drkemp@google.com]
> > Sent: Thursday, October 10, 2013 5:06 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Medic status and plans
> >
> > More info...
> >
> > The system I am using uses buildbot which has a master controller that
> > provides a web interface, moitors the git repos and generally manages
> > things. When it detects a need for a build, it communicates with
> > build-slaves to run the tests and report back.
> >
> > The build master is typically run on a linux box. It seems happy there,
> > but should run on a Windows machine - I have never tried, but the docs
> says
> > it works.
> > The build slaves can run on other machines and OSs (including Windows) as
> > required to run tests.
> > If you are building iOS, that slave must be a Mac. If you are building
> > Windows, it probably needs to be a Windows slave.
> >
> > Buildbot is written (and configured) in Python.
> >
> > The test results are written to a couchDB on every run. You can inspect
> > the DB and find out exactly which component versions were used and the
> > detailed test results.
> >
> > Plans (mine at least):
> >
> > Get the  test output viewable by the community. We are very close to
> > having our test master available on a public IP so anyone can see the
> > current state. It is my hope that as more people run CI systems, we can
> > aggregate the views on ci.cordova.io so all platforms are easily viewed.
> > This should include a tidy dashboard to look at the couchDB aggregate
> data.
> >
> > Make the test more plugin-based. The previous medic system did sed-style
> > editing of files to insert some of the automated test elements.
> > I recent made a change to mobilespec to support a medic plugin to make
> the
> > insertion of testing a bit smoother. That is not being used yet in the
> test
> > system because it does not exist in release 3.1. A rough plugin exists in
> > the repo.
> >
> > Move the medic deploy bits to simpler scripts that are just command line
> > methods to run the package in debug/attached mode.
> >
> > Hope that helps.
> > There are several other people interested in or using this or similar
> > systems. Please jump in...
> >
> > David Kemp
> >
> >
> >
> >
> >
> > On Thu, Oct 10, 2013 at 3:08 AM, Sergey Grebnov (Akvelon) <
> > v-segreb@microsoft.com> wrote:
> >
> > > Hi guys,
> > >
> > > I would like to contribute to Medic project by adding Windows
> > > platforms support (Windows 8, Windows Phone 8).  After reviewing
> > > related discussion threads and project status I have the following
> > > questions. Could someone clarify them?
> > >
> > > 1. The main repo[1] seems to be not active at all (last commit was 6
> > > months ago).  I also see special ticket with done status to create
> > > official repo, but new repo is not active too.
> > > 2. Don't see any issue/task for Medic component in Jira.
> > > 3. Medic future is unclear. Fil Maj (Medic lead) has recently moved to
> > > saucelabs . Who drives this direction right now? Will we  continue
> > > contributing to Medic project or there will be a different project
> > > used for test authomation (Appium)?
> > > 4. Are there plans or (anyone is already looking)  on adding WP8, W8
> > > support? Are there any known technical restrictions or issues here?
> > > The only big difference I see is that it should run on Windows instead
> > > of Mac OS.
> > > 5. Currently Medic uses own logic to install builds on devices
> > > (cordova cli already provides this functionality). Are there plans to
> > > change this (running Medic on top of cordova cli)?
> > > 6. To get test results Medic previously used special logs/trace
> > > parsing so that final results were pushed to db from PC, NOT directly
> > > from mobile test app installed on a device. Do you plan to change this
> > behavior?
> > >
> > > [1] https://github.com/filmaj/medic/commits/master
> > >
> > > Thank you,
> > > Sergey Grebnov
> > >
> >
>

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