Skip to content

Checklist

Christina Kang - MSFT edited this page Sep 4, 2018 · 19 revisions

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.

Documentation

  • 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.

README File

  • 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.

Testing

  • 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.
  • 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.

Dependencies

  • If adding a new dependency in <root>\src\setup.py, make sure to include it in <root>\requirements.txt as well.

Misc

Clone this wiki locally