action #162158
open[qe-core] New openqa-cli implementation
0%
Description
What?¶
Currently we rely on a bunch of bash (or perl) script wrappers around the original openqa-cli to perform certain actions such as scheduling tests, cloning tests from a PR or commit, performing database migrations etc.
This is all very loosely connected - if at all - which makes it confusing for new users and first time contributors to find their way around, as they do not have one point of contact with openQA.
Therefore, the goal of this ticket is to implement a new CLI frontend for openQA with a modern, consolidated structure.
To allow for feature parity with the current solution and ease the replacement sometime in the future, including as much of the current system's functionality
into this new CLI system is a primary objective.
Goal¶
A well documented, modern, expandable CLI system with a clearly structured usage is the ultimate goal. Providing users and developers alike with a
single source of contact would make interactions much more clear, improve maintainability and avoid confusion when troubleshooting issues during usage of openQA.
Also, by using a modern language with frameworks like argparse (Python), click (Python) or clap (Rust), we can ensure that the new CLI system is a modular one; Making the addition of new commands, arguments or flags to the existing structure relatively trivial.
It would also be easier to implement and maintain coding standards in the CLI component of openQA and make contributing more appealing to a wider range of outside contributors as - let's face it - Perl is not the most popular language anymore.
Checklist
-
Analyze the full feature set of the current
openqa-cliincluding all wrappers - Create a separate project (in Python using PyPerl, or Rust using ruperl) to hold the new CLI as a separate module for the time being
- Recreate basic functionality of the openQA cli
- Categorize existing wrappers by functionality to group them under a sub command where applicable
- Merge and consolidate the functionality of the wrappers as subcommands
- Document functionality in the code
- Document usage in doc-files and online
- Implement full test suite
- Integrate with existing openQA codebase
Updated by okurz 18 days ago
chock wrote:
Therefore, the goal of this ticket is to implement a new CLI frontend for openQA with a modern, consolidated structure.
Sounds nice but I would be very careful with that. In the past we had "openqa-client" and a new implementation "openqa-cli" was already created and we had a painful migration. Often to get any "rewrite" really replacing the legacy tooling is more effort than anticipated. It can of course still be done and you stated a lot of nice and valid ideas but one must not be frustrated if users need extra convincing to use anything new rather than the still existing old :)
Updated by chock 18 days ago ยท Edited
okurz wrote in #note-1:
Sounds nice but I would be very careful with that. In the past we had "openqa-client" and a new implementation "openqa-cli" was already created and we had a painful migration. Often to get any "rewrite" really replacing the legacy tooling is more effort than anticipated. It can of course still be done and you stated a lot of nice and valid ideas but one must not be frustrated if users need extra convincing to use anything new rather than the still existing old :)
I see that. People like the workflow they are comfortable with - I am guilty of that myself - still, I think that this is a necessary step for the future. It's also nothing that can be achieved in a couple of months, but rather a scope of 1 or 2 years to get everything the way its supposed to and begin a period of transitioning to the new system. By consolidating all those wrappers' functionality I also hope that a migration will be as painless for everyone as possible.