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

[Andrew Geissler]

On Fri, May 10, 2019 at 9:33 AM Patrick Venture <venture at google.com> wrote:
>
> From: Joel Stanley <joel at jms.id.au>
> Date: Thu, May 9, 2019 at 6:11 PM
> To: Andrew Geissler, Benjamin Fair
> Cc: OpenBMC Maillist
>
> > On Thu, 14 Mar 2019 at 13:39, Andrew Geissler <geissonator at gmail.com> wrote:
> > >
> > > I took an action item from last weeks Infrastructure Workgroup.
> > >
> > > The point was we're wasting CI resources by testing meta-*
> > > commits that are not actually tested by any of the machines in the
> > > CI job. We're also falsely marking those commits as Verified because
> > > if they are not in any of the systems under test, they're not being
> > > tested at all.
> > >
> > > The systems currently run as a part of the meta-* CI jobs are here:
> > > https://openpower.xyz/view/CI/job/run-meta-ci/
> >
> > > Are there any advantages to running CI against meta-* layers that
> > > are not in a machine being built? Are there other machines we can
> > > add to CI that would cover some of the meta layers above? The
> > > general criteria for getting a machine added to CI is that it's actively
> > > being developed and supported. We also need to balance our
> > > CI compute resources so the overall goal (in my mind) would be
> > > to pick the machines that cover the most meta layers.
> >
> > I'd like to have a nuvoton based machine so we have some confidence
> > that kernel bumps aren't broken.
> >
> > That would mean adding the evb-nuvoton or gsj machines to CI.
>
> I vote for the gsj machine.  Not that it's a democracy :)

I gave this a try but ran into https://github.com/openbmc/openbmc/issues/3542
Be great to get gsj into CI since it would give us a few new layers
for coverage.

google provides a good chunk of the CI build infrastructure for OpenBMC so
you definitely get a vote :)

Andrew

>
> >
> > Cheers,
> >
> > Joel