On Tue, 14 Nov 2017 09:24:30 +0100 Patrick Ohly <patrick.o...@intel.com> wrote:
> On Mon, 2017-11-13 at 10:17 -0800, > leonardo.sandoval.gonza...@linux.intel.com wrote: > > From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com> > > > > 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. > > 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. > > Forcing all tests to run in a clean environment would make the overall > CI run slower. Agree. better to start with a 'hot cache' scenario, and this can be accomplished the way I mentioned before. > > -- > 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. > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
