Currently, there are many 'list' related arguments, and some 'run' which is kind of difficult to use the tool. There are two areas to improve 1. we should collect all list related arguments and create a 'list' subcommand. 2. in case we want to run something, one should specify one of the 'run' arguments; in my opinion, we should run all tests without giving any parameter. To be more precise, these are some example command line examples that would make life easier for the user ## EXECUTION # execute all tests $ oe-selftest # execute just some tests $ oe-selftest --test a b c ## LISTING # list all tests $oe-selftest list # list some modules $ oe-selftest list --modules a b # or classes $ oe-selftest list --classes c d # or tests $ oe-selftest list --tests f g # or tags $ oe-selftest list --tags h i
Ideally, this enhancement should be started after the batch of changes being proposed by the QA team and this may not happen before M3. Moving to 2.2 for this reason.
This is a good enhancement, but I think I prefer to keep the subcommand 'run' for the EXECUTION part. I believe this works better to avoid confusion and collisions in the argument parsing. The run and list subcommands have a lot in common. They can both act on 'tests' or in 'modules' or in 'all'. If we explicitly require the 'run' subcommand to be typed, then we reduce mistakes of the user running tests when he only wanted ot list them. Also, not having an explicit 'run' subcommand would require the '--tests' and '--module' options to be members of the command parser and not of a run subparser. If we have these options outside of a subparser, then they might be confused or even collide with '--tests' and '--module' of the list subcommand. i.e. The following two commands might behave differently oe-selftest --tests a b c list oe-selftest list --tests a b c Based on my previous comments, I would prefer that we go with the following: ## EXECUTION # execute all tests $ oe-selftest run # execute just some tests $ oe-selftest run --test a b c ## LISTING # list all tests $oe-selftest list # list some modules $ oe-selftest list --modules a b # or classes $ oe-selftest list --classes c d # or tests $ oe-selftest list --tests f g # or tags $ oe-selftest list --tags h i
Sent patch http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123860.html
Sent v2 http://lists.openembedded.org/pipermail/openembedded-core/2016-August/124648.html
Sent v3 http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125784.html https://lists.yoctoproject.org/pipermail/yocto/2016-August/031736.html
Sent v4 http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126061.html https://lists.yoctoproject.org/pipermail/yocto/2016-September/031823.html
Forgot to sign off one of the patches https://lists.yoctoproject.org/pipermail/yocto/2016-September/031826.html
Sent v4 for the autobuilder patch https://lists.yoctoproject.org/pipermail/yocto/2016-September/031834.html
According to RP, this patch is a bit risky to be merged in 2.2 M3, so moving to next relase M1.
Humberto, what is the status of this bug? Are the proposed patches merged?
Humberto was working on this re-design of the command line, since the patches from the new OEQA framework arrived and the command line still is the same for compatibility reasons, i don't see any need to rebase this patches. I will close this bug, objections?
No objections here - I think we can make minor tweaks, but this kind of reworking of the command line interface isn't something I think we would do at this time.
(In reply to comment #12) > No objections here - I think we can make minor tweaks, but this kind of > reworking of the command line interface isn't something I think we would do > at this time. So, closed now.