From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: michael.opdenacker@bootlin.com, openembedded-core@lists.openembedded.org
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Bruce Ashfield <bruce.ashfield@gmail.com>
Subject: Re: [RFC][PATCH] oeqa/runtime/cases: new image_upgrade test
Date: Thu, 25 Apr 2024 21:40:10 +0100 [thread overview]
Message-ID: <34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org> (raw)
In-Reply-To: <20240425154607.566716-1-michael.opdenacker@bootlin.com>
Hi Michael,
At least at a first read and without running it, this does look like a
reasonable direction. I suspect that anyone else looking at this would
have a lot of questions about why we'd do it this way but given the
various constraints, it does make sense to me.
What we do need to think about is how someone else would reuse this as
currently it is very poky specific. Our aim is to make it easy for
others to use too. With that in mind:
* We probably want to "tag" this test with something so we can exclude
it from the normal oe-selftest runs on the autobuilder and allow it to
run on a per machine basis. There are other oe-selftests we already do
this with (like toolchain testing or machine specific environment file
tests).
* The configuration about what to test probably needs to come from the
distro (i.e. which DISTRO/MACHINE/image combinations).
* We probably need to parameterise it so that a list of images can be
tested rather than just a single one. I did wonder if we could have it
dynamically add tests for each image configured.
* We don't want to test on all MACHINE (e.g. qemumips and qemuppc are
not going to be included).
* We need to find a better way to share the code with autobuilder-
helper, I don't like duplicating code.
* The image url code is also highly poky specific. That probably needs
to come from the poky repository alongside the configuration.
Does that all make sense?
Cheers,
Richard
next prev parent reply other threads:[~2024-04-25 20:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 15:46 [RFC][PATCH] oeqa/runtime/cases: new image_upgrade test michael.opdenacker
2024-04-25 20:40 ` Richard Purdie [this message]
2024-04-29 15:21 ` [OE-core] " Michael Opdenacker
2024-04-29 16:14 ` Richard Purdie
2024-04-26 8:20 ` 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=34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@gmail.com \
--cc=michael.opdenacker@bootlin.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=thomas.petazzoni@bootlin.com \
/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.