From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Michael Opdenacker <michael.opdenacker@bootlin.com>
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:14:39 +0100 [thread overview]
Message-ID: <e4e8979aa535015bafe2b06fdea6078b46f417bf.camel@linuxfoundation.org> (raw)
In-Reply-To: <5a6d6cce-e996-47ef-bb3e-92c66939395a@bootlin.com>
On Mon, 2024-04-29 at 17:21 +0200, Michael Opdenacker wrote:
> 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?
What needs to happen is the code needs to be moved into meta/lib/oe, or
probably better, meta-poky/lib/oe in meta-yocto and then autobuilder-
helper needs to understand how to access it from there.
That is probably beyond what we have time for with the current work :(
> > * 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.
Some assumptions about the url format will have to be made. I still
maintain this code should be in meta-yocto since it is poky specific
but should call code with only the configuration coming from poky/meta-
yocto.
Cheers,
Richard
next prev parent reply other threads:[~2024-04-29 16:14 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 ` [OE-core] " Michael Opdenacker
2024-04-29 16:14 ` Richard Purdie [this message]
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=e4e8979aa535015bafe2b06fdea6078b46f417bf.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.