It looked like much of the device-specific deployment bits could be applied between cli prepare and cli run - as long as run does not do a prepare - or a deploy option is added (discussed in a separate thread). Then I think you can deploy to a device and start a timer (x n devices).
There's probably stuff I'm missing, but the lack of a deploy-only option in cli was the only roadblock I saw. I was thinking of a flow like the 'working with 3.0' page with a few additions. That keeps the test environment really close to our recommended workflow. Roughly: * coho to get everything (platforms, plugins, js, cli, mobilespec) * npm install cli * npm install js * build js (log tests) * patch json * cli to add platforms, plugins * copy in the newest js * hook up the mobilespec project * cli prepare * Medic bits to patch the project for each platform * cli to compile for each platform * cli to deploy to each device all along there, the Medic/couchDB stuff needs to be recording success/failures. On Mon, Jul 29, 2013 at 6:04 PM, Filip Maj <[email protected]> wrote: > 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" <[email protected]> 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? > >
