When they will we will have even more problems as python3 is not going to be on the target (phone) image. I would say that's a very strong reason to implement local post-processing for remotely-executed applications.
There are many other use cases that this enables: bootloader testing (you cannot push python there ;-), testing bare android, firefox OS, testing micro-controllers where you run something via serial but really do all the analysis locally. Thanks ZK On Mon, Mar 3, 2014 at 6:09 PM, Ara Pulido <[email protected]> wrote: > > > On 03/03/14 18:06, Zygmunt Krynicki wrote: > > Hey Ara > > > > I agree with Brendan here. Copying this will quickly pull in > > checkbox-support thus it will nullify any value in remotely testing > > under-development version of your code. > > For use cases like Ubuntu touch that's not a problem as they don't use > > any of our scripts. > > But they should :) > > At some point, we will create rich test cases for Ubuntu tablet, that > will probably require to use scripts from checkbox-support. > > > > > > Thanks > > ZK > > > > > > On Mon, Mar 3, 2014 at 5:18 PM, Ara Pulido <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > On 28/02/14 03:04, Zygmunt Krynicki wrote: > > > > > > On Thu, Feb 27, 2014 at 5:20 PM, Sylvain Pineau > > > <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > > > > On 27/02/2014 17:11, Daniel Manrique wrote: > > > > > > On 14-02-26 12:46 PM, Zygmunt Krynicki wrote: > > > > > > > > > Execution controllers > > > --------------------- > > > > > > Execution controllers that prepare the environment for > > each > > > job would > > > necessarily change. Existing set of controllers can > > run jobs > > > as the regular > > > user, as a root user via sudo or as a root user via > > > plainbox-trusted-launcher-1. > > > > > > In addition to user handing, those controllers handle > the > > > task of configuring > > > the filesystem for a specific job. The new remote > > controller > > > would need to > > > ensure that provider data associated with the job that > > is to > > > be executed is > > > copied (using rsync or adb push or other similar > command). > > > > > > > > > > > > > > > This suggests you will copy only relevant data for each > test. > > > Can this be > > > determined reliably without too many hairy heuristics? > will we > > > need to add more > > > metadata to jobs or scripts so that a remote environment > > can be > > > properly configured? > > > > > > Another approach that comes to mind is copying *everything* > > > (where "everything" > > > needs to be determined) when the first remote job > executes, so > > > subsequent jobs > > > can count on stuff being there. This would be handled by > the > > > execution > > > controller I think. > > > > > > One of the execution controller future role will also be to > detect > > > program/scripts that have to be run locally > > > but are part of the job command, e.g: "run_this_on_target | > > > parse_output_with_local___parser" > > > Several local jobs are using this method taking the output of a > > > remote command and doing some magic to > > > create jobs with run_template+udev_resource. > > > > > > > > > > > > This is an interesting point. Technically (currently) that would > > all run > > > remotely. We would copy all of the scripts (including > > udev_resource) and > > > run that there. I see that we might want to run certain parts > locally. > > > Fortunately that is easy to express (though it would require us to > > alter > > > jobs that want the distinction). > > > > > > id: some-job > > > command: foo > > > post-process: bar > > > > I wouldn't like to make this more complex if it is not fully needed. > > What's the problem in copying udev_resource (i.e.) in the target? > > > > Thanks, > > Ara. > > > > > > > > This would effectively run: "adb -s $target shell foo | bar", or > "ssh > > > $target shell foo | bar" > > > > > > What do you think? > > > > > > Thanks > > > ZK > > > > > > > > > > -- > > Mailing list: https://launchpad.net/~checkbox-dev > > Post to : [email protected] > > <mailto:[email protected]> > > Unsubscribe : https://launchpad.net/~checkbox-dev > > More help : https://help.launchpad.net/ListHelp > > > > >
-- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
