Re: Microchip KernelCi contributions

["Guillaume Tucker" <guillaume.tucker@collabora.com>]

On 20/07/2020 13:11, santiago.esteban via groups.io wrote:
> Hi Kevin,
> 
> I'm sorry for my late reply, but was on hollidays...
> 
> On 6/7/20 20:20, Kevin Hilman wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi Santiago,
>>
>> <Santiago.Esteban@microchip.com> writes:
>>
>>> I'm Santiago Esteban, SW Engineer at Microchip. I'm  leading the effort
>>> for continuous integration of our Linux developments. We are setting up
>>> the  infrastructure for CI in a  board farm containing several boards.
>>> We would like to contribute to the KernelCI effort with build and test
>>> data. Hopefully, as our knowledge increases we will be able to help  in
>>> some other ways.
>>>
>>>
>>> How should I prodeed?
>> How is your lab currently setup?  Are you using LAVA? If not, can you
>> tell us a bit more about how your lab is setup?  What kind of hardware
>> you're testing?
> 
> Unfortunately, we are not using LAVA, we are using a corporate Jenkins 
> server, a local development KernelCI server and Labgrid (from 
> Pengutronix) for testing the boards on the farm.
> 
> Right now, we are testing 3 different ARM Cortex-A5 SOCs (SAMA5D3, 
> SAMA5D4, SAMA5D2) and ARM9 device (SAM9X60), all SoCs and test boards 
> are mainlined. We are in the process of mainlining support for 2 new 
> devices/boards.
> 
>>
>> If using LAVA, getting integrated into KernelCI is pretty straight
>> forward.
>>
>> Some pre-requisites:
>>
>> - boards can boot an upstream Linux kernel using an upstream defconfig,
>>    (minimum: boot to a serial-console shell using a ramdisk)
>> - LAVA device-types for your boards are submitted upstream to the LAVA
>>    project
>>
>>  From there, with a basic LAVA setup/working, we just add your lab to our
>> list of labs[1] and then add your device-types in your lab to our list
>> of devices[2].
>>
>> For kernelci.org to be able to submit jobs to your LAVA lab, you'll need
>> to create a `kernel-ci` user, setup an auth token and share that token
>> with us.  Any boards that the kernel-ci LAVA user has access to,
>> kernelci.org will have access to.
>>
>> Hope that helps get you started,
>>
>> Kevin
>>
>> [1] https://github.com/kernelci/kernelci-core/blob/master/lab-configs.yaml
>> [2] https://github.com/kernelci/kernelci-core/blob/master/test-configs.yaml
>>
> As we are not using LAVA, we are using a local KCI docker setup. We are 
> able to perform builds for a selected set of repos/branches (simplified 
> version of lab-configs.yaml), test the outputs using Labgrid, and 
> publish the test results in the local KCI application.
> 
> Right now it is a simple boot test, but I'm working on a full baseline 
> test and later, in the future, add more functional tests.
> 
> I guess that in this case, I would need from you to create a lab, let's 
> say  "lab-microchip" and share the token with us (maybe starting with a 
> staging repository), so I can push our test results.

It seems like you're already automating jobs from Jenkins, so one
option would be to add Labgrid support to let KernelCI do that as
well if you want to test KernelCI builds directly.  That should
also help with running bisections.  Do you have a public-facing
web API for Labgrid that KernelCI could use to trigger jobs?

Presumably you're already sending test results to your local
kernelci-backend instance.  So another option is to keep all that
in place but also submit your results to the production
api.kernelci.org instance (or api.staging.kernelci.org initially
to try things out).  The new kci_data tool which is being
developed now should help with that.

Then of course you can also set up a LAVA lab but that would seem
overkill if you already have a working test system, unless you're
planning to stop using Labgrid and migrate to LAVA anyway.

Thanks,
Guillaume