Add feature kernelci-try

[aliceinwire]

Add a feature similar to buildbot try where Kernel developers provided of a API key can push request for builds to the KernelCI current running environment from the command line. Also add the possibility of pushing local kernel source changes.

[aliceinwire]

Following this issue I propose to create a tool called kci-dev

$ kci-dev --help
kci-dev -- tool for developer for test local tree with local changes against a enabled KernelCI server

where:
    --connect=[ssh,api] define the way to connect to KernelCI server
    --repository        define the kernel upstream repository where to test local changes
    --branch            define the repository branch
    --publish           define if the test results will be published
    --dir               define the directory of the local tree with local changes

This file will also accept a .kci-dev.yaml configuration file for define password and api keys The changes can also be sent from a own repository fork, in such case the upstream repository will be the fork owned.

[nuclearcat]

Hi! Thats exactly what we are working on this milestone. We implemented already resubmission for different kernel branch commit, i will implement also lab test retry logic and then we will move on discussing how to implement this tool. I will update issue with follow up on design, before implementing it.

[aliceinwire]

@nuclearcat which milestone are you talking about, there is any way I can help out?

[pawiecz]

@aliceinwire The milestone @nuclearcat mentioned is a public roadmap/development plan, e.g. M3 document

Kernel developers provided of a API key can push request for builds to the KernelCI current running environment from the command line.

This should be already possible for monitored trees/branches by submitting custom Node to the API

Also add the possibility of pushing local kernel source changes.

That's also supported using patchset Node type. Current CLI might not support it yet, though (so there's a room for improvement)

[aliceinwire]

what about the publish feature that permit to decide to publish or don't publish results

    --publish           define if the test results will be published

[aliceinwire]

This should be already possible for monitored trees/branches by submitting custom Node to the API

do you mean by using the KernelCI-api ? I tried doing it with the help of @nuclearcat but looks like it was not a feature that KernelCI-api can provide.

That's also supported using patchset Node type. Current CLI might not support it yet, though (so there's a room for improvement)

?

[nuclearcat]

@nuclearcat which milestone are you talking about, there is any way I can help out? We're currently planning our work for the coming weeks and prioritizing new tasks, including:

• Issue 403
• Issue 509
• Issue 334
• Issue 664

We may add more issues based on logical and demanded features (including this one). Additional ideas will be gathered during our upcoming weekly meeting.

Once planning is complete, we'll publish a Milestone document outlining the defined tasks. We'll strive to complete these tasks within the milestone, but some may extend beyond due to external dependencies or underestimated complexity.

[pawiecz]

That's also supported using patchset Node type. Current CLI might not support it yet, though (so there's a room for improvement)

?

API supports Nodes with patches stored as artifacts. Kernel sources that given Node references together with these patches are later packaged into tarball for further processing.

By CLI I meant kci tool which should be extended to cover patchset-related use cases.