checkbox-dev team mailing list archive
-
checkbox-dev team
-
Mailing list archive
-
Message #00091
Re: CEP-4: PlainBox Target Device
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.
Thanks
ZK
On Mon, Mar 3, 2014 at 5:18 PM, Ara Pulido <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>>
> 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
> Unsubscribe : https://launchpad.net/~checkbox-dev
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References