[U-Boot] Sharing a hardware lab

[Simon Glass]

Hi Tom,

On Fri, 7 Feb 2020 at 15:22, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Feb 05, 2020 at 11:21:41AM -0700, Stephen Warren wrote:
> > On 2/5/20 7:10 AM, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 4 Dec 2019 at 15:30, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > I have been meaning to have a crack at setting up a little hardware
> > > > > lab for a while.
> > > > >
> > > > > I made some progress recently and hooked up a rpi_3 with sdwire for
> > > > > USB/SD, ykush for power and a little computer to control it. It builds
> > > > > U-Boot, sticks it on the SD card and runs pytest.
> > > > >
> > > > > I pushed a tree here and hopefully you can see the 'hwlab' thing at the end:
> > > > >
> > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148
> > > > >
> > > > > So far it is just running the 'help' test. It seems to hang with
> > > > > serial console problems if I try to do more. It is not 100% reliable
> > > > > yet. I based it on Stephen's test hooks:
> > > > >
> > > > > https://github.com/sglass68/uboot-test-hooks
> > > > >
> > > > > Is it possible to share this so that others can use the lab when they
> > > > > push trees? Is it as simple as adding to the .gitlab-ci.yml file as I
> > > > > have done here?
> > > > >
> > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml
> > > > >
> > > > > I also got tbot going in a similar way, to test booting into Linux.
> > > > > Should we look at integrating that at the same time? It should be
> > > > > fairly easy to do.
> > > > >
> > > > > I have quite a lot of random boards and in principle it should not be
> > > > > too hard to hook up some more of them, with sufficient SDwires, hubs
> > > > > and patience.
> > >
> > > Bumping this thread as I have now hooked up about about 8 mostly ARM
> > > and x86 boards and have tbot and pytest automation mostly working for
> > > them.
> > >
> > > >
> > > > There's two parts of this.  The first part I think is that we need some
> > > > good examples of how to have one private CI job poll / monitor other
> > > > public jobs and run.  I believe some labs do this today.  This would be
> > > > helpful as at least personally I'm kicking my hardware tests manually.
> > > > This is because as best I can tell there isn't a way to include an
> > > > optional stage/portion of a CI job.
> > >
> > > So the model here is that people with a lab 'watch' various repos? I
> > > think that would be useful. Stephen Warren does this I think, but I'm
> > > not sure how the builds are kicked off.
> >
> > Yes, my Jenkins instance directly polls the relevant git repos/branches for
> > changes, then do a full build and test cycle, so is independent of anything
> > else.
> >
> > Well actually, I mirror the git repos locally and Jenkins polls the mirrors,
> > so that when I run n builds, the upstream git serves only get hit once for
> > the mirroring operation, and not once per build, but that's an
> > implementation detail.
>
> I'm of the opinion that labs that poll are probably better of an idea
> than trying to make something public and known visible to the world.
> Thanks!

It's certainly a start.

But I think there is real value in adding this to gitlab because the
committers can actually see and diagnose the failure themselves and it
becomes part of the normal test flow, rather than something that is
noticed later.

Regards,
Simon