Allow users to specify system, test, and obtain a test machine
[I opened a similar request two years ago. I am creating a new request based on LNST functionality and hopefully this will be prioritized so that it can be resolved and implemented quickly.]
One of the major issues with CKI testing is that I cannot easily reproduce a test. Often, this requires fumbling through URLs to find test repositories, figuring out dependencies for those repositories, crossing your fingers and praying to the multi-tentacled Linux gods that you've done the right thing. Eventually I and most of us give up and just re-run CKI in it's entirety rather than focusing on a single test.
LNST has a very elegant solution here:
The above link is provided without any context because it is so simple to understand and use.
The above link allows a user to specify a brew kernel [1] and a test. The result of this is that the user is provided a system to reproduce the test on [2], a simple ./reproducer.sh script that can be executed to run the test. This allows a user to have a test bed in which they can easily reproduce CKI testing failures.
This functionality from LNST be implemented in CKI testing. It is unacceptable that the functionality exists in LNST and does not exist in CKI.
Reproducing a bug in LNST was trivial. It was the best thing that I've used in a while -- the interface, as you can see, is easy to use and understand for even beginner level users. Don't overthink this, IMO just replicate the ease of use that the LNST interface has.
What if the reproduction of the bug requires a specific system? See [2] below, and yes, that may result in a slow down of testing in CKI. If that occurs, we can address the situation by adding new hardware or adding existing systems to the list of systems CKI can use.
[1] The functionality being requested in this issue must be expanded to allow a user to specify a repo for self-built kernels.
[2] The functionality being requested in this issue must be expanded to allow a user to specify a system in beaker on which they want to test. Given the heavy use of systems by CKI and if the system is in the general pool of systems CKI runs on, I believe the reservation should only occur for 8 hours -- one workday. If a user requires the system again then they can re-request the system via the interface. In this way we will have at most a one workday delay in the queue for that system.