* Microchip KernelCi contributions
@ 2020-06-02 10:20 Santiago.Esteban
2020-07-06 18:20 ` Kevin Hilman
0 siblings, 1 reply; 4+ messages in thread
From: Santiago.Esteban @ 2020-06-02 10:20 UTC (permalink / raw)
To: info
Dear KernelCi,
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?
Best Regards,
Santiago Esteban
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Microchip KernelCi contributions
2020-06-02 10:20 Microchip KernelCi contributions Santiago.Esteban
@ 2020-07-06 18:20 ` Kevin Hilman
2020-07-20 12:11 ` santiago.esteban
0 siblings, 1 reply; 4+ messages in thread
From: Kevin Hilman @ 2020-07-06 18:20 UTC (permalink / raw)
To: kernelci, Santiago.Esteban, info
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?
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Microchip KernelCi contributions
2020-07-06 18:20 ` Kevin Hilman
@ 2020-07-20 12:11 ` santiago.esteban
2020-07-20 15:14 ` Guillaume Tucker
0 siblings, 1 reply; 4+ messages in thread
From: santiago.esteban @ 2020-07-20 12:11 UTC (permalink / raw)
To: khilman, kernelci, info
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.
Best regards,
Santiago Esteban
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Microchip KernelCi contributions
2020-07-20 12:11 ` santiago.esteban
@ 2020-07-20 15:14 ` Guillaume Tucker
0 siblings, 0 replies; 4+ messages in thread
From: Guillaume Tucker @ 2020-07-20 15:14 UTC (permalink / raw)
To: kernelci, santiago.esteban, khilman
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-20 15:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-02 10:20 Microchip KernelCi contributions Santiago.Esteban
2020-07-06 18:20 ` Kevin Hilman
2020-07-20 12:11 ` santiago.esteban
2020-07-20 15:14 ` Guillaume Tucker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.