checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

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 <ara.pulido@xxxxxxxxxxxxx> 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 <ara.pulido@xxxxxxxxxxxxx
> > <mailto:ara.pulido@xxxxxxxxxxxxx>> wrote:
> >
> >
> >
> >     On 28/02/14 03:04, Zygmunt Krynicki wrote:
> >     >
> >     > On Thu, Feb 27, 2014 at 5:20 PM, Sylvain Pineau
> >     > <sylvain.pineau@xxxxxxxxxxxxx
> >     <mailto:sylvain.pineau@xxxxxxxxxxxxx>
> >     <mailto:sylvain.pineau@xxxxxxxxxxxxx
> >     <mailto:sylvain.pineau@xxxxxxxxxxxxx>>> 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     : checkbox-dev@xxxxxxxxxxxxxxxxxxx
> >     <mailto:checkbox-dev@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~checkbox-dev
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
>