Definitely agree that the presentation bits need a ton of work. I bikeshedded the whole thing. Essentially the web frontend can be completely tossed. The reusable bits are the bits integrating with the couch db.
I really want to have medic run on top of cordova-cli, but there are limitations there. A bunch of the multi-device deployment scripts in medic are built right on top of native mobile tooling, and I'm not sure if that is possible to implement right now on top of cordova-cli. Additionally, I am unsure if that is the type of use case that we want to support in cordova-cli. If so: we should refactor cordova-cli to enable it. If not, well, then we support it in medic. Once the repo is up and we push stuff from my fork over we can start figure out a roadmap for it. We DEFINITELY should talk about medic at our committer meeting coming up .. Whenever that is. On 7/29/13 11:35 AM, "David Kemp" <drk...@google.com> wrote: >I have been reviewing the medic components and the procedures for testing >the various parts of the Cordova project. With the changes in 3.0, there >are plugins that need to be handled and as already mentioned, I would like >to expand to include the tooling as well. One side effect of this is error >reporting on about 20 'projects' instead of just 2-3. > >Currently medic does a bunch of things : >* provides a dashboard of the test results and commits >* watches for commits on the android, ios,blackberry and mobilespec >projects >* when commits happen > * get the newest code > * build and report any errors to couchdb > * modify a few things to add jasmine reporting to a couchdb > * deploy to a bunch of appropriate devices > * log to couchdb if the tests do not finish in time > >With the 3.0 structure, the git monitoring and project structure gets >quite >a bit more interesting. Also we have now added a bunch of tools that do >some of this as part of their flow that we should be testing. > >So .... > >I propose that the cordova-cli and cordova-coho tools be used as part of >the test process. This means using something to watch for commits, then >launch coho to get a full set of plugins, platforms and mobilespec. It >might be wise at this point to even compile cordova-js and log the results >of the tests there. >Then some medic magic needs to happen to prepare the project for jasmine >reporting and auto-launch. Then use cli to build and deploy. >Any errors in the tooling would need to be captured in the test DB as >separate items from the errors in the platforms. > >For this to work, the medic components to manage the db and prepare a >project for an automated mobilespec would need to be broken out into >separate utilities. Also there would probably need to be a few additions >to >cli to target multiple devices, etc. > >At the top level, we still need discovery of new commits, but over a broad >range of projects. There are bits in medic that do that (needs a little >work) or possibly use buildbot for that layer. One advantage of that would >be the already built-in notification for a broken build (email/irc, ...). >Perhaps we could even report the commit(s) that broke it... > >The data presentation/reporting will need some work. There will be lots >more to show. > >Thoughts and/or discussion?
