[U-Boot] Sharing a hardware lab

[Tom Rini <trini@konsulko.com>]

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@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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200207/d9598c74/attachment.sig>