cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: cordova-vm.apache.org
Date Fri, 22 May 2015 21:18:10 GMT
afaik, it's still available, but probably we'd need to ping INFRA to make
it alive again (doesn't respond to pings atm)

On Thu, May 21, 2015 at 5:59 PM, Dmitry Blotsky <dblotsky@microsoft.com>
wrote:

> Hey folks,
>
> Resurrecting an old thread here: is cordova-vm.apache.org still available
> for us? We still need a couchdb machine on Apache Infra.
>
> Kindly,
> Dmitry
>
> -----Original Message-----
> From: Dmitry Blotsky [mailto:dblotsky@microsoft.com]
> Sent: Wednesday, April 8, 2015 5:29 PM
> To: dev@cordova.apache.org
> Subject: RE: cordova-vm.apache.org
>
> Thanks for the exposition, Jesse! Yeah, it seems like getting logs off
> some devices and emulators is either impossible or insurmountably
> difficult. I know Android and iOS emulators and devices create logs on the
> file system or have a utility to retrieve them from the device (e.g. adb
> logcat), but it doesn't seem like we can get the same easy access on
> Windows, BlackBerry, etc. Network seems to be the far superior solution.
>
> So, shall we then commandeer the Apache VM for medic's logging needs?
> Right now it's still using a private machine and it would be great to move
> this last piece to Apache infrastructure.
>
> Kindly,
> Dmitry
>
> -----Original Message-----
> From: Jesse [mailto:purplecabbage@gmail.com]
> Sent: Wednesday, April 8, 2015 4:07 PM
> To: dev@cordova.apache.org
> Subject: Re: cordova-vm.apache.org
>
> In reply to Dmitry, perhaps going off topic a bit ...
>
> All devices cannot echo their results back to the console that launched
> them.
> That was the reason in the first place for using a central db for
> federated test results.
> This is likely the ONLY way that this will ever work.
>
> Medic/BuildBot was originally designed to support a device wall with
> multiple devices running tests and reporting results to the db server,
> which then provided some interpretations of those results, including fancy
> graphs that showed things like 'the media plugin is failing 2 tests on
> Android 4.4 on a moto-x'
>
> Some of this has been lost along the way, but understand that there are
> limitations reporting test results by other means.
> 1. Windows Phone Emulator has tons of network weirdness, so reporting
> results to the command line that launched it is near impossible.
> 2. cordova-ios does not ship with any console.log capability, so there is
> nowhere to report tests to.
> 3. all of our cli build tooling exits as soon as it has built and launched
> the app, it would need to stick around and wait for results otherwise.
> 4. android does not echo console.log calls to the terminal that launched it
>
> cordova-paramedic leverages much of the way that medic works by creating
> it's own server to receive posted test results, thereby side-stepping some
> of the issues above.  This however is still not perfect in that it does not
> always play well with vms, wp8/windows are still unworkable, but
> ios/android do work.  Also, this is not intended to be a replacement for
> what medic does ( runs all the tests and federates the results ) but more
> so to integrate with TravisCI so we can see if a plugin pull request breaks
> anything, or to run yourself and test a particular plugin/platform
> combination in isolation.
>
> Ultimately though, I agree with Andrew's statement.  We need to spend more
> time fixing the bugs + the tests, instead of playing with how they are
> reported.
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Wed, Apr 8, 2015 at 2:59 PM, Dmitry Blotsky <dblotsky@microsoft.com>
> wrote:
>
> > The logs pull down the output from CouchDB; CouchDB serves as the main
> > dump point of output from a running mobilespec. This is the chosen
> > path for gathering output because we can't get logs for every platform
> > on every environment (i.e. both emulator and device), but we can get
> > network access for each.
> >
> > I'm not too knowledgeable on why logs aren't programmatically
> > available on every platform, but it is indeed another avenue that has
> > merit, and could eliminate the need for a DB in the middle. What are
> > the reasons that we can't get the logs from some emulators/devices on
> some platforms?
> >
> > - Dmitry
> >
> > -----Original Message-----
> > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of
> > Andrew Grieve
> > Sent: Wednesday, April 8, 2015 11:54 AM
> > To: Andrew Grieve
> > Cc: dev
> > Subject: Re: cordova-vm.apache.org
> >
> > Although - could you remind me why we need a couchdb? It's a hasstle
> > and will require maintentance.
> > The logs from the builders seem sufficient to me (they show which
> > tests fail). Effort might be better spent improving the tests & fixing
> bugs.
> >
> > On Wed, Apr 8, 2015 at 2:53 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > Sounds good!
> > >
> > > Here's the thread where I got myself access:
> > >
> > > http://markmail.org/thread/ee4ujznt6lhw6ug5#query:+page:1+mid:aqjyaw
> > > mz
> > > tdbnb2bf+state:results
> > >
> > > My notes from before:
> > > 1. Make sure you have an SSH key registered on id.apache.org
> > > (ssh'ing to the machine should work) 2. Install an OPIE
> > > (one-time-password) client http://apache.org/dev/freebsd-jails#opie
> > > 3. email root@apache.org asking them to add you to the VM 4. Wait
> > > for access to the machine 5. Set up OPIE via `opiepasswd`  -- DO NOT
> > > ENTER YOUR APACHE PASSWORD, it wants your client's generated password.
> > > 6. Request sudo access from #infra
> > >
> > >
> > > On Wed, Apr 8, 2015 at 2:13 PM, Steven Gill <stevengill97@gmail.com>
> > > wrote:
> > >
> > >> yes, it would be great if we could get access to it and setup a
> > >> couchdb instance that replicates CPR
> > >>
> > >> On Wed, Apr 8, 2015 at 10:57 AM, Nikhil Khandelwal <
> > >> nikhilkh@microsoft.com>
> > >> wrote:
> > >>
> > >> > Yes, we need it to setup an instance of CouchDB. Our longstanding
> > >> > INFRA ticket on this subject has not received much love. Having
> > >> > the VM should unblock us. What are the next steps to get access
> > >> > to it to setup a
> > >> couchDB
> > >> > instance?
> > >> >
> > >> > Thanks,
> > >> > Nikhil
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Parashuram N (MS OPEN TECH) [mailto:panarasi@microsoft.com]
> > >> > Sent: Wednesday, April 8, 2015 8:57 AM
> > >> > To: dev@cordova.apache.org
> > >> > Subject: Re: cordova-vm.apache.org
> > >> >
> > >> > If we still have the machine, we could still use it. I think we
> > >> > are
> > >> still
> > >> > working on getting CouchDB setup on Apache, or we could use this
> > >> > as a
> > >> slave.
> > >> >
> > >> >
> > >> > On 4/8/15, 8:35 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> > >> >
> > >> > >We got a VM a while ago with the idea to use it for BuildBot /
> > >> > >cordova-docs ruby environment.
> > >> > >
> > >> > >I don't think either of these are still applicable
> > >> > >(http://ci.cordova.io is
> > >> > >*awesome*!!!)
> > >> > >
> > >> > >Any reason to not ask for it to be decommissioned?
> > >> >
> > >> >
> > >> > -----------------------------------------------------------------
> > >> > --
> > >> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> >
> > >> > -----------------------------------------------------------------
> > >> > --
> > >> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

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