[OE-core] [PATCH v2 1/2] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution
Leonardo Sandoval
leonardo.sandoval.gonzalez at linux.intel.com
Tue Nov 14 17:42:39 UTC 2017
On Tue, 14 Nov 2017 17:09:28 +0100
Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Tue, 2017-11-14 at 10:09 -0600, Leonardo Sandoval wrote:
> > On Tue, 14 Nov 2017 09:24:30 +0100
> > Patrick Ohly <patrick.ohly at intel.com> wrote:
> >
> > > On Mon, 2017-11-13 at 10:17 -0800,
> > > leonardo.sandoval.gonzalez at linux.intel.com wrote:
> > > > From: Leonardo Sandoval <leonardo.sandoval.gonzalez at linux.intel.c
> > > > om>
> > > >
> > > > The main idea is to isolate the oe-selftest execution so neither
> > > > the
> > > > current build dir nor the configuration data is touch/polluted.
> > > > This
> > > > approach uses a wrapper script (which is the one presented on
> > > > this
> > > > commit) which creates a unique directory and inside it copies all
> > > > scripts and metadata, re-initializes the enviroment (re-sources
> > > > oe-
> > > > init-build-env) and finally launches the oe-selftest-internal
> > > > (which
> > > > used to be oe-selftest) command, passing command arguments to the
> > > > latter.
> > >
> > > This mode of operation may or may not be desirable. Can it be made
> > > optional?
> >
> > good idea. However, you can call the oe-selftest-internal for the
> > this purpose.
>
> While doable, it feels wrong to rename something as "internal" and then
> still expect people to call it directly.
>
> A command line parameter for the new oe-selftest which controls this
> behavior and just calls oe-selftest-internal directly when requested
> feels cleaner and more discoverable.
>
> Is oe-selftest-internal even going to be in the default PATH? It
> probably shouldn't be, once it truly becomes an implementation detail.
where can we placed it besides the scripts folder?
>
> > > In refkit CI testing, several selftests run tests on build
> > > artifacts
> > > (primarily the images) produced during the previous build and only
> > > build them if needed, i.e. they run "bitbake some-image" and that
> > > is
> > > usually fast because the image already exists. Reusing sstate and
> > > download dir also is important for speed.
> >
> > oe-selftest creates a new build/conf folder, with the same conf files
> > as the ones present in your current build/conf, so this means that
> > you can set there DL_DIR and SSTATE_DIR (for example) on your main
> > local.conf and these will be used by oe-selftest, effectively reusing
> > these folders.
>
> Instead of leaving it to the developer to figure this out, should the
> oe-selftest have --[no-]reuse-download and --[no]-reuse-sstate options?
sounds good. By default, we will let reuse download/sstate.
Good input. I will send a v3.
>
> > >
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
More information about the Openembedded-core
mailing list