-
Notifications
You must be signed in to change notification settings - Fork 10
Open
Labels
enhancementNew feature or requestNew feature or request
Description
Trying to match what the dashboard offers I believe we can follow these steps (I listed the features in a decreasing priority order):
- Add
kci-dev issuescommand, with the following subcommands:
1.1kci-dev issues --origin <origin>that lists all issues fromorigin.
1.2kci-dev issues details --id <id>gives detailed information of the issue withid. It supports multiple--idoptions.
1.3kci-dev issues tests --id <id>lists all the tests related to the issue withid. It supports multiple--id.
1.4kci-dev issues build --id <id>lists all builds related to the issue withid. You can query multiple issues using multiple--idoptions. - Add
kci-dev hardwarecommand:
2.1kci-dev hardware list --origin <origin>that lists all available hardware fororigin.
2.2kci-dev hardware summary --id <id>gives a summary on the builds, boots and tests run of the hardware withid.
2.3kci-dev hardware boots --id <id>lists the boots for the hardware withid. The response is similar tokci-dev results boots.
2.4kci-dev hardware builds --id <id>lists the builds for the hardware withid. The response is similar tokci-dev results builds.
2.5kci-dev hardware tests --id <id>lists the tests for the hardware withid. The response is similar tokci-dev results tests. - Add
kci-dev results issuessubcommand. We can obtain this information viaapi/tree/{commit}/full, however, it would be best if there was aapi/tree/{commit]/issuesavailable, sincefullretrieves information we would just discard. - Add more options to
kci-dev results boots --filterYAML filter. The new options could be: config, compiler, architecture. - Modify
kci-dev results--archoption. It could allow filtering by various architectures by supporting multiple--arch.
Please let me know how this looks to you.
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request