On Thu, 2022-11-17 at 09:12 +0200, Mikko Rapeli wrote:
> Many runtime tests would need customization for different
> machines and images. Currently some tests like parselogs.py are hard
> coding machine specific exceptions into the test itself. I think these
> machine specific exceptions fit better as image specific ones, since a
> single machine config can generate multiple images which behave
> differently. Thus create a "testimage_data.json" file format which image
> recipes can deploy. This is then used by tests like parselogs.py to find
> the image specific exception list.
> 
> Same approach would fit other runtime tests too. For example systemd
> tests could include a test case which checks that an image specific list of
> services are running.
> 
> I don't know how this data storage would be used with SDK or selftests,
> but maybe it could work there too with some small tweaks.
> 
> Mikko Rapeli (2):
>   oeqa: add utils/data.py with get_data() function
>   oeqa parselogs.py: use get_data() to fetch image specific error list
> 
>  meta/lib/oeqa/runtime/cases/parselogs.py | 17 +++++++---
>  meta/lib/oeqa/utils/data.py              | 41 ++++++++++++++++++++++++
>  2 files changed, 54 insertions(+), 4 deletions(-)
>  create mode 100644 meta/lib/oeqa/utils/data.py

This patch looks like it is one side of the equation, i.e. importing
the data into the tests. How does the data get into the deploy
directory in the first place? I assume there are other patches which do
that?

We have a bit of contention with two approaches to data management in
OEQA. One is where the runtime tests are directly run against an image,
in which case the datastore is available. You could therefore have
markup in the recipe as normal variables and access them directly in
the tests.

The second is the "testexport" approach where the tests are run without
the main metadata. I know Ross and I would like to see testexport
dropped as it complicates things and is a pain.

This new file "feels" a lot like more extensions in the testexport
direction and I'm not sure we need to do that. Could we handle this
with more markup in the image recipe?

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173429): 
https://lists.openembedded.org/g/openembedded-core/message/173429
Mute This Topic: https://lists.openembedded.org/mt/95085492/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to