From: Patrick Ohly <patrick.ohly@intel.com>
To: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 1/2] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution
Date: Tue, 14 Nov 2017 17:09:28 +0100 [thread overview]
Message-ID: <1510675768.5979.9.camel@intel.com> (raw)
In-Reply-To: <20171114100939.12d4c1df@lsandov1-mobl2.zpn.intel.com>
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@intel.com> wrote:
>
> > On Mon, 2017-11-13 at 10:17 -0800,
> > leonardo.sandoval.gonzalez@linux.intel.com wrote:
> > > From: Leonardo Sandoval <leonardo.sandoval.gonzalez@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.
> > 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?
> >
--
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.
next prev parent reply other threads:[~2017-11-14 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 18:17 [PATCH v2 1/2] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution leonardo.sandoval.gonzalez
2017-11-13 18:17 ` [PATCH v2 2/2] parallel-oe-selftest.sh: runs oe-selftest in parallel leonardo.sandoval.gonzalez
2017-11-14 8:24 ` [PATCH v2 1/2] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution Patrick Ohly
2017-11-14 16:09 ` Leonardo Sandoval
2017-11-14 16:09 ` Patrick Ohly [this message]
2017-11-14 17:42 ` Leonardo Sandoval
2017-11-15 10:01 ` Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1510675768.5979.9.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=leonardo.sandoval.gonzalez@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.