Hi Stephen, On Wed, 5 Feb 2020 at 11:21, Stephen Warren <swar...@wwwdotorg.org> wrote: > > On 2/5/20 7:10 AM, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 4 Dec 2019 at 15:30, Tom Rini <tr...@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.
OK thanks, that explains it. Tom, I added a kea-sandbox runner - is it possible to try that as a public group runner? Regards, Simon