Checklist

This checklist lists items to check before submitting a pull request:

Usability

Minimize JSON inputs where possible. If the command inputs can be split up into simple types, such as strings and integers, then do so.

Ensure that the PR has a descriptive summary.
Update the <root>\CODEOWNERS file as appropriate. Instruction for how to add is included in the file itself.
For each new command / command group added, make sure appropriate documentation is added to the corresponding help file. For commands, this is only required if you have a swagger command override (a custom command). Each new group of commands added always needs custom help text.
If your command has a custom help text section, check that the content is still current.
Custom commands should provide examples in the help files unless inputs are very simple and obvious.
With any inputs which are not overly obvious, please provide examples in the help files. See knack documentation for instructions on adding examples.
All newly added methods should include detailed documentation for its use cases, including what the arguments represent, their types, and the return values and types.

Update the <root>\src\README.rst file to summarize the changes included in the pull request. If required by semantic versioning, include change logs under a new version. Include the PR number at the end of each entry, with format New feature (#70) where 70 is the pull request number.
In the <root>\src\README.rst file, all new entries that are not published yet should be marked as 'Unreleased'.
Do not add a period at the end of the line.
Use present tense.

Any new functionality should include testing. Tests that require a live cluster connection are optional, and should be avoided if possible.
Non live testing is required. Suggested testing includes unit testing, as well as paths generation test, which can be found in <root>\src\sfctl\tests\request_generation_test.py. Each command should have a corresponding test in request_generation_test, not only custom commands. Make sure to include all the possible parameters in this test. Create more than one call to validate_command if required.
Any new commands, command groups, or commands whose names have been changed, should include a test in the file <root>\src\sfctl\tests\help_text_test.py. This test helps ensure that the help text is present and displayed correctly.
Make sure that all test assert calls include an explanatory message for ease of debugging errors.
Test method names must start with test_. Otherwise, they will not be picked up by nose2 test finder. However, test file names can end in _test.py.
If you've added new tests, make sure that the automated testing is finding the new tests.

If adding a new runtime dependency, make sure it is listed in <root>\src\setup.py. If adding a test dependency, make sure to include it in <root>\requirements.txt.