QA » openQA Project

• This use-case is also impaired by the inability to use custom needles (https://progress.opensuse.org/issues/56789 #56789).
• Besides, the implementation suggestion use SCHEDULE parameter with e.g. SCHEDULE=tests/boot/boot_to_desktop,tests/run_custom implies that a composability of test distributions would be required. This is of course possible by somehow embedding the base test distribution (e.g. os-autoinst-distri-opensuse) into the product repository (e.g. cobbler) adding own tests on top of it. But this sounds rather hacky and inconvenient to use. So having a light test distribution which can simply be referred to as "base test distribution" seems a desirable for this use-case.

These points are likely the tricky part. Triggering the test execution itself is likely not that hard. Instead of writing a "polling bot" I would add an API route in openQA which can be added as GitHub hook.

mkittler wrote:

• This use-case is also impaired by the inability to use custom needles (https://progress.opensuse.org/issues/56789 #56789).

Maybe we can still consider any need for needles an independant requirement of the part about triggering test code which I find more important.

Regarding the "hacky approach" or "base test distribution" I think we have a ticket for having something like a "linux" middleware between os-autoinst and os-autoinst-distri-opensuse that can be extracted but for now and to have a proof-of-concept on which to improve upon I recommend the "hacky" approach

[…] I would add an API route in openQA which can be added as GitHub hook.

What would you add as an API route here?