small improvements to the cmds #55
Conversation
padovan
commented
Dec 6, 2024
padovan
commented
- improve main description phrase
- rename 'results' cmd to 'maestro-results'
We want to do more that just submit tests, so let's open up the description. Signed-off-by: Gustavo Padovan <[email protected]>
The results command is accessing the Maestro API directly for fetching results. We want to build an origin agnostic infra, so let's rename this one to 'maestro-results' for clarity. Signed-off-by: Gustavo Padovan <[email protected]>
| @@ -38,7 +38,7 @@ def run(): | |||
| cli.add_command(checkout.checkout) | |||
| cli.add_command(commit.commit) | |||
| cli.add_command(patch.patch) | |||
| cli.add_command(results.results) | |||
| cli.add_command(maestro_results.maestro_results) | |||
There was a problem hiding this comment.
@aliceinwire @nuclearcat I wonder if we shouldn't in the future have a maestro subcommand and fold all the maestro stuff as subcommands of that.
There was a problem hiding this comment.
We should not make also cli too complex. Maybe if commands will be more or less common, we can just hide it in configuration file, like --instance=maestro_production and in config it will be:
[maestro_production]
type=maestro
url=....
But if functionality will be unique, then it is different thing.
There was a problem hiding this comment.
We should not make also cli too complex.
completely agree, also we should not make terminology too complex, kci-dev need to be simple to use and "hide" all the KernelCI internal complex structure and terminology.
kci-dev users shouldn't know what is "maestro" for using kci-dev, they just need a way to get results logs from KernelCI.
I could maybe accept some sub-command like "--source="
