From: Igor Opaniuk <igor.opaniuk@foundries.io>
To: openembedded-core@lists.openembedded.org
Subject: [oe-selftest] adding new tests workflow
Date: Thu, 20 Jan 2022 16:40:33 +0200 [thread overview]
Message-ID: <CAL6CDMGDmLQ+kQACFOO716ofrjBGUjH=SnBR+n7FYg8Ey3VThg@mail.gmail.com> (raw)
Hi everyone,
I do have some questions about a standard workflow people usually
follow when adding new test sets to meta/lib/oeqa/selftest/cases/.
When oe-selftest is invoked for example this way:
oe-selftest --run-tests wic.Wic2.test_offset --machine random
It usually creates a new build dir, then as far as I understood it
builds all available recipes (~30GB of build cache) for a random
machine.
When I try to invoke oe-selftest again, it prints error message that
build dir already exists:
2022-01-20 16:27:50,892 - oe-selftest - INFO - Adding layer libraries:
2022-01-20 16:27:50,892 - oe-selftest - INFO - openembedded-core.git/meta/lib
2022-01-20 16:27:50,892 - oe-selftest - INFO -
openembedded-core.git/meta-selftest/lib
2022-01-20 16:27:50,893 - oe-selftest - INFO - Running bitbake -e to
test the configuration is valid/parsable
2022-01-20 16:27:52,524 - oe-selftest - ERROR - Build directory
openembedded-core.git/build-st already exists, aborting
So there are two questions:
1. Are there a way to avoid building full set of recipes, if I really
want to run tests for one specific module (ksparser for example,
--run-tests wic)
2. Is it possible to re-use existing build directory for that and
expect bitbake to rebuild only recipes that were changed?
Thanks and looking forward to suggestions.
Regards,
Igor
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Embedded Software Engineer
T: +380 938364067
E: igor.opaniuk@foundries.io
W: www.foundries.io
next reply other threads:[~2022-01-20 14:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 14:40 Igor Opaniuk [this message]
2022-01-20 14:51 ` [OE-core] [oe-selftest] adding new tests workflow Alexander Kanavin
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='CAL6CDMGDmLQ+kQACFOO716ofrjBGUjH=SnBR+n7FYg8Ey3VThg@mail.gmail.com' \
--to=igor.opaniuk@foundries.io \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).