|
| 1 | +This checklist is used to make sure that common issues in a pull request are covered by the creator. You can find a more complete discussion of PowerShell cmdlet best practices [here](https://msdn.microsoft.com/en-us/library/dd878270(v=vs.85).aspx). |
| 2 | + |
| 3 | +Below in **Overall Changes**, check off the boxes that apply to your PR. Within each of the categories that you select, make sure that you can check off **all** of the boxes. |
| 4 | + |
| 5 | +## Overall Changes |
| 6 | +- [ ] [**MANDATORY** - General changes](#general) |
| 7 | +- [ ] [**MANDATORY** - Add/remove/edit test(s)](#tests) |
| 8 | +- [ ] [Add/remove/edit cmdlet(s)](#cmdlet-signature) |
| 9 | +- [ ] [Add/remove/edit parameter(s)](#parameters) |
| 10 | +- [ ] [Edit pipeline parameters](#parameters-and-the-pipeline) |
| 11 | + |
| 12 | +### General |
| 13 | +- [ ] Title of the PR is clear and informative |
| 14 | +- [ ] There are a small number of commits that each have an informative message |
| 15 | +- [ ] If it applies, references the bug/issue that the PR fixes |
| 16 | +- [ ] All files have the Microsoft copyright header |
| 17 | +- [ ] Cmdlets refer to management libraries through nuget references - no dlls are checked in |
| 18 | +- [ ] The PR does not introduce breaking changes (unless a major version change occurs in the assembly and module) |
| 19 | + |
| 20 | +### Tests |
| 21 | +- [ ] PR includes test coverage for the included changes |
| 22 | +- [ ] Tests must use xunit, and should either use Moq to mock management client calls, or use the scenario test framework |
| 23 | +- [ ] PowerShell scripts used in tests must not use hard-coded values for location |
| 24 | +- [ ] PowerShell scripts used in tests should do any necessary setup as part of the test or suite setup, and should not use hard-coded values for existing resources |
| 25 | +- [ ] Tests should not use App.config files for settings |
| 26 | +- [ ] Tests should use the built-in PowerShell functions for generating random names when unique names are necessary - this will store names in the test recording |
| 27 | +- [ ] Tests should use Start-Sleep to pause rather than Thread.Sleep |
| 28 | + |
| 29 | +### Cmdlet Signature |
| 30 | +- [ ] Cmdlet name uses an approved PowerShell verb - use the enums for `VerbsCommon`, `VerbsCommunication`, `VerbsLifecycle`, `VerbsOther` whenever possible |
| 31 | +- [ ] Cmdlet noun name uses the AzureRm prefix for management cmdlets, and the Azure prefix for data plane cmdlets |
| 32 | +- [ ] Cmdlet specifies the `OutputType` attribute if any output is produced; if the cmdlet produces no output, it should implement a `PassThrough` parameter |
| 33 | +- [ ] If the cmdlet makes changes or has side effects, it should implement `ShouldProcess` and have `SupportShouldProcess = true` specified in the cmdlet attribute. See a discussion about correct `ShouldProcess` implementation [here](https://gist.github.com/markcowl/338e16fe5c8bbf195aff9f8af0db585d#what-is-the-change) |
| 34 | +- [ ] Cmdlets should derive from AzureRmCmdlet for management cmdlets, and AzureDataCmdlet for data cmdlets |
| 35 | +- [ ] If multiple parameter sets are implemented, the cmdlet should specify a `DefaultParameterSetName` in its cmdlet attribute |
| 36 | + |
| 37 | +### Parameters |
| 38 | +- [ ] Cmdlets should have no more than four positional parameters |
| 39 | +- [ ] Cmdlet parameter sets should be mutually exclusive - each parameter set must have at least one mandatory parameter not in other parameter sets |
| 40 | +- [ ] Parameter types should not expose types from the management library - complex parameter types should be defined in the module |
| 41 | +- [ ] Complex parameter types are discouraged - a parameter type should be simple types as often as possible. If complex types are used, they should be shallow and easily creatable from a constructor or another cmdlet |
| 42 | +- [ ] Parameters should be explicitly marked as Mandatory or not, and should contain a HelpMessage |
| 43 | +- [ ] No parameter is of type `object`. |
| 44 | + - Management cmdlets should have the following parameters and aliases: |
| 45 | + - ResourceGroupName with (optional) alias to `ResourceGroup` type string marked as [ValueFromPipelineByPropertyName] |
| 46 | + - Name with alias to `ResourceName` type string marked as [ValueFromPipelineByPropertyName] |
| 47 | + - Location (if appropriate) type string |
| 48 | + - Tag, type `HashTable` |
| 49 | + |
| 50 | +### Parameters and the Pipeline |
| 51 | +- [ ] Complex parameters should take values from the pipeline when possible, and certainly when they match the output type of another cmdlet |
| 52 | +- [ ] Only one parameter should use ValueFromPipeline per parameter set; parameters from different parameter sets may have this attribute, but should not be convertible |
| 53 | +- [ ] No parameter is of type `object` |
| 54 | +- [ ] Each management cmdlet should have a parameter set that takes `ResourceGroupName` and `Name` from the pipeline by property value |
| 55 | +- [ ] For a given resource type, it should be possible to pipe the output of `Get` and `New` cmdlets to the input of `Set`, `Update`, `Remove` and other action cmdlets for that resource |
0 commit comments