From: Michael Opdenacker <michael.opdenacker@bootlin.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Bruce Ashfield <bruce.ashfield@gmail.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [RFC][PATCH] oeqa/runtime/cases: new image_upgrade test
Date: Mon, 29 Apr 2024 17:21:42 +0200 [thread overview]
Message-ID: <5a6d6cce-e996-47ef-bb3e-92c66939395a@bootlin.com> (raw)
In-Reply-To: <34a52efaf6a38753f773d5dd6b3cc4d6fe3c91ec.camel@linuxfoundation.org>
Hi Richard,
Many thanks for your feedback.
I started by implementing Alex Kanavin's suggestions, which are a little
more specific to get started ;-)
On 4/25/24 at 22:40, Richard Purdie wrote:
> 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.
Is there example code somewhere doing something similar, i.e. importing
code from an external repository?
>
> * The image url code is also highly poky specific. That probably needs
> to come from the poky repository alongside the configuration.
I'm going to submit a new version that doesn't assume any specific URL
scheme.
More soon.
Thanks,
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2024-04-29 15:21 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
2024-04-29 15:21 ` Michael Opdenacker [this message]
2024-04-29 16:14 ` [OE-core] " 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=5a6d6cce-e996-47ef-bb3e-92c66939395a@bootlin.com \
--to=michael.opdenacker@bootlin.com \
--cc=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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.