CI to stop testing meta-* layers not in tested machine

[Joel Stanley]

On Fri, 14 Jun 2019 at 15:55, Benjamin Fair <benjaminfair at google.com> wrote:
> >
> > Andrew tried to build the machine and ran into u-boot issues which is
> > still blocking the machine's addition to our CI. Patrick, are you able
> > to look into that?
> >
> >  https://github.com/openbmc/openbmc/issues/3542#issuecomment-501706892
>
> That issue will be resolved by switching to a 2019-based U-Boot branch:
>
> https://gerrit.openbmc-project.xyz/c/openbmc/meta-nuvoton/+/22556

This has been merged now.

Andrew G, are we able to turn on the CI?

I think we have consensus to drop qemu, and enable gsj. There were no
objections to enabling swift too.

Cheers,

Joel

>
> >
> >
> >
> > Once we get the u-boot issue sorted out, I propose the following changes:
> >
> >  - drop qemu from CI. 'qemu' is actually testing on a generic arm
> > machine. A few of us at IBM have a side project that has resulted in a
> > high quality Qemu support for the aspeed boards, so if you would like
> > to test in qemu I recommend grabbing palmetto or romulus and doing
> > that. So consider this dropping the generic qemu image and instead
> > focusing on the aspeed one.
>
> +1
>
> Many things are already broken on QEMU, including phosphor-ipmi-host.
> It's not a useful platform to test with.
>
> >
> >  - add gsj. This gives us coverage of the nuvoton kernel and u-boot,
> > as well as the nuvoton specific layers
>
> Agreed. I'd also like to switch to (or add) a Nuvoton system with a
> host once such a machine is supported upstream. The gsj is only a
> storage tray so it doesn't test IPMI bridges, power control, etc.
>
> >
> >  - add swift. This is an ast2500-based system that we're looking to
> > use emmc flash with, and having testing for those images will be
> > useful
> >
> > Cheers,
> >
> > Joel