On 2/3/22 11:19 AM, Guillaume Tucker wrote:
On 02/02/2022 15:23, Shuah Khan wrote:
Hi Guillaume,
I see these 4 branches (fixes, next, kunit, kunit-fixes) are all merged into linux-next. So it seems like the best thing to do would be to cover them with a very lightweight number of builds and tests focused on what they are about: only run kselftest on the fixes and next branches, and only KUnit on kunit and kunit-fixes. At the moment, KUnit is not run by kernelci.org (coming soon) so I think we could just add the next branch for kselftest. Then linux-next will be tested with maximum coverage anyway so if something subtle gets missed with the early tests it should get caught the following day at the latest with linux-next.
Many things could potentially be done with arbitrary builds and tests etc. These are some initial suggestions. How does this sound?
Sounds good to me. The things that tend to break are:
- test builds at times due to seemingly innocuous changes to fix static analysis warnings. build test is good for catching these -
Sounds great to me. Since selftest patches flow through various subsystem trees, having kernelci keep an eye is great. This would be another pair of eyes in addition to occasional tests I run and Linaro (LKTP) monitoring next.
How often do you send reports - I will watch out for them. Thanks again for taking the initiative to add kselftest to kernelci.
Builds and tests are run every time a new revision is detected on the branches being monitored. Then when they complete, a report is sent. It can take a while, but with a small number of builds you could get results within an hour. We could get the reports sent to the linux-kselftest mailing list and your own address if you want.
Please send it to my email address as well.
Also this configuration is all under source control on GitHub so feel free to make changes to it in the future as you see fit.
Will do.
thanks, -- Shuah