Updated comment-based help .INPUTS and .OUTPUTS sections#2358
Updated comment-based help .INPUTS and .OUTPUTS sections#2358johlju merged 68 commits intodsccommunity:mainfrom
.INPUTS and .OUTPUTS sections#2358Conversation
WalkthroughStandardized comment-based PowerShell help across the repository: inserted/reordered .INPUTS and .OUTPUTS sections, formatted type names with backticks, normalized punctuation (e.g., "None."), and added a small number of Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Pre-merge checks✅ Passed checks (5 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (11)
source/Private/ConvertTo-RedactedText.ps1 (1)
43-44: Add missing[OutputType()]attribute to match .OUTPUTS documentation.The function has a
.OUTPUTSsection documentingSystem.Stringas the return type, but lacks the corresponding[OutputType([System.String])]attribute. Per guidelines,.OUTPUTSmust match both the[OutputType()]attribute and actual returns.Apply this diff:
function ConvertTo-RedactedText { [CmdletBinding()] + [OutputType([System.String])] paramsource/Private/ConvertTo-ManagedServiceType.ps1 (1)
28-37: Add missing[OutputType()]attribute to match documented return type.The function's
.OUTPUTSsection documents a return type ofMicrosoft.SqlServer.Management.Smo.Wmi.ManagedServiceType, but the function lacks the corresponding[OutputType()]attribute. Per the DSC Community guidelines, the[OutputType()]must match both the documented return type and the actual return statement (line 101).Apply this diff to add the
[OutputType()]attribute:function ConvertTo-ManagedServiceType { [CmdletBinding()] + [OutputType([Microsoft.SqlServer.Management.Smo.Wmi.ManagedServiceType])] paramBased on learnings, the
.OUTPUTSsection and[OutputType()]attribute must be consistent with the actual return value.source/Public/Assert-SqlDscLogin.ps1 (1)
40-53: Add missing[OutputType()]attribute.The function declaration lacks a
[OutputType()]attribute. Per coding guidelines, this attribute is required for all functions and must match the documented.OUTPUTSsection. Since the function outputsNone, add[OutputType()](empty brackets) immediately after[CmdletBinding()].Apply this diff:
function Assert-SqlDscLogin { [System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('UseSyntacticallyCorrectExamples', '', Justification = 'Because the rule does not yet support parsing the code when a parameter type is not available. The ScriptAnalyzer rule UseSyntacticallyCorrectExamples will always error in the editor due to https://github.com/indented-automation/Indented.ScriptAnalyzerRules/issues/8.')] [CmdletBinding()] + [OutputType()] paramsource/Public/Import-SqlDscPreferredModule.ps1 (1)
51-52: Add the[OutputType()]attribute to match the documented behavior.Since the function returns no output (as correctly documented in the
.OUTPUTSsection), it should include[OutputType()]to align with DSC Community guidelines.Apply this diff to add the missing attribute:
function Import-SqlDscPreferredModule { [CmdletBinding()] + [OutputType()] paramsource/Public/Disconnect-SqlDscDatabaseEngine.ps1 (1)
36-36: Critical:[OutputType()]attribute doesn't match actual function behavior.The attribute declares
System.Data.DataSetas the output type, but this function performs a disconnect operation and returns nothing. The.OUTPUTS None.comment-based help is correct. Per the coding guidelines, "OUTPUTS must match both[OutputType()]and actual returns."Apply this diff to correct the attribute:
- [OutputType([System.Data.DataSet])] + [OutputType()]source/Public/Test-SqlDscIsLoginEnabled.ps1 (1)
27-27: Use backticks for inline code formatting in.INPUTStypes.The input type names are using square brackets
[TypeName]instead of backticks`TypeName`for inline code notation. According to the PR objectives and issue #2103, types should be formatted as inline code with backticks, consistent with the.OUTPUTSsection on line 36.Apply this diff to fix the formatting:
- [Microsoft.SqlServer.Management.Smo.Server] + `Microsoft.SqlServer.Management.Smo.Server`- [Microsoft.SqlServer.Management.Smo.Login] + `Microsoft.SqlServer.Management.Smo.Login`Also applies to: 31-31
source/Public/Add-SqlDscFileGroup.ps1 (2)
23-26: Format the input type as inline code.The
.INPUTSsection should format the type with backticks to match the inline code requirement from issue #2103 and the DSC Community style guidelines.Apply this diff:
.INPUTS - Microsoft.SqlServer.Management.Smo.FileGroup + `Microsoft.SqlServer.Management.Smo.FileGroup` FileGroup objects that will be added to the Database.
33-36: Format the output type as inline code.The second
.OUTPUTSsection should format the type with backticks to match the inline code requirement from issue #2103 and the DSC Community style guidelines.Apply this diff:
.OUTPUTS - Microsoft.SqlServer.Management.Smo.FileGroup[] + `Microsoft.SqlServer.Management.Smo.FileGroup[]` When the PassThru parameter is specified, returns the FileGroup objects that were added.source/Public/Test-SqlDscIsAgentAlert.ps1 (1)
15-18: Apply inline code formatting to INPUTS type.The INPUTS type should be formatted as inline code with backticks to align with the DSC community style guidelines and match the OUTPUTS formatting in this file.
Apply this diff:
.INPUTS - Microsoft.SqlServer.Management.Smo.Server + `Microsoft.SqlServer.Management.Smo.Server` SQL Server Database Engine instance object.Based on coding guidelines.
source/Public/Get-SqlDscAgentAlert.ps1 (2)
15-18: Apply inline code formatting to INPUTS type.The INPUTS type should be formatted as inline code with backticks to align with the DSC community style guidelines.
Apply this diff:
.INPUTS - Microsoft.SqlServer.Management.Smo.Server + `Microsoft.SqlServer.Management.Smo.Server` SQL Server Database Engine instance object.Based on coding guidelines.
20-28: Apply inline code formatting to OUTPUTS types.The OUTPUTS types should be formatted as inline code with backticks to align with the DSC community style guidelines.
Apply this diff:
.OUTPUTS - Microsoft.SqlServer.Management.Smo.Agent.Alert + `Microsoft.SqlServer.Management.Smo.Agent.Alert` When using the ByName parameter set, returns a single SQL Agent Alert object. .OUTPUTS - Microsoft.SqlServer.Management.Smo.Agent.Alert[] + `Microsoft.SqlServer.Management.Smo.Agent.Alert[]` When using the All parameter set, returns an array of SQL Agent Alert objects.Based on coding guidelines.
🟠 Major comments (18)
source/Public/Install-SqlDscBIReportServer.ps1-63-65 (1)
63-65: OUTPUTS section does not follow required format and is incomplete.The current
.OUTPUTSsection violates the formatting requirements in two ways:
- Format violation: Description should be inline code (backticks) followed by a one-line description, not narrative prose spanning multiple lines.
- Incomplete coverage: The function has conditional output behavior—it returns
System.Int32whenPassThruis specified, and returns$null(no output) otherwise. Per the learnings and PR objectives, each distinct return type must have its own.OUTPUTSentry with a description of when that type is returned.Apply this diff to correct the format and coverage:
.OUTPUTS - When PassThru is specified the function will return the setup process exit - code as System.Int32. Otherwise, the function does not generate any output. + `System.Int32` + + The exit code from the setup process when PassThru is specified. + + .OUTPUTS + None. + + No output is generated when PassThru is not specified.Based on learnings, this aligns with the DSC Community style where each distinct return type (or absence thereof) receives its own
.OUTPUTSentry.source/Public/Get-SqlDscAgentOperator.ps1-30-33 (1)
30-33: Remove the "None." entry from OUTPUTS documentation—it doesn't match the [OutputType()] declarations.The comment-based help declares three output scenarios (lines 30-33), but the
[OutputType()]attributes (lines 56-57) only declare two:Microsoft.SqlServer.Management.Smo.Agent.OperatorandMicrosoft.SqlServer.Management.Smo.Agent.Operator[]. Per the coding guidelines, OUTPUTS must match both[OutputType()]and actual returns. A function that returns$nullin the ByName case still returns theOperatortype (nullable), not "nothing"—so the "None." entry is incorrect. Delete lines 30-33 and adjust the OUTPUTS entries for the two actual return types with repeating.OUTPUTSkeywords and 1-line descriptions per the style guidelines.source/Public/Get-SqlDscManagedComputerService.ps1-54-55 (1)
54-55: Add description to .OUTPUTS section.The
.OUTPUTSblock documents the return type but is missing the required 1-line description. Per DSC community style guidelines, each output type must have an accompanying description on the following line(s).Apply this diff to add the missing description:
.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.Wmi.Service[]]` + `[Microsoft.SqlServer.Management.Smo.Wmi.Service[]]` + + An array of managed computer service objects.source/Public/Get-SqlDscManagedComputer.ps1-26-27 (1)
26-27: Add description to .OUTPUTS section.The
.OUTPUTSblock documents the return type but is missing the required 1-line description. Per DSC community style guidelines, each output type must have an accompanying description on the following line(s).Apply this diff to add the missing description:
.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer]` + `[Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer]` + + A managed computer object representing the SQL Server instance.source/Public/Remove-SqlDscRole.ps1-47-50 (1)
47-50: Add missing pipeline input type.The
.INPUTSsection is incomplete. The function accepts two types via the pipeline:
Microsoft.SqlServer.Management.Smo.Server(documented)Microsoft.SqlServer.Management.Smo.ServerRole(missing)Per the guidelines, repeat the
.INPUTSkeyword for each input type.Apply this diff to add the missing input type:
.INPUTS `Microsoft.SqlServer.Management.Smo.Server` Accepts input via the pipeline. + .INPUTS + `Microsoft.SqlServer.Management.Smo.ServerRole` + + Accepts input via the pipeline. + .OUTPUTSsource/Public/Test-SqlDscServerPermission.ps1-48-51 (1)
48-51: Fix indentation and incomplete documentation for INPUTS and OUTPUTS sections.There are three issues with the comment-based help formatting:
Line 48: The
.OUTPUTSkeyword is not properly indented. It should have 4 spaces of indentation to align with.INPUTSon line 43.Lines 43-46: The
.INPUTSsection only documents theMicrosoft.SqlServer.Management.Smo.Logintype, but the function also acceptsMicrosoft.SqlServer.Management.Smo.ServerRolevia pipeline (lines 96-99). Per guidelines, each pipeline-accepted type must have its own.INPUTSentry with the keyword repeated.Line 51: The description "Returns the output object" is too generic. It should clearly state what the boolean return value represents, e.g., whether permissions are in the desired state.
Apply this diff to fix the formatting and documentation:
.PARAMETER ExactMatch Specifies that the test should verify that only the specified permissions are present and no additional permissions exist in the specified state. When this parameter is not used, the test will return true if the specified permissions are present, regardless of any additional permissions. .INPUTS `Microsoft.SqlServer.Management.Smo.Login` Accepts input via the pipeline. + .INPUTS + `Microsoft.SqlServer.Management.Smo.ServerRole` + + Accepts input via the pipeline. + .OUTPUTS `System.Boolean` - Returns the output object. + Returns $true if the permissions are in the desired state; otherwise $false.Committable suggestion skipped: line range outside the PR's diff.
source/Public/New-SqlDscDatabase.ps1-343-344 (1)
343-344: OUTPUTS section formatting needs correction per PR objective #2103.The existing OUTPUTS section should follow the same formatting pattern as the INPUTS section you just added. Currently:
- The type reference includes brackets inside backticks:
[Microsoft.SqlServer.Management.Smo.Database]- A description line is missing after the type
Per the PR objective and coding guidelines, the format should mirror the INPUTS pattern: type in backticks without brackets, followed by a description line.
Apply this diff to correct the OUTPUTS section formatting:
.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.Database]` + `Microsoft.SqlServer.Management.Smo.Database` + + The newly created database object.source/Public/ConvertTo-SqlDscFileGroup.ps1-20-21 (1)
20-21: Format the output type as inline code.The
.OUTPUTSsection should format the type with backticks to match the inline code requirement from issue #2103 and the DSC Community style guidelines. Since this PR is updating INPUTS/OUTPUTS formatting across the codebase, this file should be updated consistently.Apply this diff to add backticks around the type:
.OUTPUTS - Microsoft.SqlServer.Management.Smo.FileGroup + `Microsoft.SqlServer.Management.Smo.FileGroup` + + Returns a FileGroup object configured with the specified properties and data files.source/Public/Uninstall-SqlDscBIReportServer.ps1-32-38 (1)
32-38: Fix indentation and format.OUTPUTSwith inline code for each return type.Same issues as noted in
Uninstall-SqlDscReportingService.ps1: Line 36 has incorrect indentation for the.OUTPUTSkeyword, and the section is missing inline code formatting for type names. The function conditionally returnsSystem.Int32or nothing, so both should be documented as separate.OUTPUTSentries per PR guidelines.- - .INPUTS + .INPUTS None. - .OUTPUTS + .OUTPUTS + `System.Int32` + + The setup process exit code when PassThru is specified. + + .OUTPUTS + None + + No output when PassThru is not specified.source/Public/Uninstall-SqlDscReportingService.ps1-33-39 (1)
33-39: Fix indentation and format.OUTPUTSwith inline code for each return type.Line 37 has incorrect indentation (
.OUTPUTSshould be indented 4 spaces), and the.OUTPUTSsection is missing inline code formatting for type names. Per the PR objectives and coding guidelines, each distinct return type should have its own.OUTPUTSkeyword entry with the type in inline code and a one-line description.Additionally, the function's
[OutputType([System.Int32])]attribute (line 65) is incomplete—the function conditionally returns eitherSystem.Int32(whenPassThruis present) or nothing (whenPassThruis absent). The comment-based help should reflect both return types separately.- - .INPUTS + .INPUTS None. - .OUTPUTS + .OUTPUTS + `System.Int32` + + The setup process exit code when PassThru is specified. + + .OUTPUTS + None + + No output when PassThru is not specified.To fully align with PowerShell standards, consider updating the
[OutputType()]attribute to reflect both possible return types. However, verify if the project convention allows conditional outputs in[OutputType()]or prefers a single declaration.source/Public/Get-SqlDscPreferredModule.ps1-53-55 (1)
53-55: Remove empty .NOTES section.The
.NOTESsection is empty and should be removed per guidelines, which state it should only be included if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior).Apply this diff to remove the empty section:
Returns a PSModuleInfo object for the preferred module, or $null if not found. - .NOTES - #>source/Public/Get-SqlDscPreferredModule.ps1-48-51 (1)
48-51: OUTPUTS section documents incorrect return type; should beSystem.StringnotPSModuleInfo.The function returns
[System.String](the preferred module name or path), but the OUTPUTS section claimsPSModuleInfo. Update the OUTPUTS section to document[System.String]with appropriate description. Additionally, if the function can return$null, document that by either adding a second.OUTPUTSentry for$nullor combining the description to note when$nullis returned (e.g., "Returns the module name/path as a string, or$nullif not found").Remove the empty .NOTES section (lines 53-55).
source/Public/Install-SqlDscReportingService.ps1-59-66 (1)
59-66: Fix.OUTPUTSindentation and format return type explicitlyThe new
.INPUTSblock looks good, but:
.OUTPUTSis no longer indented by 4 spaces, breaking the help indentation convention.- The return type is only mentioned in prose instead of as a dedicated, inline‑code type line that matches
[OutputType([System.Int32])].You can address both with:
- - .INPUTS - None. - -.OUTPUTS - When PassThru is specified the function will return the setup process exit - code as System.Int32. Otherwise, the function does not generate any output. + .INPUTS + None. + + .OUTPUTS + `System.Int32` + + Returns the setup process exit code when PassThru is specified; otherwise + the command does not generate any output.This brings the help in line with the style guidelines and the
[OutputType([System.Int32])]attribute.
As per coding guidelines, comment-based help indentation and OUTPUTS formatting should be consistent and must match declared output types.source/Public/Test-SqlDscIsDatabasePrincipal.ps1-41-50 (1)
41-50: Fix .OUTPUTS keyword indentation.The
.OUTPUTSkeyword should be indented with 4 spaces to match the.INPUTSkeyword indentation and follow comment-based help formatting guidelines.Apply this diff:
.INPUTS `Microsoft.SqlServer.Management.Smo.Server` Accepts input via the pipeline. -.OUTPUTS + .OUTPUTS `System.Boolean` Returns the output object.Based on coding guidelines.
source/Public/Get-SqlDscAgentAlert.ps1-30-33 (1)
30-33: Fix indentation for OUTPUTS None description.The description text should be indented with 8 spaces according to the comment-based help indentation guidelines (keywords 4 spaces, text 8 spaces).
Apply this diff:
.OUTPUTS None. -Returns nothing when no alerts are found for the specified criteria. + Returns nothing when no alerts are found for the specified criteria.Based on coding guidelines.
source/Public/Remove-SqlDscTraceFlag.ps1-50-57 (1)
50-57: Fix .OUTPUTS keyword indentation.The
.OUTPUTSkeyword should be indented with 4 spaces to match the.INPUTSkeyword indentation and follow comment-based help formatting guidelines.Apply this diff:
.INPUTS `Microsoft.SqlServer.Management.Smo.Wmi.Service` Accepts input via the pipeline. -.OUTPUTS + .OUTPUTS None.Based on coding guidelines.
source/Public/Test-SqlDscRSInstalled.ps1-31-34 (1)
31-34: Fix indentation and apply inline code formatting to OUTPUTS.Two issues need correction:
- The
.OUTPUTSkeyword should be indented with 4 spaces (same as.INPUTS)- The output type should be formatted as inline code with backticks
Apply this diff:
- -.OUTPUTS - System.Boolean + .OUTPUTS + `System.Boolean` Returns $true if the specified instance exists and $false if it does not.Based on coding guidelines.
source/Public/Repair-SqlDscReportingService.ps1-64-66 (1)
64-66: Fix .OUTPUTS keyword indentation.The
.OUTPUTSkeyword should be indented with 4 spaces to match the.INPUTSkeyword indentation and follow comment-based help formatting guidelines.Apply this diff:
- -.OUTPUTS + .OUTPUTS When PassThru is specified the function will return the setup process exit code as System.Int32. Otherwise, the function does not generate any output.Based on coding guidelines.
🟡 Minor comments (15)
source/Public/New-SqlDscRole.ps1-41-48 (1)
41-48: Align.OUTPUTShelp with style guidelines (indentation + description).The new
.INPUTSblock looks correct and matches the pipeline type, but the.OUTPUTSsection is (1) not indented like the other help keywords and (2) missing the required one-line description of the return type. Both the repository guidelines and the linked issue for this PR require each output type to be listed as inline code followed by a descriptive line, and the keyword should follow the same indentation as.SYNOPSIS,.DESCRIPTION, etc. As per coding guidelines and learnings, you should update this block.Suggested change:
- .INPUTS - `Microsoft.SqlServer.Management.Smo.Server` - - Accepts input via the pipeline. - -.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.ServerRole]` + .INPUTS + `Microsoft.SqlServer.Management.Smo.Server` + + Accepts input via the pipeline. + + .OUTPUTS + `[Microsoft.SqlServer.Management.Smo.ServerRole]` + + Returns the newly created server role.This keeps
.INPUTSas-is, makes.OUTPUTSindentation consistent with other help keywords, and adds a concise description that matches the[OutputType()]attribute and actual return. As per coding guidelines and retrieved learnings, this brings the help block in line with the required INPUTS/OUTPUTS format.source/Public/ConvertTo-SqlDscEditionName.ps1-27-30 (1)
27-30: Fix the incorrect property description.The description states the returned object has
EditionNameandFriendlyEditionNameproperties, but the actual implementation (lines 48-52) returns an object withEditionId,Edition, andEditionNameproperties. This is inconsistent with both the code and the .DESCRIPTION section (lines 8-9), which correctly lists the properties.Apply this diff to correct the description:
.OUTPUTS `System.Management.Automation.PSCustomObject` - Returns a custom object with EditionName and FriendlyEditionName properties. + Returns a custom object with EditionId, Edition, and EditionName properties.source/Public/Remove-SqlDscAudit.ps1-41-47 (1)
41-47: Document both pipeline input types in.INPUTS(and optionally tidy.OUTPUTS).The function accepts pipeline input for both
[Microsoft.SqlServer.Management.Smo.Server](ServerObject) and[Microsoft.SqlServer.Management.Smo.Audit](AuditObject), but the.INPUTSsection only documents the server type. Per the style guidelines and the PR objective, each pipeline-accepted type should have its own.INPUTSentry with a short description. As per coding guidelines and retrieved learnings, each distinct input type must be listed separately with repeated.INPUTSkeywords.Suggested update:
- .INPUTS - `Microsoft.SqlServer.Management.Smo.Server` - - Accepts input via the pipeline. - -.OUTPUTS - None. + .INPUTS + `Microsoft.SqlServer.Management.Smo.Server` + + Accepts server objects via the pipeline. + + .INPUTS + `Microsoft.SqlServer.Management.Smo.Audit` + + Accepts audit objects via the pipeline. + + .OUTPUTS + None.(Last change to
.OUTPUTSis just indentation to match the documented 4‑space keyword indent; if you also want to align with the “inline code” convention forNone.you could optionally change that line to`None.`in the same edit.) Based on learnings, …source/Public/Remove-SqlDscRole.ps1-52-52 (1)
52-52: Fix keyword indentation.The
.OUTPUTSkeyword is missing its indentation. Per style guidelines, all comment-based help keywords should be indented 4 spaces.Apply this diff:
- -.OUTPUTS + + .OUTPUTS None.source/Public/Repair-SqlDscServer.ps1-51-56 (1)
51-56: Fix the indentation for the.OUTPUTSkeyword.Line 55 is missing the required 4-space indentation before
.OUTPUTS. According to the coding guidelines, comment-based help keywords must be indented with 4 spaces.Apply this diff to fix the indentation:
- .INPUTS None. -.OUTPUTS + .OUTPUTS None.Committable suggestion skipped: line range outside the PR's diff.
source/Public/Test-SqlDscIsLogin.ps1-20-20 (1)
20-20: Fix the indentation of the.OUTPUTSkeyword.The
.OUTPUTSkeyword is missing the required 4-space indentation. According to the comment-based help guidelines, keywords must be indented with 4 spaces.Apply this diff to fix the indentation:
- -.OUTPUTS + + .OUTPUTSsource/Public/Set-SqlDscStartupParameter.ps1-55-56 (1)
55-56: Update .OUTPUTS to follow new inline-code + description format for “no output”Per the repository’s PowerShell style guidelines and this PR’s objectives,
.OUTPUTSshould either list each return type as inline code with a one-line description, or use`None.`(also as inline code) plus a short description when there is no output. This command has[OutputType()]and never returns, so consider:-.OUTPUTS - None. +.OUTPUTS + `None.` + + This command does not generate any output.This keeps the help consistent with both the
[OutputType()]attribute and the documented formatting rules.source/Public/Get-SqlDscRole.ps1-41-42 (1)
41-42: Fix.OUTPUTSindentation and add missing description.The
.OUTPUTSsection has two issues:
- Line 41: The
.OUTPUTSkeyword is missing the required 4-space indentation (should align with.INPUTSon line 36).- Missing description: After the output type, there should be a blank line followed by a 1-line description explaining what is returned.
Additionally, line 42 uses the cast syntax
`[Microsoft.SqlServer.Management.Smo.ServerRole[]]`but should use only the type name`Microsoft.SqlServer.Management.Smo.ServerRole[]`without the outer square brackets.Apply this diff to fix the formatting:
- -.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.ServerRole[]]` + + .OUTPUTS + `Microsoft.SqlServer.Management.Smo.ServerRole[]` + + Returns the server role objects from the instance.source/Private/Get-CommandParameter.ps1-17-23 (1)
17-23: Keep INPUTS “None.” consistent with style guidelines
Get-CommandParameterdoes not take pipeline input, so documentingNoneis correct, but the module-wide guideline is to useNone.(with a trailing period) for this case, while.OUTPUTSalready follows the new inline-code format.You can align this block like so:
- .INPUTS - None + .INPUTS + None.As per coding guidelines, INPUTS/OUTPUTS “no input/output” cases should be normalized across commands.
source/Public/New-SqlDscDataFile.ps1-115-115 (1)
115-115: Fix indentation in comment-based help.The descriptive text on line 115 lacks the required 8-space indentation for comment-based help content. As per coding guidelines, keywords should have 4 spaces and text should have 8 spaces.
Apply this diff to fix the indentation:
-This cmdlet does not generate output by default when using Standard or FromSpec parameter sets without PassThru. + This cmdlet does not generate output by default when using Standard or FromSpec parameter sets without PassThru.source/Public/Enable-SqlDscAudit.ps1-40-43 (1)
40-43: Missing INPUTS entry for Audit type.The AuditObject parameter (line 59) also accepts pipeline input with type
Microsoft.SqlServer.Management.Smo.Audit, but the INPUTS section only documents the Server type. According to the guidelines, the .INPUTS keyword should be repeated for each pipeline-accepted input type.Add a second INPUTS section after line 43:
Accepts a SQL Server server object via the pipeline. + .INPUTS + `Microsoft.SqlServer.Management.Smo.Audit` + + Accepts an audit object via the pipeline. + .OUTPUTS None.As per coding guidelines and learnings.
source/Public/Set-SqlDscAudit.ps1-77-85 (1)
77-85: Document both pipeline input types and fix.OUTPUTSindentationThis command accepts two distinct pipeline types:
Microsoft.SqlServer.Management.Smo.Servervia ServerObjectMicrosoft.SqlServer.Management.Smo.Auditvia AuditObjectbut the
.INPUTSsection only lists the server type, and.OUTPUTSis not indented with 4 spaces.To align help with the actual parameter sets and style guidelines, consider updating the block like this:
- .INPUTS - `Microsoft.SqlServer.Management.Smo.Server` - - Accepts input via the pipeline. - -.OUTPUTS + .INPUTS + `Microsoft.SqlServer.Management.Smo.Server` + + Accepts a SQL Server server object via the pipeline. + + .INPUTS + `Microsoft.SqlServer.Management.Smo.Audit` + + Accepts a SQL Server audit object via the pipeline. + + .OUTPUTSThis documents both pipeline-accepted types and restores the expected 4-space indentation on
.OUTPUTS. As per coding guidelines and retrieved learnings, each pipeline type should have its own.INPUTSentry.source/Public/Grant-SqlDscServerPermission.ps1-29-34 (1)
29-34: Missing.INPUTSentry forServerRoleparameter.The function has two parameters that accept pipeline input (
$Loginand$ServerRole), but only theLogintype is documented in the.INPUTSsection. According to the coding guidelines, each pipeline-accepted type must have its own.INPUTSentry with the keyword repeated.Apply this diff to add the missing
.INPUTSentry:.INPUTS `Microsoft.SqlServer.Management.Smo.Login` Accepts input via the pipeline. + .INPUTS + `Microsoft.SqlServer.Management.Smo.ServerRole` + + Accepts input via the pipeline. + .OUTPUTS None.source/Public/Get-SqlDscDatabasePermission.ps1-32-35 (1)
32-35: Fix formatting error in.OUTPUTSsection.The
.OUTPUTSsection has a formatting error with an unclosed backtick and incomplete array bracket notation. The type should be properly enclosed in backticks, and the description should be corrected.Apply this diff to fix the formatting:
.OUTPUTS - `Microsoft.SqlServer.Management.Smo.DatabasePermissionInfo[` + `Microsoft.SqlServer.Management.Smo.DatabasePermissionInfo[]` - Returns the output object.] + Returns an array of database permission information objects.source/Public/Revoke-SqlDscServerPermission.ps1-30-35 (1)
30-35: Missing.INPUTSentry forServerRoleparameter.The function has two parameters that accept pipeline input (
$Loginand$ServerRole), but only theLogintype is documented in the.INPUTSsection. According to the coding guidelines, each pipeline-accepted type must have its own.INPUTSentry with the keyword repeated.Apply this diff to add the missing
.INPUTSentry:.INPUTS `Microsoft.SqlServer.Management.Smo.Login` Accepts input via the pipeline. + .INPUTS + `Microsoft.SqlServer.Management.Smo.ServerRole` + + Accepts input via the pipeline. + .OUTPUTS None.
🧹 Nitpick comments (12)
source/Public/Test-SqlDscIsSupportedFeature.ps1 (1)
20-29: Fix.OUTPUTSindentation and consider clearer descriptions
- Line 26:
.OUTPUTSis not indented with 4 spaces like the other comment-based help keywords in this block. It should follow the standard:-.OUTPUTS + .OUTPUTSThis keeps the help block consistent with the style guideline “keywords 4 spaces, text 8 spaces.” As per coding guidelines, this should be aligned.
- Optional: The descriptions are quite generic:
- Line 24: You could make it clearer which parameter accepts pipeline input, e.g. “Accepts the
Featureparameter value via the pipeline.”- Line 29: You could describe the boolean semantics, e.g. “Returns
$trueif the feature is supported; otherwise$false.”These wording tweaks are not required for correctness but would make the help more informative. Based on learnings, each output type’s description should explain when that type/value is returned.
source/Public/Remove-SqlDscNode.ps1 (1)
37-37: Fix indentation of.OUTPUTSkeyword to match comment-based help style
.OUTPUTSis currently not indented, while all other help keywords (including the new.INPUTS) have 4 leading spaces. The guidelines require 4-space indentation for help keywords. Please align.OUTPUTSwith the same indentation:-.OUTPUTS + .OUTPUTSThis keeps the help block consistent and compliant with the documented formatting rules.
source/Public/Install-SqlDscServer.ps1 (1)
354-359: Align.INPUTS/.OUTPUTSblock with new style (inline code + indentation).The semantics look right (no inputs, no outputs), but this block is slightly off from the documented guidelines:
None.should be formatted as inline code in both.INPUTSand.OUTPUTS..OUTPUTSshould be indented with 4 spaces, like.SYNOPSIS,.PARAMETER, and.INPUTS.A minimal fix:
- - .INPUTS - None. - -.OUTPUTS - None. + + .INPUTS + `None.` + + .OUTPUTS + `None.`This keeps behavior unchanged while matching the updated
.INPUTS/.OUTPUTSformatting rules. As per coding guidelines, ...source/Public/Add-SqlDscTraceFlag.ps1 (1)
55-56: Align .OUTPUTS formatting with inline-code style for “no output”Semantically,
.OUTPUTS=None.matches both[OutputType()](no type) and the implementation (no objects are emitted). To fully comply with the updated style guidelines, consider formatting the “no outputs” case using inline code (and optionally adding a brief description), e.g.:- .OUTPUTS - None. + .OUTPUTS + `None.` + + No objects are returned.This keeps behavior unchanged while bringing the help text in line with the standardized
.OUTPUTSformatting.As per coding guidelines,
.OUTPUTSentries should use inline code formatting and include a one-line description of the output type (or lack thereof).source/Public/ConvertTo-SqlDscEditionName.ps1 (1)
32-34: Consider removing the .NOTES section.The .NOTES section contains only author information, which doesn't meet the guideline criteria for inclusion: "Include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior)."
Apply this diff to remove the non-essential .NOTES section:
- .NOTES - Author: SqlServerDsc -#> +#>source/Public/New-SqlDscAudit.ps1 (1)
73-73: Consider a more specific INPUTS description.The description "Accepts input via the pipeline." is generic. For better developer ergonomics and clarity, consider a more specific and informative description that explains what the type represents in context, such as "SQL Server object from Connect-SqlDscDatabaseEngine" or "Specifies the SQL Server instance for audit creation."
source/Public/Get-SqlDscInstalledInstance.ps1 (1)
15-20: Tighten.INPUTS/.OUTPUTShelp to fully match style guidelinesThe new
.INPUTSblock is semantically correct (this command doesn’t take pipeline input), but the.OUTPUTSsection is still missing the required 1‑line description and the keyword indentation is inconsistent with the rest of the help. Also, for consistency with the “inline code” convention,None.can be treated the same way as types.Consider updating this block to something along these lines:
- - .INPUTS - None. - -.OUTPUTS - `[System.Object[]]` + + .INPUTS + `None.` + + .OUTPUTS + `[System.Object[]]` + + An array of objects that describes each installed SQL Server instance.This keeps
.INPUTSaccurate, indents.OUTPUTSlike the other keywords, and adds the mandated one‑line description for the output type so the comment-based help matches[OutputType()]and the actual return value. As per coding guidelines and retrieved learnings, …source/Public/Test-SqlDscIsLogin.ps1 (1)
21-23: Consider a more descriptive output description.The description "Returns the output object." is generic and doesn't convey what the boolean value represents. Consider describing the actual meaning, such as "Returns
$trueif the principal exists as a login, otherwise$false."source/Public/Test-SqlDscIsLoginEnabled.ps1 (1)
36-40: Consider consolidating or improving the output description.Line 38 provides a generic description "Returns the output object." while line 40 provides the actual useful information. Consider removing line 38 or merging both lines into a single, more concise description like "Returns
$trueif the login is enabled,$falseif disabled."source/Public/Set-SqlDscStartupParameter.ps1 (1)
36-47: Examples referenceSet-SqlDscTraceFlaginstead of this commandThe second and third
.EXAMPLEblocks callSet-SqlDscTraceFlagwhile this help block documentsSet-SqlDscStartupParameter. Please verify whether these examples are intended to reference a different command or if this is a copy/paste oversight; if the latter, updating them to useSet-SqlDscStartupParameter(or adjusting the examples accordingly) would avoid confusion for users.source/Public/Connect-SqlDscDatabaseEngine.ps1 (1)
62-68: INPUTS/OUTPUTS help now matches usage
.INPUTScorrectly documents that the command does not accept pipeline input..OUTPUTSnow advertisesMicrosoft.SqlServer.Management.Smo.Serverwith a clear one-line description, which matches the expected server object returned byConnect-Sql.If you do a future style clean-up, consider adding a matching
[OutputType([Microsoft.SqlServer.Management.Smo.Server])]attribute to keep metadata and help fully in sync.source/Public/Get-SqlDscDatabase.ps1 (1)
35-42: Tighten .OUTPUTS formatting and add a short description
.INPUTScorrectly documents the pipeline server type, but.OUTPUTSis flush-left and only shows the type without a description. To better follow the help guidelines (indentation + 1‑line description per return type), you could adjust as:- .INPUTS - `Microsoft.SqlServer.Management.Smo.Server` - - Accepts input via the pipeline. - -.OUTPUTS - `[Microsoft.SqlServer.Management.Smo.Database[]]` + .INPUTS + `Microsoft.SqlServer.Management.Smo.Server` + + Accepts input via the pipeline. + + .OUTPUTS + `[Microsoft.SqlServer.Management.Smo.Database[]]` + + Returns one or more database objects from the SQL Server instance.This keeps
.OUTPUTSaligned and adds the required brief description. As per coding guidelines and prior learnings.
… DSC scripts to enhance clarity and consistency. Updated parameter types to use backticks for better formatting. Improved descriptions for inputs and outputs, ensuring they accurately reflect the expected types and behaviors. This includes changes in scripts related to agent alerts, logins, databases, and configuration options, among others.
…rmission for clarity and consistency
…tation for clarity
…base documentation
…ole documentation
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
source/Public/Get-SqlDscRSSetupConfiguration.ps1 (1)
44-62: Align .OUTPUTS with [OutputType()] and use 1-line description format.Two issues with the .OUTPUTS section:
Type mismatch: Line 45 documents
PSCustomObjectbut line 67 declares[OutputType([PSCustomObject[]])]and line 213 returns an array. The documentation should reflect that it returns an array.Format: The coding guidelines specify "list each return type as inline code with a 1-line description", but the current format uses a multi-line bullet list describing each property. While detailed property descriptions are helpful, they should appear in the .DESCRIPTION section rather than .OUTPUTS.
Apply this diff to align with the guidelines:
-.OUTPUTS - `PSCustomObject` - - - InstanceName: The name of the Reporting Services instance. - - InstallFolder: The installation folder path. - - ServiceName: The name of the service. - - ErrorDumpDirectory: The path to the error dump directory. - - CustomerFeedback: Whether customer feedback is enabled. - - EnableErrorReporting: Whether error reporting is enabled. - - ProductVersion: The product version from registry. - - CurrentVersion: The current version from registry. - - VirtualRootServer: The virtual root server value. - - ConfigFilePath: The path to the report server configuration file. - - EditionID: The edition ID of the Reporting Services instance. - - EditionName: The edition name of the Reporting Services instance. - - IsSharePointIntegrated: Whether the instance is SharePoint integrated. - MSReportServer_Instance. - - InstanceId: The instance ID of the Reporting Services instance. + .OUTPUTS + `PSCustomObject[]` + + Returns an array of custom objects containing Reporting Services configuration information including instance name, installation folder, service details, version information, and additional properties.source/Public/Set-SqlDscDatabaseDefault.ps1 (1)
82-82: Add[OutputType()]attribute for the None output case.The
.OUTPUTShelp documents bothNone.andMicrosoft.SqlServer.Management.Smo.Database, but only the Database type has a corresponding[OutputType()]attribute. To maintain consistency between the help documentation and the OutputType declarations, add an empty[OutputType()]attribute for the None case.Apply this diff:
+ [OutputType()] [OutputType([Microsoft.SqlServer.Management.Smo.Database])]Based on learnings and the pattern used in Set-SqlDscDatabaseOwner.ps1 (lines 86-87) within this PR.
🧹 Nitpick comments (3)
source/Public/Test-SqlDscAgentAlertProperty.ps1 (1)
37-40: LGTM! OUTPUTS section correctly formatted.The OUTPUTS section properly uses inline code formatting (backticks) for the type name and matches both the
[OutputType([System.Boolean])]attribute and the actual return statements throughout the function. The formatting and indentation follow the guidelines correctly.Optionally, consider making the description more specific about what the boolean represents:
- Returns the output object. + Returns `$true` if the alert has the specified properties, otherwise `$false`.source/Public/ConvertTo-SqlDscFileGroup.ps1 (1)
17-21: .INPUTS/.OUTPUTS help formatting looks correct; optional description line for .OUTPUTSThe
.INPUTSsection correctly usesNone.for a command with no pipeline input, and.OUTPUTSnow documents the correct return type as inline code matching both[OutputType()]and the actualreturn. To fully align with the style guideline of having a one‑line description per output type, you could optionally add a brief description under.OUTPUTS, for example:.OUTPUTS - `Microsoft.SqlServer.Management.Smo.FileGroup` + `Microsoft.SqlServer.Management.Smo.FileGroup` + + A `Microsoft.SqlServer.Management.Smo.FileGroup` instance representing the created file group.As per coding guidelines, …
source/Public/New-SqlDscAgentAlert.ps1 (1)
33-35: Consider separating output types into individual.OUTPUTSentries.Per the coding guidelines and PR objectives, each return type should have its own
.OUTPUTSkeyword with the type as inline code on its own line, followed by a blank line and a one-line description. The current format merges the type and conditional description on the same line.Based on learnings, each distinct return type should have its own entry with a description of when that type is returned.
Apply this diff to align with the expected format:
.OUTPUTS - `Microsoft.SqlServer.Management.Smo.Agent.Alert` if passing parameter **PassThru**, - otherwise none. + `Microsoft.SqlServer.Management.Smo.Agent.Alert` + + Returns the created alert object when using the **PassThru** parameter. + + .OUTPUTS + `None.` + + No output when the **PassThru** parameter is not specified.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (63)
source/Private/Get-CommandParameter.ps1(1 hunks)source/Public/Add-SqlDscFileGroup.ps1(1 hunks)source/Public/ConvertTo-SqlDscDataFile.ps1(1 hunks)source/Public/ConvertTo-SqlDscFileGroup.ps1(1 hunks)source/Public/Disable-SqlDscAgentOperator.ps1(1 hunks)source/Public/Disable-SqlDscDatabaseSnapshotIsolation.ps1(2 hunks)source/Public/Disable-SqlDscLogin.ps1(1 hunks)source/Public/Enable-SqlDscAgentOperator.ps1(1 hunks)source/Public/Enable-SqlDscDatabaseSnapshotIsolation.ps1(2 hunks)source/Public/Enable-SqlDscLogin.ps1(1 hunks)source/Public/Get-SqlDscAgentAlert.ps1(1 hunks)source/Public/Get-SqlDscAgentOperator.ps1(1 hunks)source/Public/Get-SqlDscCompatibilityLevel.ps1(1 hunks)source/Public/Get-SqlDscConfigurationOption.ps1(1 hunks)source/Public/Get-SqlDscDatabase.ps1(1 hunks)source/Public/Get-SqlDscInstalledInstance.ps1(1 hunks)source/Public/Get-SqlDscLogin.ps1(1 hunks)source/Public/Get-SqlDscManagedComputer.ps1(1 hunks)source/Public/Get-SqlDscManagedComputerInstance.ps1(1 hunks)source/Public/Get-SqlDscManagedComputerService.ps1(1 hunks)source/Public/Get-SqlDscRSSetupConfiguration.ps1(1 hunks)source/Public/Get-SqlDscRole.ps1(1 hunks)source/Public/Get-SqlDscServerProtocol.ps1(2 hunks)source/Public/Get-SqlDscServerProtocolName.ps1(1 hunks)source/Public/Get-SqlDscSetupLog.ps1(1 hunks)source/Public/Get-SqlDscStartupParameter.ps1(1 hunks)source/Public/Get-SqlDscTraceFlag.ps1(1 hunks)source/Public/Install-SqlDscBIReportServer.ps1(1 hunks)source/Public/Install-SqlDscReportingService.ps1(1 hunks)source/Public/Invoke-SqlDscQuery.ps1(1 hunks)source/Public/New-SqlDscAgentAlert.ps1(1 hunks)source/Public/New-SqlDscAgentOperator.ps1(1 hunks)source/Public/New-SqlDscAudit.ps1(1 hunks)source/Public/New-SqlDscDataFile.ps1(1 hunks)source/Public/New-SqlDscDatabase.ps1(1 hunks)source/Public/New-SqlDscDatabaseSnapshot.ps1(1 hunks)source/Public/New-SqlDscFileGroup.ps1(1 hunks)source/Public/New-SqlDscLogin.ps1(1 hunks)source/Public/New-SqlDscRole.ps1(1 hunks)source/Public/Remove-SqlDscAgentAlert.ps1(1 hunks)source/Public/Remove-SqlDscAgentOperator.ps1(1 hunks)source/Public/Remove-SqlDscLogin.ps1(1 hunks)source/Public/Repair-SqlDscBIReportServer.ps1(1 hunks)source/Public/Repair-SqlDscReportingService.ps1(1 hunks)source/Public/Resume-SqlDscDatabase.ps1(2 hunks)source/Public/Set-SqlDscAgentAlert.ps1(1 hunks)source/Public/Set-SqlDscAgentOperator.ps1(1 hunks)source/Public/Set-SqlDscAudit.ps1(1 hunks)source/Public/Set-SqlDscConfigurationOption.ps1(1 hunks)source/Public/Set-SqlDscDatabaseDefault.ps1(1 hunks)source/Public/Set-SqlDscDatabaseOwner.ps1(1 hunks)source/Public/Set-SqlDscDatabaseProperty.ps1(2 hunks)source/Public/Suspend-SqlDscDatabase.ps1(2 hunks)source/Public/Test-SqlDscAgentAlertProperty.ps1(1 hunks)source/Public/Test-SqlDscConfigurationOption.ps1(1 hunks)source/Public/Test-SqlDscDatabaseProperty.ps1(1 hunks)source/Public/Test-SqlDscIsAgentAlert.ps1(1 hunks)source/Public/Test-SqlDscIsAgentOperator.ps1(1 hunks)source/Public/Test-SqlDscIsDatabase.ps1(1 hunks)source/Public/Test-SqlDscIsLoginEnabled.ps1(1 hunks)source/Public/Test-SqlDscRSInstalled.ps1(1 hunks)source/Public/Uninstall-SqlDscBIReportServer.ps1(1 hunks)source/Public/Uninstall-SqlDscReportingService.ps1(1 hunks)
✅ Files skipped from review due to trivial changes (22)
- source/Private/Get-CommandParameter.ps1
- source/Public/New-SqlDscFileGroup.ps1
- source/Public/Set-SqlDscConfigurationOption.ps1
- source/Public/Get-SqlDscSetupLog.ps1
- source/Public/Disable-SqlDscLogin.ps1
- source/Public/Enable-SqlDscDatabaseSnapshotIsolation.ps1
- source/Public/Set-SqlDscDatabaseProperty.ps1
- source/Public/Remove-SqlDscAgentOperator.ps1
- source/Public/Get-SqlDscCompatibilityLevel.ps1
- source/Public/Test-SqlDscIsDatabase.ps1
- source/Public/Disable-SqlDscAgentOperator.ps1
- source/Public/Disable-SqlDscDatabaseSnapshotIsolation.ps1
- source/Public/Get-SqlDscManagedComputerInstance.ps1
- source/Public/Test-SqlDscIsAgentOperator.ps1
- source/Public/Get-SqlDscServerProtocol.ps1
- source/Public/Test-SqlDscConfigurationOption.ps1
- source/Public/Enable-SqlDscLogin.ps1
- source/Public/Get-SqlDscServerProtocolName.ps1
- source/Public/Get-SqlDscConfigurationOption.ps1
- source/Public/Remove-SqlDscLogin.ps1
- source/Public/Get-SqlDscStartupParameter.ps1
- source/Public/New-SqlDscDatabaseSnapshot.ps1
🚧 Files skipped from review as they are similar to previous changes (19)
- source/Public/New-SqlDscAudit.ps1
- source/Public/Get-SqlDscTraceFlag.ps1
- source/Public/Get-SqlDscManagedComputerService.ps1
- source/Public/New-SqlDscDataFile.ps1
- source/Public/Get-SqlDscDatabase.ps1
- source/Public/Install-SqlDscBIReportServer.ps1
- source/Public/Test-SqlDscIsAgentAlert.ps1
- source/Public/Set-SqlDscAudit.ps1
- source/Public/Get-SqlDscInstalledInstance.ps1
- source/Public/Get-SqlDscAgentOperator.ps1
- source/Public/Get-SqlDscLogin.ps1
- source/Public/Uninstall-SqlDscReportingService.ps1
- source/Public/New-SqlDscDatabase.ps1
- source/Public/Add-SqlDscFileGroup.ps1
- source/Public/Uninstall-SqlDscBIReportServer.ps1
- source/Public/Invoke-SqlDscQuery.ps1
- source/Public/Test-SqlDscIsLoginEnabled.ps1
- source/Public/Get-SqlDscAgentAlert.ps1
- source/Public/Get-SqlDscRole.ps1
🧰 Additional context used
📓 Path-based instructions (6)
**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
**/*.ps1: Format public commands as{Verb}-SqlDsc{Noun}following PowerShell naming conventions
Format private functions as{Verb}-{Noun}following PowerShell naming conventions
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
source/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-localization.instructions.md)
source/**/*.ps1: Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages in PowerShell scripts
Use localized string keys from $script:localizedData, not hardcoded strings, in diagnostic messages
Reference localized strings using the syntax: Write-Verbose -Message ($script:localizedData.KeyName -f $value1)Localize all strings using string keys; remove any orphaned string keys
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
**/*.{ps1,psm1,psd1}
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-powershell.instructions.md)
**/*.{ps1,psm1,psd1}: Use descriptive names with 3+ characters and no abbreviations for functions, variables, and identifiers
Functions: Use PascalCase with Verb-Noun format using approved verbs
Parameters: Use PascalCase
Variables: Use camelCase
Keywords: Use lower-case
Classes: Use PascalCase
Include scope for script/global/environment variables:$script:,$global:,$env:
Use 4 spaces for indentation (no tabs)
Use one space around operators:$a = 1 + 2
Use one space between type and variable:[String] $name
Use one space between keyword and parenthesis:if ($condition)
No spaces on empty lines
Try to limit lines to 120 characters
Newline before opening brace (except variable assignments)
One newline after opening brace
Two newlines after closing brace (one if followed by another brace or continuation)
Use single quotes unless variable expansion is needed:'text'vs"text $variable"
Single-line arrays:@('one', 'two', 'three'); multi-line: each element on separate line with proper indentation
Do not use the unary comma operator (,) in return statements to force an array
Empty hashtables:@{}; each property on separate line with proper indentation; use PascalCase for properties
Single-line comments:# Comment(capitalized, on own line); multi-line:<# Comment #>format with opening/closing brackets on own line
Do not include commented-out code
Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Comment-based help indentation: keywords 4 spaces, text 8 spaces
Include examples in comment-based help for all parameter sets and combinations
INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both[OutputType()]and actual ret...
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
source/Public/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Public commands should be located in
source/Public/{CommandName}.ps1
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Classes:
source/Classes/{DependencyGroupNumber}.{ClassName}.ps1- Enums:
source/Enum/{DependencyGroupNumber}.{EnumName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type as inline code with a 1‑line description...
Files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
🧠 Learnings (25)
📓 Common learnings
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include examples in comment-based help for all parameter sets and combinations
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : .NOTES section in comment-based help: include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior); keep to ≤2 short sentences
📚 Learning: 2025-10-03T15:27:24.417Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Applied to files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Test-SqlDscAgentAlertProperty.ps1source/Public/Remove-SqlDscAgentAlert.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Suspend-SqlDscDatabase.ps1source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Set-SqlDscDatabaseDefault.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Set-SqlDscAgentOperator.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-11-22T17:36:09.703Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Applied to files:
source/Public/Enable-SqlDscAgentOperator.ps1source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/New-SqlDscLogin.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/New-SqlDscRole.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Get-SqlDscManagedComputer.ps1
📚 Learning: 2025-09-13T10:13:47.123Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/Repair-SqlDscBIReportServer.ps1source/Public/Repair-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1
📚 Learning: 2025-10-03T15:27:39.511Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Applied to files:
source/Public/New-SqlDscAgentOperator.ps1source/Public/Test-SqlDscRSInstalled.ps1source/Public/ConvertTo-SqlDscFileGroup.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Place parameter type on line above parameter name
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-08-16T13:22:15.230Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: tests/Unit/Public/Get-SqlDscLogin.Tests.ps1:78-93
Timestamp: 2025-08-16T13:22:15.230Z
Learning: In PowerShell unit tests for parameter validation in SqlServerDsc, accessing parameter attributes directly like `$cmd.Parameters['ParameterName'].Attributes.Mandatory` works correctly because PowerShell automatically iterates through the array and returns the property values. Additional filtering to ParameterAttribute is not necessary when the parameter structure is known and controlled.
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Avoid unnecessary type declarations when type is clear
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/tests/Integration/**/*.ps1 : Integration tests: use `Connect-SqlDscDatabaseEngine` for SQL Server DB session with correct CI credentials, and always follow with `Disconnect-SqlDscDatabaseEngine`
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-11-27T17:59:01.508Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.508Z
Learning: Applies to source/DSCResources/**/*.psm1 : `Test-TargetResource` function must return a boolean value ($true or $false)
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1source/Public/Test-SqlDscRSInstalled.ps1
📚 Learning: 2025-11-27T17:59:27.205Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.205Z
Learning: Applies to **/*.[Tt]ests.ps1 : Use `-BeTrue`/`-BeFalse` never `-Be $true`/`-Be $false`
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-11-27T17:59:27.205Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.205Z
Learning: Applies to **/*.[Tt]ests.ps1 : Access test case properties directly: `$PropertyName`
Applied to files:
source/Public/Test-SqlDscDatabaseProperty.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/tests/**/*.tests.ps1 : Add `$env:SqlServerDscCI = $true` in `BeforeAll` block and remove in `AfterAll` block of unit tests
Applied to files:
source/Public/Test-SqlDscRSInstalled.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : For state-changing functions, use `SupportsShouldProcess`; place ShouldProcess check immediately before each state-change; set `ConfirmImpact` to 'Low', 'Medium', or 'High'
Applied to files:
source/Public/Test-SqlDscRSInstalled.ps1
📚 Learning: 2025-11-27T17:58:20.404Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Applied to files:
source/Public/Test-SqlDscRSInstalled.ps1source/Public/Get-SqlDscRSSetupConfiguration.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/*.ps1 : Format public commands as `{Verb}-SqlDsc{Noun}` following PowerShell naming conventions
Applied to files:
source/Public/Set-SqlDscDatabaseOwner.ps1source/Public/New-SqlDscLogin.ps1source/Public/ConvertTo-SqlDscDataFile.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Resume-SqlDscDatabase.ps1
📚 Learning: 2025-10-19T10:33:22.772Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2309
File: tests/Integration/Commands/Initialize-SqlDscRebuildDatabase.Integration.Tests.ps1:132-148
Timestamp: 2025-10-19T10:33:22.772Z
Learning: In SqlServerDsc integration tests, when connecting via Connect-SqlDscDatabaseEngine using a local Windows account (e.g., 'SqlAdmin'), use the plain username format without computer/domain prefix. This is Windows Authentication with a local account. The NetBIOS format (e.g., 'COMPUTER\SqlAdmin') is only used for SqlSysAdminAccounts during SQL Server setup/rebuild and will throw an exception if used with Connect-SqlDscDatabaseEngine for local Windows accounts.
Applied to files:
source/Public/New-SqlDscLogin.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/tests/**/*.tests.ps1 : When unit tests test classes or commands containing SMO types like `[Microsoft.SqlServer.Management.Smo.*]`, ensure they are properly stubbed in SMO.cs
Applied to files:
source/Public/Suspend-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/resources/**/*.ps1 : Add `InstanceName`, `ServerName`, and `Credential` to `$this.ExcludeDscProperties` in Database Engine resources
Applied to files:
source/Public/New-SqlDscRole.ps1source/Public/Set-SqlDscDatabaseDefault.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : .NOTES section in comment-based help: include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior); keep to ≤2 short sentences
Applied to files:
source/Public/Set-SqlDscAgentAlert.ps1source/Public/ConvertTo-SqlDscDataFile.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include `[OutputType({return type})]` for functions with output; use `[OutputType()]` for no output
Applied to files:
source/Public/ConvertTo-SqlDscDataFile.ps1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
- GitHub Check: PSScriptAnalyzer
- GitHub Check: PSScriptAnalyzer
🔇 Additional comments (21)
source/Public/ConvertTo-SqlDscDataFile.ps1 (1)
16-24: LGTM! Documentation properly formatted.The
.INPUTSand.OUTPUTSsections now follow the required format:
.INPUTScorrectly specifiesNone.since no parameters accept pipeline input.OUTPUTStype is properly wrapped in backticks as inline code and matches the[OutputType()]declaration and actual return valuesource/Public/Set-SqlDscAgentOperator.ps1 (1)
53-64: LGTM! Documentation formatting correctly updated.The
.INPUTSand.OUTPUTSsections now follow the required format:
- Each pipeline-accepted type is formatted as inline code (backticks)
- The
.INPUTSkeyword is repeated for each input type- Types match the parameter definitions (ServerObject and OperatorObject with
ValueFromPipeline = $true).OUTPUTScorrectly specifiesNone., consistent with the empty[OutputType()]attribute on line 88source/Public/New-SqlDscLogin.ps1 (2)
153-157: .OUTPUTS section correctly documents conditional login return typeThe
.OUTPUTSentry now cleanly matches[OutputType([Microsoft.SqlServer.Management.Smo.Login])]and the actual behavior of only returning aMicrosoft.SqlServer.Management.Smo.Logininstance whenPassThruis used. Formatting (inline-code type, separate description line, keyword per type) aligns with the documented style guidelines.
158-162: .INPUTS section correctly reflects pipeline-accepted SMO Server typeThe
.INPUTSentry correctly documentsMicrosoft.SqlServer.Management.Smo.Serveras the pipeline-accepted type, and the description clearly states that the cmdlet accepts a SMOServerobject from the pipeline (matching theServerObjectparameter’s type andValueFromPipelineusage). Indentation and inline-code formatting are consistent with the guidelines.source/Public/Enable-SqlDscAgentOperator.ps1 (1)
40-51: LGTM! Documentation formatting correctly updated.The
.INPUTSand.OUTPUTSsections now follow the required DSC Community style guidelines:
- Each pipeline-accepted type is formatted as inline code with backticks
- The
.INPUTSkeyword is correctly repeated for each input type- The
.OUTPUTSsection correctly specifiesNone.matching the[OutputType()]attribute on line 56source/Public/New-SqlDscAgentOperator.ps1 (1)
60-68: LGTM! Documentation formatting correctly updated.The
.INPUTSand.OUTPUTSsections now follow the required DSC Community style guidelines:
- The pipeline-accepted Server type is formatted as inline code with backticks
- The Operator return type is formatted as inline code with backticks
- The
.OUTPUTSdescription accurately documents the conditional return behavior (lines 266-268 confirm the operator is only returned whenPassThruis present)- The documented output type matches the
[OutputType()]attribute on line 98source/Public/Suspend-SqlDscDatabase.ps1 (1)
63-81: INPUTS/OUTPUTS help now correctly formatted and aligned with behaviorThe
.INPUTSand.OUTPUTSsections now use inline code for the SMO types, repeat the keywords per type, and accurately reflect both[OutputType()]attributes and the actual PassThru behavior. No further changes needed.As per coding guidelines, ...
source/Public/Remove-SqlDscAgentAlert.ps1 (1)
25-34: INPUTS/OUTPUTS help now correctly reflects pipeline and return behaviorBoth
.INPUTSentries now list the exact pipeline-accepted types with one-line descriptions, and the.OUTPUTSsection (None.) matches[OutputType()]and the actual lack of pipeline output from this command. No further changes needed.
As per coding guidelines, this aligns with the required INPUTS/OUTPUTS formatting.source/Public/Test-SqlDscAgentAlertProperty.ps1 (1)
27-35: LGTM! INPUTS section correctly formatted.The INPUTS section properly documents both pipeline-accepting parameter types using inline code formatting (backticks), repeats the
.INPUTSkeyword for each type, and follows the correct indentation pattern. The types accurately match theServerObjectandAlertObjectparameters withValueFromPipeline = $true.source/Public/Get-SqlDscRSSetupConfiguration.ps1 (1)
41-42: LGTM - .INPUTS section correctly formatted.The .INPUTS section correctly specifies "None." since no parameters accept pipeline input.
source/Public/New-SqlDscAgentAlert.ps1 (1)
28-31: LGTM!The
.INPUTSsection correctly follows the expected format: type as inline code on its own line, blank line, then one-line description. The input type matches the pipeline-accepting parameter.source/Public/Resume-SqlDscDatabase.ps1 (2)
60-69: .INPUTS section correctly documents pipeline types and formattingBoth
.INPUTSentries now use backticked fully-qualified SMO types matching the pipeline-accepted parameters (ServerObjectandDatabaseObject), with clear one-line descriptions and repeated.INPUTSper type. As per coding guidelines, this is the expected pattern.
70-79: .OUTPUTS section now aligned with OutputType attributes and behaviorThe first
.OUTPUTSentry (None.) documents the default no-output case, and the second entry uses a backtickedMicrosoft.SqlServer.Management.Smo.Databasetype with a concise PassThru description, matching both[OutputType()]and[OutputType([Microsoft.SqlServer.Management.Smo.Database])]and the actual return behavior. As per coding guidelines and prior learnings on OUTPUTS, this is correct.source/Public/Repair-SqlDscBIReportServer.ps1 (1)
58-66: .INPUTS/.OUTPUTS help correctly documents input and output behavior
.INPUTSexplicitly states there is no pipeline input, and.OUTPUTSdocumentsSystem.Int32with a clear condition tied to-PassThru, matching the[OutputType([System.Int32])]attribute and actual return behavior. As per coding guidelines, this aligns with the required format for comment-based help.source/Public/Set-SqlDscAgentAlert.ps1 (3)
37-45: LGTM! INPUTS section correctly formatted.The
.INPUTSsection properly documents both pipeline-accepted types with backticks, repeats the keyword for each input type, and provides clear one-line descriptions. This aligns with the PR objectives and coding guidelines.
47-53: Verify the pattern of documenting both output type andNone.The
.OUTPUTSsection lists both the Alert return type (when PassThru is specified) andNone.(when PassThru is not specified) as separate entries. This pattern is unusual in PowerShell comment-based help.Standard practice for functions with PassThru parameters is to document only the actual return type, with the description explaining when it's returned (which is already present on Line 50). The guideline "If there are no outputs, specify
None." typically applies to functions that never return anything, not conditionally-returning functions.Consider whether the second
.OUTPUTS None.entry (lines 52-53) should be removed, leaving only the Alert type with its conditional description.Based on learnings, each distinct return type should have its own .OUTPUTS entry. However, "no output" is not a distinct type—it's the absence of a return value, which is the default behavior when PassThru is not specified.
58-58: Nice documentation improvement.The added example description clearly explains the action being performed, which improves the documentation quality.
source/Public/Test-SqlDscRSInstalled.ps1 (1)
27-34: LGTM!The
.INPUTSand.OUTPUTSsections are correctly formatted with proper indentation, inline code formatting for the type, and accurate documentation that matches both the[OutputType()]attribute and the actual return behavior.source/Public/Set-SqlDscDatabaseDefault.ps1 (1)
61-77: LGTM! The.INPUTSand.OUTPUTSdocumentation is well-structured.The help sections correctly document both input types (Server and Database via pipeline) and both output scenarios (None by default, Database when PassThru is specified). The formatting with inline code and proper indentation follows the style guidelines.
source/Public/Get-SqlDscManagedComputer.ps1 (1)
23-27: The help content is accurate.The
.INPUTS(None) and.OUTPUTSsections correctly document the function behavior with proper inline code formatting for the type. The output type matches the[OutputType()]attribute and the actual return value.source/Public/Set-SqlDscDatabaseOwner.ps1 (1)
70-81: LGTM! Exemplary implementation of.INPUTSand.OUTPUTSdocumentation.This file demonstrates the correct pattern for documenting functions with optional PassThru parameters:
- Both
[OutputType()]attributes are present (lines 86-87)- Both output scenarios are documented (None by default, Database when PassThru is specified)
- Proper indentation and inline code formatting throughout
- Input documentation correctly identifies the pipeline-accepted type
…ify input and output details
…fy output details
…on to clarify return values
…regarding PassThru parameter
…L Server instance for audit creation
…line before INPUTS section
… improve readability of return values
…on to improve readability and detail of returned objects
…n to specify return values based on alert properties.
…arity and consistency
…on to specify that no output is generated by default.
…n to specify that no output is generated by default.
…to specify return value based on database properties state.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
source/Public/Set-SqlDscAudit.ps1 (1)
77-86: INPUTS/OUTPUTS now correctly aligned with pipeline parameters and return typeThe new
.INPUTSentries accurately reflect the two pipeline-accepted types and follow the backtick/indentation pattern, and.OUTPUTSnow matches[OutputType([Microsoft.SqlServer.Management.Smo.Audit])]and the actualPassThrubehavior.As optional polish, you could make the description a full sentence for readability and match the style used in other cmdlets, for example:
- `Microsoft.SqlServer.Management.Smo.Audit` - - When passing parameter **PassThru**. + `Microsoft.SqlServer.Management.Smo.Audit` + + Returns the updated audit object when using the **PassThru** parameter.If you want perfect symmetry with
New-SqlDscAgentAlert, you could also add a second.OUTPUTSblock forNone.with a short description like “No output when the PassThru parameter is not specified.”, but the current form already meets the documented guidelines.Also applies to: 88-90
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (45)
source/Private/ConvertTo-ManagedServiceType.ps1(1 hunks)source/Private/ConvertTo-RedactedText.ps1(1 hunks)source/Public/Assert-SqlDscLogin.ps1(2 hunks)source/Public/Connect-SqlDscDatabaseEngine.ps1(1 hunks)source/Public/ConvertTo-SqlDscEditionName.ps1(1 hunks)source/Public/ConvertTo-SqlDscFileGroup.ps1(1 hunks)source/Public/Disconnect-SqlDscDatabaseEngine.ps1(1 hunks)source/Public/Enable-SqlDscAudit.ps1(1 hunks)source/Public/Get-SqlDscAgentAlert.ps1(1 hunks)source/Public/Get-SqlDscAgentOperator.ps1(1 hunks)source/Public/Get-SqlDscDatabase.ps1(1 hunks)source/Public/Get-SqlDscDatabasePermission.ps1(1 hunks)source/Public/Get-SqlDscManagedComputer.ps1(1 hunks)source/Public/Get-SqlDscManagedComputerService.ps1(1 hunks)source/Public/Get-SqlDscPreferredModule.ps1(1 hunks)source/Public/Get-SqlDscRSSetupConfiguration.ps1(1 hunks)source/Public/Get-SqlDscRole.ps1(1 hunks)source/Public/Get-SqlDscServerPermission.ps1(1 hunks)source/Public/Grant-SqlDscServerPermission.ps1(1 hunks)source/Public/Import-SqlDscPreferredModule.ps1(1 hunks)source/Public/Install-SqlDscBIReportServer.ps1(1 hunks)source/Public/Install-SqlDscReportingService.ps1(2 hunks)source/Public/New-SqlDscAgentAlert.ps1(1 hunks)source/Public/New-SqlDscAudit.ps1(1 hunks)source/Public/New-SqlDscDatabase.ps1(1 hunks)source/Public/New-SqlDscRole.ps1(1 hunks)source/Public/Remove-SqlDscAudit.ps1(1 hunks)source/Public/Remove-SqlDscDatabase.ps1(1 hunks)source/Public/Remove-SqlDscNode.ps1(1 hunks)source/Public/Remove-SqlDscRole.ps1(1 hunks)source/Public/Remove-SqlDscTraceFlag.ps1(1 hunks)source/Public/Repair-SqlDscReportingService.ps1(2 hunks)source/Public/Repair-SqlDscServer.ps1(1 hunks)source/Public/Revoke-SqlDscServerPermission.ps1(1 hunks)source/Public/Set-SqlDscAudit.ps1(1 hunks)source/Public/Set-SqlDscStartupParameter.ps1(1 hunks)source/Public/Test-SqlDscAgentAlertProperty.ps1(1 hunks)source/Public/Test-SqlDscDatabaseProperty.ps1(1 hunks)source/Public/Test-SqlDscIsDatabasePrincipal.ps1(1 hunks)source/Public/Test-SqlDscIsLogin.ps1(1 hunks)source/Public/Test-SqlDscIsLoginEnabled.ps1(1 hunks)source/Public/Test-SqlDscIsRole.ps1(1 hunks)source/Public/Test-SqlDscServerPermission.ps1(1 hunks)source/Public/Uninstall-SqlDscBIReportServer.ps1(1 hunks)source/Public/Uninstall-SqlDscReportingService.ps1(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- source/Public/New-SqlDscDatabase.ps1
- source/Public/Test-SqlDscDatabaseProperty.ps1
- source/Public/Set-SqlDscStartupParameter.ps1
- source/Public/ConvertTo-SqlDscEditionName.ps1
🚧 Files skipped from review as they are similar to previous changes (23)
- source/Public/Uninstall-SqlDscBIReportServer.ps1
- source/Public/New-SqlDscAudit.ps1
- source/Public/Remove-SqlDscDatabase.ps1
- source/Public/Enable-SqlDscAudit.ps1
- source/Public/Repair-SqlDscServer.ps1
- source/Public/Remove-SqlDscTraceFlag.ps1
- source/Public/Get-SqlDscServerPermission.ps1
- source/Public/Get-SqlDscRSSetupConfiguration.ps1
- source/Public/Get-SqlDscAgentOperator.ps1
- source/Public/Test-SqlDscIsDatabasePrincipal.ps1
- source/Public/Get-SqlDscManagedComputerService.ps1
- source/Private/ConvertTo-ManagedServiceType.ps1
- source/Public/Get-SqlDscAgentAlert.ps1
- source/Public/Test-SqlDscAgentAlertProperty.ps1
- source/Public/Test-SqlDscServerPermission.ps1
- source/Public/Get-SqlDscPreferredModule.ps1
- source/Public/Uninstall-SqlDscReportingService.ps1
- source/Public/Get-SqlDscDatabasePermission.ps1
- source/Public/Repair-SqlDscReportingService.ps1
- source/Public/ConvertTo-SqlDscFileGroup.ps1
- source/Public/Remove-SqlDscNode.ps1
- source/Public/Import-SqlDscPreferredModule.ps1
- source/Public/Install-SqlDscBIReportServer.ps1
🧰 Additional context used
📓 Path-based instructions (7)
**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
**/*.ps1: Format public commands as{Verb}-SqlDsc{Noun}following PowerShell naming conventions
Format private functions as{Verb}-{Noun}following PowerShell naming conventions
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
source/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-localization.instructions.md)
source/**/*.ps1: Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages in PowerShell scripts
Use localized string keys from $script:localizedData, not hardcoded strings, in diagnostic messages
Reference localized strings using the syntax: Write-Verbose -Message ($script:localizedData.KeyName -f $value1)Localize all strings using string keys; remove any orphaned string keys
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
**/*.{ps1,psm1,psd1}
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-powershell.instructions.md)
**/*.{ps1,psm1,psd1}: Use descriptive names with 3+ characters and no abbreviations for functions, variables, and identifiers
Functions: Use PascalCase with Verb-Noun format using approved verbs
Parameters: Use PascalCase
Variables: Use camelCase
Keywords: Use lower-case
Classes: Use PascalCase
Include scope for script/global/environment variables:$script:,$global:,$env:
Use 4 spaces for indentation (no tabs)
Use one space around operators:$a = 1 + 2
Use one space between type and variable:[String] $name
Use one space between keyword and parenthesis:if ($condition)
No spaces on empty lines
Try to limit lines to 120 characters
Newline before opening brace (except variable assignments)
One newline after opening brace
Two newlines after closing brace (one if followed by another brace or continuation)
Use single quotes unless variable expansion is needed:'text'vs"text $variable"
Single-line arrays:@('one', 'two', 'three'); multi-line: each element on separate line with proper indentation
Do not use the unary comma operator (,) in return statements to force an array
Empty hashtables:@{}; each property on separate line with proper indentation; use PascalCase for properties
Single-line comments:# Comment(capitalized, on own line); multi-line:<# Comment #>format with opening/closing brackets on own line
Do not include commented-out code
Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Comment-based help indentation: keywords 4 spaces, text 8 spaces
Include examples in comment-based help for all parameter sets and combinations
INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both[OutputType()]and actual ret...
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
source/Public/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Public commands should be located in
source/Public/{CommandName}.ps1
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Classes:
source/Classes/{DependencyGroupNumber}.{ClassName}.ps1- Enums:
source/Enum/{DependencyGroupNumber}.{EnumName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type as inline code with a 1‑line description...
Files:
source/Public/Set-SqlDscAudit.ps1source/Public/Test-SqlDscIsLogin.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Test-SqlDscIsLoginEnabled.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
source/Private/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Private functions should be located in
source/Private/{FunctionName}.ps1
Files:
source/Private/ConvertTo-RedactedText.ps1
🧠 Learnings (34)
📓 Common learnings
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include examples in comment-based help for all parameter sets and combinations
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : .NOTES section in comment-based help: include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior); keep to ≤2 short sentences
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Comment-based help indentation: keywords 4 spaces, text 8 spaces
📚 Learning: 2025-10-03T15:27:24.417Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Applied to files:
source/Public/Set-SqlDscAudit.ps1source/Public/Remove-SqlDscAudit.ps1source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Public/Grant-SqlDscServerPermission.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Applied to files:
source/Public/Set-SqlDscAudit.ps1source/Public/Get-SqlDscRole.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Revoke-SqlDscServerPermission.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1source/Public/Test-SqlDscIsRole.ps1source/Public/Grant-SqlDscServerPermission.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Applied to files:
source/Public/Set-SqlDscAudit.ps1source/Public/Get-SqlDscRole.ps1source/Public/New-SqlDscAgentAlert.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-09-13T10:13:47.123Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Applied to files:
source/Public/Set-SqlDscAudit.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/tests/Integration/**/*.ps1 : Integration tests: use `Connect-SqlDscDatabaseEngine` for SQL Server DB session with correct CI credentials, and always follow with `Disconnect-SqlDscDatabaseEngine`
Applied to files:
source/Public/Test-SqlDscIsLogin.ps1source/Public/Disconnect-SqlDscDatabaseEngine.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/resources/**/*.ps1 : Add `InstanceName`, `ServerName`, and `Credential` to `$this.ExcludeDscProperties` in Database Engine resources
Applied to files:
source/Public/Get-SqlDscRole.ps1source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-10-19T10:33:22.772Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2309
File: tests/Integration/Commands/Initialize-SqlDscRebuildDatabase.Integration.Tests.ps1:132-148
Timestamp: 2025-10-19T10:33:22.772Z
Learning: In SqlServerDsc integration tests, when connecting via Connect-SqlDscDatabaseEngine using a local Windows account (e.g., 'SqlAdmin'), use the plain username format without computer/domain prefix. This is Windows Authentication with a local account. The NetBIOS format (e.g., 'COMPUTER\SqlAdmin') is only used for SqlSysAdminAccounts during SQL Server setup/rebuild and will throw an exception if used with Connect-SqlDscDatabaseEngine for local Windows accounts.
Applied to files:
source/Public/Connect-SqlDscDatabaseEngine.ps1
📚 Learning: 2025-11-27T17:58:02.422Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.422Z
Learning: Applies to **/*.ps1 : Format public commands as `{Verb}-SqlDsc{Noun}` following PowerShell naming conventions
Applied to files:
source/Public/Connect-SqlDscDatabaseEngine.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include `[OutputType({return type})]` for functions with output; use `[OutputType()]` for no output
Applied to files:
source/Public/Connect-SqlDscDatabaseEngine.ps1source/Public/Assert-SqlDscLogin.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Applied to files:
source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Applied to files:
source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1source/Private/ConvertTo-RedactedText.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-11-27T17:58:20.404Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources may optionally implement methods: `AssertProperties()` and `NormalizeProperties()` following the specified pattern
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-10-03T15:27:39.511Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Applied to files:
source/Public/Assert-SqlDscLogin.ps1source/Public/Get-SqlDscDatabase.ps1source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1source/Public/New-SqlDscRole.ps1
📚 Learning: 2025-11-27T17:59:27.205Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.205Z
Learning: Applies to **/*.[Tt]ests.ps1 : Pass all mandatory parameters to avoid prompts
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-10-25T09:10:29.033Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2317
File: source/Public/Test-SqlDscDatabaseProperty.ps1:507-509
Timestamp: 2025-10-25T09:10:29.033Z
Learning: In PowerShell functions with multiple parameter sets: If a parameter is declared in multiple parameter sets AND accepts pipeline input (ValueFromPipeline=$true), then the ValueFromPipeline attribute must be specified consistently across all parameter set declarations for that parameter. This does not mean a pipeline parameter must be added to every parameter set in the function—parameters can be exclusive to specific parameter sets.
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Use splatting for long parameter lists
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Use named parameters in function calls
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-08-17T10:59:03.955Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2136
File: source/Public/Remove-SqlDscLogin.ps1:59-77
Timestamp: 2025-08-17T10:59:03.955Z
Learning: In PowerShell, mandatory parameters with [Parameter(Mandatory = $true)] automatically guard against $null values and don't require additional [ValidateNotNull()] or [ValidateNotNullOrEmpty()] attributes, as these validations are redundant with the mandatory parameter behavior.
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:35.078Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T18:00:35.078Z
Learning: Follow PowerShell style and test guideline instructions strictly
Applied to files:
source/Public/Assert-SqlDscLogin.ps1source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : `ValueFromPipeline` must be consistent across all parameter sets declarations for the same parameter
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Limit piping to one pipe per line
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : All parameters must use `[Parameter()]` attribute; mandatory parameters use `[Parameter(Mandatory = $true)]`
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Parameters: Use PascalCase
Applied to files:
source/Public/Assert-SqlDscLogin.ps1
📚 Learning: 2025-11-27T17:59:01.508Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.508Z
Learning: Applies to source/DSCResources/**/*.psm1 : Unused mandatory parameters in `Set-TargetResource` and `Test-TargetResource` should include "Not used in <function_name>" in the help comment
Applied to files:
source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Avoid `Write-Output`; use `return` instead
Applied to files:
source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Comment-based help indentation: keywords 4 spaces, text 8 spaces
Applied to files:
source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Use 4 spaces for indentation (no tabs)
Applied to files:
source/Public/Install-SqlDscReportingService.ps1source/Public/Get-SqlDscManagedComputer.ps1source/Public/Test-SqlDscIsRole.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : For state-changing functions, use `SupportsShouldProcess`; place ShouldProcess check immediately before each state-change; set `ConfirmImpact` to 'Low', 'Medium', or 'High'
Applied to files:
source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-08-18T10:44:38.990Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2132
File: source/Public/New-SqlDscLogin.ps1:254-257
Timestamp: 2025-08-18T10:44:38.990Z
Learning: When implementing Force and Confirm parameter interaction in PowerShell functions with SupportsShouldProcess, use the pattern `if ($Force.IsPresent -and -not $Confirm)` to suppress confirmations. This ensures that explicit `-Confirm:$true` is respected even when `-Force` is present, preserving user intent when they explicitly request confirmation alongside Force.
Applied to files:
source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-08-17T10:03:59.993Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2136
File: source/Public/Remove-SqlDscLogin.ps1:83-86
Timestamp: 2025-08-17T10:03:59.993Z
Learning: In PowerShell functions with SupportsShouldProcess, the $Confirm automatic variable defaults to $false when no -Confirm parameter is passed, and only becomes $true when -Confirm or -Confirm:$true is explicitly passed. The logic `if ($Force.IsPresent -and -not $Confirm)` correctly handles both cases where no -Confirm is passed and where -Confirm:$false is explicitly passed.
Applied to files:
source/Public/Install-SqlDscReportingService.ps1
📚 Learning: 2025-11-22T17:36:09.703Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Applied to files:
source/Public/Get-SqlDscManagedComputer.ps1source/Public/Remove-SqlDscRole.ps1
📚 Learning: 2025-11-27T17:58:20.404Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Applied to files:
source/Public/Get-SqlDscManagedComputer.ps1
📚 Learning: 2025-11-27T17:57:47.617Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T17:57:47.617Z
Learning: SqlServerDsc-specific guidelines and requirements override general project guidelines and requirements
Applied to files:
source/Public/New-SqlDscRole.ps1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
- GitHub Check: PSScriptAnalyzer
- GitHub Check: PSScriptAnalyzer
🔇 Additional comments (20)
source/Public/Revoke-SqlDscServerPermission.ps1 (1)
30-38: LGTM! INPUTS sections correctly formatted.The added
.INPUTSsections properly document both pipeline-accepted types with correct formatting:
- Type names are formatted as inline code with backticks
- Each type has a one-line description
- The
.INPUTSkeyword is correctly repeated for each type- Types match the parameters with
ValueFromPipeline = $true- Indentation follows the guidelines (keywords at 4 spaces, text at 8 spaces)
The OUTPUTS section correctly states "None." and matches the
[OutputType()]attribute.Based on learnings, this follows the established pattern for PowerShell comment-based help.
source/Private/ConvertTo-RedactedText.ps1 (2)
31-39: .INPUTS/.OUTPUTS formatting and semantics look correctThe new
.INPUTSand.OUTPUTSentries correctly:
- Use inline-code type names.
- Repeat the keyword per type.
- Document only the pipeline-accepted input (
System.String) and the single output type (System.String) with concise 1‑line descriptions.This matches both the function signature and actual behavior, and aligns with the repository’s comment-based help guidelines. Based on learnings, this is consistent with the required OUTPUTS conventions.
44-44: [OutputType] attribute matches implementation and help
[OutputType([System.String])]accurately reflects the function’s return type ($redactedTextis always aSystem.String) and is consistent with the.OUTPUTShelp entry.source/Public/Remove-SqlDscAudit.ps1 (1)
40-51: LGTM! Documentation properly formatted.The
.INPUTSand.OUTPUTSsections are correctly formatted according to the DSC Community style guidelines:
- Both pipeline-accepted types (
Microsoft.SqlServer.Management.Smo.ServerandMicrosoft.SqlServer.Management.Smo.Audit) are documented with the.INPUTSkeyword repeated for each type.- Types are formatted as inline code with backticks.
- Each input has a clear one-line description.
- The
.OUTPUTSsection correctly specifiesNone.matching the[OutputType()]attribute.- Indentation follows the required pattern (4 spaces for keywords, 8 for text).
source/Public/Remove-SqlDscRole.ps1 (1)
46-55: LGTM! .INPUTS sections correctly document pipeline parameters.The additions correctly follow the comment-based help guidelines:
- Each pipeline-accepted type has its own
.INPUTSkeyword- Type names are formatted as inline code with backticks
- One-line descriptions provided for each
- Indentation is correct (keywords at 4 spaces, text at 8 spaces)
- Both types match the actual
ValueFromPipelineparameters in the functionBased on learnings and coding guidelines.
source/Public/Get-SqlDscManagedComputer.ps1 (1)
22-28: Comment-based help for.INPUTS/.OUTPUTSnow matches style and behavior
.INPUTScorrectly documents that there is no pipeline input (None.), and.OUTPUTSnow lists the concrete return type with a clear one-line description that matches both[OutputType([Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer])]and the actualreturnvalue. Indentation of keywords and text also follows the documented comment-based help format.As per coding guidelines, this aligns with the required INPUTS/OUTPUTS pattern.
source/Public/Disconnect-SqlDscDatabaseEngine.ps1 (2)
25-28: LGTM! INPUTS section correctly formatted.The
.INPUTSsection properly documents the pipeline-accepted type with inline code formatting (backticks) and a concise description, matching both the style guidelines and the$ServerObjectparameter'sValueFromPipeline = $trueattribute.
36-36: LGTM! OutputType attribute corrected.The
[OutputType()]attribute now correctly reflects that this function performs an action (disconnecting) without returning a value, aligning with both the implementation and the.OUTPUTSsection that specifies "None."source/Public/Test-SqlDscIsLogin.ps1 (1)
14-22: LGTM! Comment-based help sections correctly formatted.The
.INPUTSand.OUTPUTSsections correctly follow the DSC Community style guidelines:
- Input type
Microsoft.SqlServer.Management.Smo.Servermatches the pipeline-accepted parameter- Output type
System.Booleanmatches both the[OutputType()]attribute and actual return value- Types are properly formatted as inline code with backticks
- Descriptions are clear and accurate
source/Public/Test-SqlDscIsLoginEnabled.ps1 (1)
26-39: LGTM! Comment-based help sections correctly formatted.The
.INPUTSand.OUTPUTSsections correctly follow the DSC Community style guidelines:
- Two input types properly documented with repeated
.INPUTSkeyword:
Microsoft.SqlServer.Management.Smo.Servermatches the ServerObject pipeline parameterMicrosoft.SqlServer.Management.Smo.Loginmatches the LoginObject pipeline parameter- Output type
System.Booleanmatches both the[OutputType()]attribute and actual return value- All types are properly formatted as inline code with backticks
- Descriptions are clear and accurate
Based on learnings, repeating the
.INPUTSkeyword for each distinct input type is the correct approach per official PowerShell documentation standards.source/Public/Get-SqlDscDatabase.ps1 (1)
35-39: .INPUTS/.OUTPUTS help matches parameter types, OutputType, and style guidelinesThe
.INPUTSentry correctly documents theMicrosoft.SqlServer.Management.Smo.Serverpipeline input, and the.OUTPUTSentry now matches both[OutputType([Microsoft.SqlServer.Management.Smo.Database[]])]and the finalreturn [Microsoft.SqlServer.Management.Smo.Database[]] $databaseObject, with proper inline-code formatting and 1‑line descriptions. This is aligned with the updated INPUTS/OUTPUTS formatting rules.Also applies to: 41-43
source/Public/Assert-SqlDscLogin.ps1 (2)
28-35: .INPUTS/.OUTPUTS help formatting looks correct and consistentThe
.INPUTSentry correctly documents the pipeline typeMicrosoft.SqlServer.Management.Smo.Serverwith a one‑line description, and.OUTPUTSis set toNone.for a command that does not write to the pipeline. Indentation and keyword usage match the documented comment‑based help style (4/8 spaces, one keyword per type).If you want to double‑check behavior, you can run
Get-Help Assert-SqlDscLogin -Fullto verify the rendered INPUTS/OUTPUTS sections match expectations. As per coding guidelines, this aligns with the required pattern for documenting inputs/outputs.
44-44:[OutputType()]correctly declares no pipeline outputUsing an empty
[OutputType()]here is appropriate for a command that only asserts and throws on failure without emitting objects, and it matches the.OUTPUTShelp ofNone.so tooling and documentation stay in sync.If needed, you can verify with
Get-Command Assert-SqlDscLogin | Select-Object -ExpandProperty OutputTypeto confirm it reports no output types. As per coding guidelines, this is the recommended way to model “no output”.source/Public/Test-SqlDscIsRole.ps1 (1)
14-22: INPUTS/OUTPUTS help correctly aligned with implementation and guidelines.
.INPUTSdocuments the pipeline-acceptedMicrosoft.SqlServer.Management.Smo.Servercorrectly, and.OUTPUTSdocumentsSystem.Booleanmatching both[OutputType([System.Boolean])]and the actual return value. Indentation, backtick usage, and 1‑line descriptions follow the prescribed style.As per coding guidelines, this formatting and type alignment look correct.
source/Public/Get-SqlDscRole.ps1 (1)
35-43: INPUTS/OUTPUTS help now correctly reflects pipeline type and return type
.INPUTSdocuments theMicrosoft.SqlServer.Management.Smo.Serverpipeline input forServerObject, and.OUTPUTScorrectly documentsMicrosoft.SqlServer.Management.Smo.ServerRole[]with a one-line description that matches[OutputType()]and the final casted return value. Indentation and formatting align with the DSC Community PowerShell help guidelines.
As per coding guidelines, this is consistent and complete.source/Public/New-SqlDscRole.ps1 (1)
41-49: Comment-based INPUTS/OUTPUTS now match the function signature and behaviorThe
.INPUTSentry correctly documentsMicrosoft.SqlServer.Management.Smo.Serveras the pipeline input forServerObject, and.OUTPUTSnow listsMicrosoft.SqlServer.Management.Smo.ServerRolewith a clear one-line description that matches[OutputType()]and the returned$serverRole. Indentation and layout follow the project’s help formatting rules.
As per coding guidelines, this is the expected structure.source/Public/New-SqlDscAgentAlert.ps1 (1)
29-41: Comment-based help now fully matches OUTPUTS guidelines and implementationThe updated
.INPUTSand.OUTPUTSsections look good: the Server input and Alert output are correctly backticked, the Alert output matches[OutputType()]and thePassThru-based return, and the separateNone.entry clearly documents the default no-output case. Formatting and indentation are consistent with the PowerShell/DSC style guidelines.source/Public/Grant-SqlDscServerPermission.ps1 (1)
29-37: .INPUTS help correctly documents pipeline-accepted principal typesThe two
.INPUTSentries now listMicrosoft.SqlServer.Management.Smo.LoginandMicrosoft.SqlServer.Management.Smo.ServerRolewith 1‑line descriptions, matching theLoginandServerRoleparameters that accept pipeline input and keeping.OUTPUTS=None.in sync with[OutputType()]. This aligns with the documented INPUTS/OUTPUTS help pattern.As per coding guidelines, this matches the “repeat keyword per type with 1‑line description” rule.
source/Public/Install-SqlDscReportingService.ps1 (1)
59-70: INPUTS/OUTPUTS help and OutputType metadata now correctly reflect PassThru behavior
.INPUTSis explicitlyNone., and.OUTPUTSnow documents both the default no‑output case (None.with explanation) and theSystem.Int32exit code when-PassThruis used. The added empty[OutputType()]alongside[OutputType([System.Int32])]matches these two cases and the implementation (return $exitCodeonly when$PassThru.IsPresent). This is consistent with the established pattern for functions with optionalPassThruoutputs.Based on learnings, this matches the documented approach for dual None/typed outputs with PassThru.
Also applies to: 102-102
source/Public/Connect-SqlDscDatabaseEngine.ps1 (1)
62-69: Help OUTPUTS and OutputType for Connect-SqlDscDatabaseEngine are aligned with actual return typeThe
.INPUTSsection correctly declaresNone., and.OUTPUTSnow documents theMicrosoft.SqlServer.Management.Smo.Serverreturn type with an inline‑code type name and 1‑line description. The added[OutputType([Microsoft.SqlServer.Management.Smo.Server])]attribute matches both the help text and the function’s behavior (returning the server object fromConnect-Sql).As per coding guidelines, this satisfies the requirement that OUTPUTS and
[OutputType()]agree with real outputs.Also applies to: 72-73
…eturn values based on the PassThru parameter.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2358 +/- ##
====================================
Coverage 94% 94%
====================================
Files 166 166
Lines 9765 9765
====================================
Hits 9206 9206
Misses 559 559
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
source/Public/Set-SqlDscDatabasePermission.ps1 (1)
34-37: LGTM! The .INPUTS section follows the required format.The addition correctly documents the pipeline input, matches the
ServerObjectparameter'sValueFromPipelineattribute, and follows the DSC Community style guidelines for indentation and inline code formatting.Optional: Consider a more descriptive explanation.
While "Accepts input via the pipeline" is accurate, you could make it more specific:
.INPUTS `Microsoft.SqlServer.Management.Smo.Server` - Accepts input via the pipeline. + The SQL Server instance connection object to configure.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
source/Public/Initialize-SqlDscRebuildDatabase.ps1(1 hunks)source/Public/Install-SqlDscServer.ps1(1 hunks)source/Public/Set-SqlDscDatabasePermission.ps1(1 hunks)source/Public/Set-SqlDscServerPermission.ps1(1 hunks)source/Public/Set-SqlDscTraceFlag.ps1(1 hunks)source/Public/Test-SqlDscIsSupportedFeature.ps1(1 hunks)source/Public/Uninstall-SqlDscServer.ps1(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- source/Public/Set-SqlDscTraceFlag.ps1
- source/Public/Install-SqlDscServer.ps1
- source/Public/Uninstall-SqlDscServer.ps1
- source/Public/Initialize-SqlDscRebuildDatabase.ps1
- source/Public/Set-SqlDscServerPermission.ps1
🧰 Additional context used
📓 Path-based instructions (6)
**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
**/*.ps1: Format public commands as{Verb}-SqlDsc{Noun}following PowerShell naming conventions
Format private functions as{Verb}-{Noun}following PowerShell naming conventions
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
source/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-localization.instructions.md)
source/**/*.ps1: Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages in PowerShell scripts
Use localized string keys from $script:localizedData, not hardcoded strings, in diagnostic messages
Reference localized strings using the syntax: Write-Verbose -Message ($script:localizedData.KeyName -f $value1)Localize all strings using string keys; remove any orphaned string keys
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
**/*.{ps1,psm1,psd1}
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-powershell.instructions.md)
**/*.{ps1,psm1,psd1}: Use descriptive names with 3+ characters and no abbreviations for functions, variables, and identifiers
Functions: Use PascalCase with Verb-Noun format using approved verbs
Parameters: Use PascalCase
Variables: Use camelCase
Keywords: Use lower-case
Classes: Use PascalCase
Include scope for script/global/environment variables:$script:,$global:,$env:
Use 4 spaces for indentation (no tabs)
Use one space around operators:$a = 1 + 2
Use one space between type and variable:[String] $name
Use one space between keyword and parenthesis:if ($condition)
No spaces on empty lines
Try to limit lines to 120 characters
Newline before opening brace (except variable assignments)
One newline after opening brace
Two newlines after closing brace (one if followed by another brace or continuation)
Use single quotes unless variable expansion is needed:'text'vs"text $variable"
Single-line arrays:@('one', 'two', 'three'); multi-line: each element on separate line with proper indentation
Do not use the unary comma operator (,) in return statements to force an array
Empty hashtables:@{}; each property on separate line with proper indentation; use PascalCase for properties
Single-line comments:# Comment(capitalized, on own line); multi-line:<# Comment #>format with opening/closing brackets on own line
Do not include commented-out code
Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Comment-based help indentation: keywords 4 spaces, text 8 spaces
Include examples in comment-based help for all parameter sets and combinations
INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both[OutputType()]and actual ret...
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
source/Public/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Public commands should be located in
source/Public/{CommandName}.ps1
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Classes:
source/Classes/{DependencyGroupNumber}.{ClassName}.ps1- Enums:
source/Enum/{DependencyGroupNumber}.{EnumName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type as inline code with a 1‑line description...
Files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
🧠 Learnings (8)
📓 Common learnings
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include examples in comment-based help for all parameter sets and combinations
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Comment-based help indentation: keywords 4 spaces, text 8 spaces
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : .NOTES section in comment-based help: include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior); keep to ≤2 short sentences
📚 Learning: 2025-10-03T15:27:24.417Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
📚 Learning: 2025-10-03T15:27:39.511Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
📚 Learning: 2025-11-27T17:59:01.508Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.508Z
Learning: Applies to source/DSCResources/**/*.psm1 : `Test-TargetResource` function must return a boolean value ($true or $false)
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1source/Public/Set-SqlDscDatabasePermission.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : For state-changing functions, use `SupportsShouldProcess`; place ShouldProcess check immediately before each state-change; set `ConfirmImpact` to 'Low', 'Medium', or 'High'
Applied to files:
source/Public/Test-SqlDscIsSupportedFeature.ps1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
- GitHub Check: PSScriptAnalyzer
- GitHub Check: PSScriptAnalyzer
🔇 Additional comments (1)
source/Public/Test-SqlDscIsSupportedFeature.ps1 (1)
20-28: .INPUTS/.OUTPUTS help now matches style and implementationThe updated comment-based help looks good:
.INPUTScorrectly documents a singleSystem.Stringvalue accepted from the pipeline for-Feature..OUTPUTSnow uses inline-codeSystem.Booleanand the type matches both[OutputType([System.Boolean])]and the actual$true/$falsereturn from$supported.No further changes needed here.
As per coding guidelines, this satisfies the INPUTS/OUTPUTS documentation requirements.
…to specify the SQL Server instance connection object.
…pecify that a server instance object can be piped to the command.
…eFlag documentation
johlju
left a comment
There was a problem hiding this comment.
@johlju reviewed 27 of 87 files at r1, 42 of 63 files at r2, 52 of 52 files at r3, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @johlju)
johlju
left a comment
There was a problem hiding this comment.
@johlju reviewed 4 of 4 files at r4, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @johlju)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
source/Public/Get-SqlDscTraceFlag.ps1 (1)
43-47: Align.INPUTS/.OUTPUTSwith style guideline (inline code + description).Two small doc tweaks to fully match the documented conventions and issue #2103:
- Line 44 (.INPUTS): You correctly document that there is no pipeline input, but the guideline says to specify
None.as inline code. Consider changing the text to use backticks:`None.`- Line 47 (.OUTPUTS): The type
System.UInt32[]matches both[OutputType([System.UInt32[]])]and the actual return, but the guideline and the issue description both require a one‑line description for each output type. Suggest adding a short description line, for example:`System.UInt32[]` Current trace flags as unsigned 32-bit integer values.This keeps the help consistent with the repo’s comment-based help requirements and the patterns used in other cmdlets. As per coding guidelines and based on learnings, …
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
source/Public/Get-SqlDscServerProtocol.ps1(1 hunks)source/Public/Get-SqlDscTraceFlag.ps1(1 hunks)source/Public/Set-SqlDscAgentAlert.ps1(1 hunks)source/Public/Set-SqlDscDatabasePermission.ps1(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- source/Public/Set-SqlDscDatabasePermission.ps1
🧰 Additional context used
📓 Path-based instructions (6)
**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
**/*.ps1: Format public commands as{Verb}-SqlDsc{Noun}following PowerShell naming conventions
Format private functions as{Verb}-{Noun}following PowerShell naming conventions
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
source/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-localization.instructions.md)
source/**/*.ps1: Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages in PowerShell scripts
Use localized string keys from $script:localizedData, not hardcoded strings, in diagnostic messages
Reference localized strings using the syntax: Write-Verbose -Message ($script:localizedData.KeyName -f $value1)Localize all strings using string keys; remove any orphaned string keys
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
**/*.{ps1,psm1,psd1}
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-powershell.instructions.md)
**/*.{ps1,psm1,psd1}: Use descriptive names with 3+ characters and no abbreviations for functions, variables, and identifiers
Functions: Use PascalCase with Verb-Noun format using approved verbs
Parameters: Use PascalCase
Variables: Use camelCase
Keywords: Use lower-case
Classes: Use PascalCase
Include scope for script/global/environment variables:$script:,$global:,$env:
Use 4 spaces for indentation (no tabs)
Use one space around operators:$a = 1 + 2
Use one space between type and variable:[String] $name
Use one space between keyword and parenthesis:if ($condition)
No spaces on empty lines
Try to limit lines to 120 characters
Newline before opening brace (except variable assignments)
One newline after opening brace
Two newlines after closing brace (one if followed by another brace or continuation)
Use single quotes unless variable expansion is needed:'text'vs"text $variable"
Single-line arrays:@('one', 'two', 'three'); multi-line: each element on separate line with proper indentation
Do not use the unary comma operator (,) in return statements to force an array
Empty hashtables:@{}; each property on separate line with proper indentation; use PascalCase for properties
Single-line comments:# Comment(capitalized, on own line); multi-line:<# Comment #>format with opening/closing brackets on own line
Do not include commented-out code
Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Comment-based help indentation: keywords 4 spaces, text 8 spaces
Include examples in comment-based help for all parameter sets and combinations
INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both[OutputType()]and actual ret...
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
source/Public/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Public commands should be located in
source/Public/{CommandName}.ps1
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Classes:
source/Classes/{DependencyGroupNumber}.{ClassName}.ps1- Enums:
source/Enum/{DependencyGroupNumber}.{EnumName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type as inline code with a 1‑line description...
Files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
🧠 Learnings (9)
📓 Common learnings
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both `[OutputType()]` and actual returns
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2204
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:67-68
Timestamp: 2025-09-13T10:13:47.123Z
Learning: According to official Microsoft PowerShell documentation, both .INPUTS and .OUTPUTS keywords should be repeated for each type in comment-based help: "Repeat this keyword for each input type" and "Repeat this keyword for each output type". The guideline should instruct to repeat both keywords, not use single blocks.
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : .NOTES section in comment-based help: include only if it conveys critical info (constraints, side effects, security, version compatibility, breaking behavior); keep to ≤2 short sentences
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Include examples in comment-based help for all parameter sets and combinations
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help .OUTPUTS sections: Each distinct return type should have its own .OUTPUTS entry with a description of when that type is returned, even if the underlying implementation uses array casting. This follows official PowerShell documentation standards where you list each return type on its own line under .OUTPUTS with clear descriptions of the conditions for each type.
Applied to files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1
📚 Learning: 2025-08-16T13:15:17.108Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: source/Public/Get-SqlDscLogin.ps1:27-38
Timestamp: 2025-08-16T13:15:17.108Z
Learning: For PowerShell comment-based help in .OUTPUTS sections: Each distinct type that can be returned should have its own .OUTPUTS entry, even if the implementation technically always returns an array. This follows official PowerShell documentation standards and helps users understand what to expect in different usage scenarios.
Applied to files:
source/Public/Get-SqlDscTraceFlag.ps1
📚 Learning: 2025-10-03T15:27:24.417Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:9-22
Timestamp: 2025-10-03T15:27:24.417Z
Learning: In the UpdateServicesDsc repository, MOF-based DSC resources follow a minimal comment-based help convention that includes only .SYNOPSIS and .PARAMETER sections. The .DESCRIPTION, .INPUTS, and .OUTPUTS sections are intentionally omitted, even though functions have [OutputType()] attributes. This is consistent across all existing DSC resources: MSFT_UpdateServicesServer, MSFT_UpdateServicesCleanup, and MSFT_UpdateServicesApprovalRule.
Applied to files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1source/Public/Set-SqlDscAgentAlert.ps1
📚 Learning: 2025-10-03T15:27:39.511Z
Learnt from: Borgquite
Repo: dsccommunity/UpdateServicesDsc PR: 78
File: source/DSCResources/MSFT_UpdateServicesComputerTargetGroup/MSFT_UpdateServicesComputerTargetGroup.psm1:91-109
Timestamp: 2025-10-03T15:27:39.511Z
Learning: For MOF-based DSC resources in DSC Community repositories (files matching `source/DSCResources/MSFT_*/MSFT_*.psm1`), the comment-based help for `Get-TargetResource`, `Set-TargetResource`, and `Test-TargetResource` functions should NOT include `.OUTPUTS` sections, even though the general PowerShell guidelines require them. This is an established pattern in the DSC Community.
Applied to files:
source/Public/Get-SqlDscTraceFlag.ps1source/Public/Get-SqlDscServerProtocol.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
Applied to files:
source/Public/Get-SqlDscTraceFlag.ps1
📚 Learning: 2025-11-22T17:36:09.703Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2343
File: source/Classes/004.DatabaseFileGroupSpec.ps1:5-34
Timestamp: 2025-11-22T17:36:09.703Z
Learning: The comment-based help requirements for ## Requirements and ## Known issues sections only apply to class-based DSC resources (classes decorated with [DscResource(...)]) in source/Classes/**/*.ps1, not to regular helper classes, DTO classes, or specification classes in the same directory.
Applied to files:
source/Public/Get-SqlDscServerProtocol.ps1
📚 Learning: 2025-11-27T17:58:20.404Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-class-resource.instructions.md:0-0
Timestamp: 2025-11-27T17:58:20.404Z
Learning: Applies to source/[cC]lasses/**/*.ps1 : DSC class-based resources must include comment-based help with .DESCRIPTION section containing Requirements and Known issues sections with a link to all open issues on GitHub
Applied to files:
source/Public/Get-SqlDscServerProtocol.ps1
📚 Learning: 2025-11-27T18:00:11.970Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.970Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Applied to files:
source/Public/Get-SqlDscServerProtocol.ps1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
- GitHub Check: PSScriptAnalyzer
- GitHub Check: PSScriptAnalyzer
🔇 Additional comments (3)
source/Public/Set-SqlDscAgentAlert.ps1 (2)
37-53: LGTM! Comment-based help sections updated correctly.The
.INPUTSand.OUTPUTSsections follow the DSC Community guidelines precisely:
- Type names are properly formatted with backticks
- Descriptions are clear and concise
- Keywords are correctly repeated for each type
- Content matches the
[OutputType()]attribute and actual return behavior- The
None.output case is documented correctly with a periodBased on learnings, this implementation correctly documents each distinct type that can be returned with descriptions of when each type is returned.
43-43: Inconsistency in AI-generated summary.The AI summary incorrectly references
Microsoft.SqlServer.Management.Smo.Audit, but the actual code correctly documentsMicrosoft.SqlServer.Management.Smo.Agent.Alert. The code implementation is accurate.source/Public/Get-SqlDscServerProtocol.ps1 (1)
64-74: LGTM! Comment-based help formatting correctly updated.The
.INPUTSand.OUTPUTSsections now follow the standardized format:
- Type names are wrapped in backticks as inline code
- The
.INPUTSkeyword is correctly repeated for each pipeline-accepting parameter type- Both input types match the parameters that accept
ValueFromPipeline(lines 103, 107)- The output type matches the
[OutputType()]attribute (line 82)
Pull Request (PR) description
None..[OutputType()]and actual returns. If there are no outputs, specifyNone..This Pull Request (PR) fixes the following issues
OUTPUTSshould have correct format #2103Task list
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
This change is