checkbox-dev team mailing list archive

[Ara Pulido <ara.pulido@xxxxxxxxxxxxx>]

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
> 
>