Skip to content

Updated comment-based help .INPUTS and .OUTPUTS sections#2358

Merged
johlju merged 68 commits intodsccommunity:mainfrom
johlju:fix/issue-#2103
Dec 4, 2025
Merged

Updated comment-based help .INPUTS and .OUTPUTS sections#2358
johlju merged 68 commits intodsccommunity:mainfrom
johlju:fix/issue-#2103

Conversation

@johlju
Copy link
Member

@johlju johlju commented Dec 3, 2025

Pull Request (PR) description

  • INPUTS: List each pipeline‑accepted type as inline code with a 1‑line description. Repeat keyword for each input type. If there are no inputs, specify None..
  • OUTPUTS: List each return type as inline code with a 1‑line description. Repeat keyword for each output type. Must match both [OutputType()] and actual returns. If there are no outputs, specify None..

This Pull Request (PR) fixes the following issues

Task list

  • Added an entry to the change log under the Unreleased section of the
    file CHANGELOG.md. Entry should say what was changed and how that
    affects users (if applicable), and reference the issue being resolved
    (if applicable).
  • Resource documentation updated in the resource's README.md.
  • Resource parameter descriptions updated in schema.mof.
  • Comment-based help updated, including parameter descriptions.
  • Localization strings updated.
  • Examples updated.
  • Unit tests updated. See DSC Community Testing Guidelines.
  • Integration tests updated (where possible). See DSC Community Testing Guidelines.
  • Code changes adheres to DSC Community Style Guidelines.

This change is Reviewable

@johlju johlju requested a review from a team as a code owner December 3, 2025 20:16
@coderabbitai
Copy link

coderabbitai bot commented Dec 3, 2025

Walkthrough

Standardized 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 [OutputType()] / suppress-message attributes. No functional or control-flow changes.

Changes

Cohort / File(s) Summary
Style guidelines & changelog
\.github/instructions/dsc-community-style-guidelines-powershell.instructions.md, CHANGELOG.md
Updated guidance and changelog to require backticked inline types and punctuation normalization for .INPUTS / .OUTPUTS.
Private helpers — docs & metadata
source/Private/*
source/Private/Assert-Feature.ps1, .../Assert-ManagedServiceType.ps1, .../Assert-SetupActionProperties.ps1, .../ConvertFrom-ManagedServiceType.ps1, .../ConvertTo-ManagedServiceType.ps1, .../ConvertTo-RedactedText.ps1, .../Get-AgentAlertObject.ps1, .../Get-AgentOperatorObject.ps1, .../Get-CommandParameter.ps1, .../Get-FileVersionInformation.ps1, .../Get-SMOModuleCalculatedVersion.ps1, .../Invoke-ReportServerSetupAction.ps1, .../Invoke-SetupAction.ps1
Added or standardized .INPUTS / .OUTPUTS help blocks, wrapped types in backticks, inserted explicit "None." where appropriate, and added a few [OutputType()] attributes. No code/behavior changes.
Public commands — INPUTS added / reordered (pipeline docs)
source/Public/...
examples: source/Public/Add-SqlDscNode.ps1, .../Add-SqlDscTraceFlag.ps1, .../Assert-SqlDscLogin.ps1, .../Connect-SqlDscDatabaseEngine.ps1, .../Disconnect-SqlDscDatabaseEngine.ps1, .../Get-SqlDsc*.ps1, .../New-SqlDsc*.ps1, .../Remove-SqlDsc*.ps1, .../Set-SqlDsc*.ps1, .../Install-SqlDsc*.ps1, .../Repair-SqlDsc*.ps1
Inserted or reordered .INPUTS to document pipeline-accepted objects (Server, Login, Service, ManagedComputer, etc.), normalized .OUTPUTS formatting with backticks, and clarified some PassThru/exit-code wording. No behavioral signature changes except attribute additions noted separately.
Public commands — OUTPUTS formatting only
source/Public/*
examples: .../Add-SqlDscFileGroup.ps1, .../Get-SqlDscAgentAlert.ps1, .../Get-SqlDscAgentOperator.ps1, .../Get-SqlDscSetupLog.ps1, .../Get-SqlDscStartupParameter.ps1, .../Test-SqlDsc*.ps1
Normalized .OUTPUTS formatting: wrapped type names in backticks, adjusted phrasing/punctuation, and added brief return descriptions in many help blocks. No code changes.
Public commands — OUTPUTTYPE / attributes & clarifications
source/Public/ConvertTo-ManagedServiceType.ps1, .../ConvertTo-RedactedText.ps1, .../Connect-SqlDscDatabaseEngine.ps1, .../Import-SqlDscPreferredModule.ps1, .../Install-SqlDscReportingService.ps1, .../Repair-SqlDscReportingService.ps1, .../Install-SqlDscBIReportServer.ps1, .../Save-SqlDscSqlServerMediaFile.ps1, .../Get-SqlDscRSSetupConfiguration.ps1
Added or adjusted [OutputType()] attributes and a few SuppressMessage attributes; rewrote/clarified OUTPUTS blocks for PassThru/exit-code semantics and collection/property descriptions. Reviewers should confirm attributes match actual outputs.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Files needing extra attention:
    • Those with newly added/changed attributes: ConvertTo-ManagedServiceType.ps1, ConvertTo-RedactedText.ps1, Connect-SqlDscDatabaseEngine.ps1, Import-SqlDscPreferredModule.ps1, Repair-SqlDscReportingService.ps1.
    • Scripts where OUTPUTS were clarified for PassThru/exit-code behavior: Install/Repair/Uninstall BI/Reporting scripts.
    • Representative public cmdlets that now document pipeline acceptance — verify parameters have ValueFromPipeline/ValueFromPipelineByPropertyName bindings.

Possibly related PRs

Pre-merge checks

✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: updating comment-based help .INPUTS and .OUTPUTS sections across the codebase.
Description check ✅ Passed The description clearly relates to the changeset, explaining the updated formatting rules for .INPUTS and .OUTPUTS sections and referencing issue #2103.
Linked Issues check ✅ Passed The PR successfully implements the requirements from issue #2103: .INPUTS and .OUTPUTS are formatted as inline code with descriptions, with explicit None entries when applicable, matching [OutputType()] attributes.
Out of Scope Changes check ✅ Passed All changes are scoped to updating comment-based help documentation for .INPUTS and .OUTPUTS sections and adding corresponding [OutputType()] attributes as required by the style guidelines.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 075b09c and 45b96cb.

📒 Files selected for processing (1)
  • source/Public/Get-SqlDscTraceFlag.ps1 (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • source/Public/Get-SqlDscTraceFlag.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

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 .OUTPUTS section documenting System.String as the return type, but lacks the corresponding [OutputType([System.String])] attribute. Per guidelines, .OUTPUTS must match both the [OutputType()] attribute and actual returns.

Apply this diff:

 function ConvertTo-RedactedText
 {
     [CmdletBinding()]
+    [OutputType([System.String])]
     param
source/Private/ConvertTo-ManagedServiceType.ps1 (1)

28-37: Add missing [OutputType()] attribute to match documented return type.

The function's .OUTPUTS section documents a return type of Microsoft.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])]
     param

Based on learnings, the .OUTPUTS section 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 .OUTPUTS section. Since the function outputs None, 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()]
     param
source/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 .OUTPUTS section), it should include [OutputType()] to align with DSC Community guidelines.

Apply this diff to add the missing attribute:

 function Import-SqlDscPreferredModule
 {
     [CmdletBinding()]
+    [OutputType()]
     param
source/Public/Disconnect-SqlDscDatabaseEngine.ps1 (1)

36-36: Critical: [OutputType()] attribute doesn't match actual function behavior.

The attribute declares System.Data.DataSet as 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 .INPUTS types.

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 .OUTPUTS section 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 .INPUTS section 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 .OUTPUTS section 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 .OUTPUTS section violates the formatting requirements in two ways:

  1. Format violation: Description should be inline code (backticks) followed by a one-line description, not narrative prose spanning multiple lines.
  2. Incomplete coverage: The function has conditional output behavior—it returns System.Int32 when PassThru is specified, and returns $null (no output) otherwise. Per the learnings and PR objectives, each distinct return type must have its own .OUTPUTS entry 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 .OUTPUTS entry.

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.Operator and Microsoft.SqlServer.Management.Smo.Agent.Operator[]. Per the coding guidelines, OUTPUTS must match both [OutputType()] and actual returns. A function that returns $null in the ByName case still returns the Operator type (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 .OUTPUTS keywords and 1-line descriptions per the style guidelines.

source/Public/Get-SqlDscManagedComputerService.ps1-54-55 (1)

54-55: Add description to .OUTPUTS section.

The .OUTPUTS block 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 .OUTPUTS block 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 .INPUTS section 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 .INPUTS keyword 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.
+
 .OUTPUTS
source/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:

  1. Line 48: The .OUTPUTS keyword is not properly indented. It should have 4 spaces of indentation to align with .INPUTS on line 43.

  2. Lines 43-46: The .INPUTS section only documents the Microsoft.SqlServer.Management.Smo.Login type, but the function also accepts Microsoft.SqlServer.Management.Smo.ServerRole via pipeline (lines 96-99). Per guidelines, each pipeline-accepted type must have its own .INPUTS entry with the keyword repeated.

  3. 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 .OUTPUTS section 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 .OUTPUTS with inline code for each return type.

Same issues as noted in Uninstall-SqlDscReportingService.ps1: Line 36 has incorrect indentation for the .OUTPUTS keyword, and the section is missing inline code formatting for type names. The function conditionally returns System.Int32 or nothing, so both should be documented as separate .OUTPUTS entries 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 .OUTPUTS with inline code for each return type.

Line 37 has incorrect indentation (.OUTPUTS should be indented 4 spaces), and the .OUTPUTS section is missing inline code formatting for type names. Per the PR objectives and coding guidelines, each distinct return type should have its own .OUTPUTS keyword 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 either System.Int32 (when PassThru is present) or nothing (when PassThru is 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 .NOTES section 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 be System.String not PSModuleInfo.

The function returns [System.String] (the preferred module name or path), but the OUTPUTS section claims PSModuleInfo. 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 .OUTPUTS entry for $null or combining the description to note when $null is returned (e.g., "Returns the module name/path as a string, or $null if not found").

Remove the empty .NOTES section (lines 53-55).

source/Public/Install-SqlDscReportingService.ps1-59-66 (1)

59-66: Fix .OUTPUTS indentation and format return type explicitly

The new .INPUTS block looks good, but:

  • .OUTPUTS is 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 .OUTPUTS keyword should be indented with 4 spaces to match the .INPUTS keyword 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 .OUTPUTS keyword should be indented with 4 spaces to match the .INPUTS keyword 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:

  1. The .OUTPUTS keyword should be indented with 4 spaces (same as .INPUTS)
  2. 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 .OUTPUTS keyword should be indented with 4 spaces to match the .INPUTS keyword 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 .OUTPUTS help with style guidelines (indentation + description).

The new .INPUTS block looks correct and matches the pipeline type, but the .OUTPUTS section 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 .INPUTS as-is, makes .OUTPUTS indentation 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 EditionName and FriendlyEditionName properties, but the actual implementation (lines 48-52) returns an object with EditionId, Edition, and EditionName properties. 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 .INPUTS section only documents the server type. Per the style guidelines and the PR objective, each pipeline-accepted type should have its own .INPUTS entry with a short description. As per coding guidelines and retrieved learnings, each distinct input type must be listed separately with repeated .INPUTS keywords.

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 .OUTPUTS is just indentation to match the documented 4‑space keyword indent; if you also want to align with the “inline code” convention for None. 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 .OUTPUTS keyword 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 .OUTPUTS keyword.

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 .OUTPUTS keyword.

The .OUTPUTS keyword 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
+
+    .OUTPUTS
source/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, .OUTPUTS should 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 .OUTPUTS indentation and add missing description.

The .OUTPUTS section has two issues:

  1. Line 41: The .OUTPUTS keyword is missing the required 4-space indentation (should align with .INPUTS on line 36).
  2. 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-CommandParameter does not take pipeline input, so documenting None is correct, but the module-wide guideline is to use None. (with a trailing period) for this case, while .OUTPUTS already 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 .OUTPUTS indentation

This command accepts two distinct pipeline types:

  • Microsoft.SqlServer.Management.Smo.Server via ServerObject
  • Microsoft.SqlServer.Management.Smo.Audit via AuditObject

but the .INPUTS section only lists the server type, and .OUTPUTS is 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.
+
+    .OUTPUTS

This 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 .INPUTS entry.

source/Public/Grant-SqlDscServerPermission.ps1-29-34 (1)

29-34: Missing .INPUTS entry for ServerRole parameter.

The function has two parameters that accept pipeline input ($Login and $ServerRole), but only the Login type is documented in the .INPUTS section. According to the coding guidelines, each pipeline-accepted type must have its own .INPUTS entry with the keyword repeated.

Apply this diff to add the missing .INPUTS entry:

     .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 .OUTPUTS section.

The .OUTPUTS section 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 .INPUTS entry for ServerRole parameter.

The function has two parameters that accept pipeline input ($Login and $ServerRole), but only the Login type is documented in the .INPUTS section. According to the coding guidelines, each pipeline-accepted type must have its own .INPUTS entry with the keyword repeated.

Apply this diff to add the missing .INPUTS entry:

     .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 .OUTPUTS indentation and consider clearer descriptions

  • Line 26: .OUTPUTS is not indented with 4 spaces like the other comment-based help keywords in this block. It should follow the standard:
-.OUTPUTS
+    .OUTPUTS

This 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 Feature parameter value via the pipeline.”
    • Line 29: You could describe the boolean semantics, e.g. “Returns $true if 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 .OUTPUTS keyword to match comment-based help style

.OUTPUTS is 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 .OUTPUTS with the same indentation:

-.OUTPUTS
+    .OUTPUTS

This keeps the help block consistent and compliant with the documented formatting rules.

source/Public/Install-SqlDscServer.ps1 (1)

354-359: Align .INPUTS/.OUTPUTS block 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 .INPUTS and .OUTPUTS.
  • .OUTPUTS should 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/.OUTPUTS formatting 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 .OUTPUTS formatting.

As per coding guidelines, .OUTPUTS entries 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/.OUTPUTS help to fully match style guidelines

The new .INPUTS block is semantically correct (this command doesn’t take pipeline input), but the .OUTPUTS section 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 .INPUTS accurate, indents .OUTPUTS like 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 $true if 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 $true if the login is enabled, $false if disabled."

source/Public/Set-SqlDscStartupParameter.ps1 (1)

36-47: Examples reference Set-SqlDscTraceFlag instead of this command

The second and third .EXAMPLE blocks call Set-SqlDscTraceFlag while this help block documents Set-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 use Set-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

  • .INPUTS correctly documents that the command does not accept pipeline input.
  • .OUTPUTS now advertises Microsoft.SqlServer.Management.Smo.Server with a clear one-line description, which matches the expected server object returned by Connect-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

.INPUTS correctly documents the pipeline server type, but .OUTPUTS is 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 .OUTPUTS aligned 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.
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Type mismatch: Line 45 documents PSCustomObject but line 67 declares [OutputType([PSCustomObject[]])] and line 213 returns an array. The documentation should reflect that it returns an array.

  2. 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 .OUTPUTS help documents both None. and Microsoft.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 .OUTPUTS

The .INPUTS section correctly uses None. for a command with no pipeline input, and .OUTPUTS now documents the correct return type as inline code matching both [OutputType()] and the actual return. 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 .OUTPUTS entries.

Per the coding guidelines and PR objectives, each return type should have its own .OUTPUTS keyword 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

📥 Commits

Reviewing files that changed from the base of the PR and between 9541519 and da88e98.

📒 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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/Public/Resume-SqlDscDatabase.ps1

⚙️ CodeRabbit configuration file

source/**/*.ps1: # Localization Guidelines

Requirements

  • Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
  • Use localized string keys, not hardcoded strings
  • Assume $script:localizedData is available

String Files

  • Commands/functions: source/en-US/{MyModuleName}.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming Patterns

  • Format: Verb_FunctionName_Action (underscore separators), e.g. Get_Database_ConnectingToDatabase

String 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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/Public/Resume-SqlDscDatabase.ps1
**

⚙️ CodeRabbit configuration file

**: # DSC Community Guidelines

Terminology

  • 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 pwsh session): ./build.ps1 -Tasks noop
  • Build project before running tests: ./build.ps1 -Tasks build
  • Always run tests in new pwsh session: Invoke-Pester -Path @({test paths}) -Output Detailed

File 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.ps1

Requirements

  • 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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/Public/Resume-SqlDscDatabase.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}

⚙️ CodeRabbit configuration file

{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell Guidelines

Naming

  • 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.ps1 format (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 array

Hashtables

  • 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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Test-SqlDscAgentAlertProperty.ps1
  • source/Public/Remove-SqlDscAgentAlert.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Suspend-SqlDscDatabase.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Set-SqlDscDatabaseDefault.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Set-SqlDscAgentOperator.ps1
  • source/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.ps1
  • source/Public/New-SqlDscAgentOperator.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/Set-SqlDscDatabaseOwner.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscDatabaseProperty.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/New-SqlDscRole.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/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.ps1
  • source/Public/Repair-SqlDscBIReportServer.ps1
  • source/Public/Repair-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscRSInstalled.ps1
  • source/Public/ConvertTo-SqlDscFileGroup.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscRSSetupConfiguration.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/New-SqlDscLogin.ps1
  • source/Public/ConvertTo-SqlDscDataFile.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/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.ps1
  • source/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 .INPUTS and .OUTPUTS sections now follow the required format:

  • .INPUTS correctly specifies None. since no parameters accept pipeline input
  • .OUTPUTS type is properly wrapped in backticks as inline code and matches the [OutputType()] declaration and actual return value
source/Public/Set-SqlDscAgentOperator.ps1 (1)

53-64: LGTM! Documentation formatting correctly updated.

The .INPUTS and .OUTPUTS sections now follow the required format:

  • Each pipeline-accepted type is formatted as inline code (backticks)
  • The .INPUTS keyword is repeated for each input type
  • Types match the parameter definitions (ServerObject and OperatorObject with ValueFromPipeline = $true)
  • .OUTPUTS correctly specifies None., consistent with the empty [OutputType()] attribute on line 88
source/Public/New-SqlDscLogin.ps1 (2)

153-157: .OUTPUTS section correctly documents conditional login return type

The .OUTPUTS entry now cleanly matches [OutputType([Microsoft.SqlServer.Management.Smo.Login])] and the actual behavior of only returning a Microsoft.SqlServer.Management.Smo.Login instance when PassThru is 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 type

The .INPUTS entry correctly documents Microsoft.SqlServer.Management.Smo.Server as the pipeline-accepted type, and the description clearly states that the cmdlet accepts a SMO Server object from the pipeline (matching the ServerObject parameter’s type and ValueFromPipeline usage). Indentation and inline-code formatting are consistent with the guidelines.

source/Public/Enable-SqlDscAgentOperator.ps1 (1)

40-51: LGTM! Documentation formatting correctly updated.

The .INPUTS and .OUTPUTS sections now follow the required DSC Community style guidelines:

  • Each pipeline-accepted type is formatted as inline code with backticks
  • The .INPUTS keyword is correctly repeated for each input type
  • The .OUTPUTS section correctly specifies None. matching the [OutputType()] attribute on line 56
source/Public/New-SqlDscAgentOperator.ps1 (1)

60-68: LGTM! Documentation formatting correctly updated.

The .INPUTS and .OUTPUTS sections 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 .OUTPUTS description accurately documents the conditional return behavior (lines 266-268 confirm the operator is only returned when PassThru is present)
  • The documented output type matches the [OutputType()] attribute on line 98
source/Public/Suspend-SqlDscDatabase.ps1 (1)

63-81: INPUTS/OUTPUTS help now correctly formatted and aligned with behavior

The .INPUTS and .OUTPUTS sections 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 behavior

Both .INPUTS entries now list the exact pipeline-accepted types with one-line descriptions, and the .OUTPUTS section (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 .INPUTS keyword for each type, and follows the correct indentation pattern. The types accurately match the ServerObject and AlertObject parameters with ValueFromPipeline = $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 .INPUTS section 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 formatting

Both .INPUTS entries now use backticked fully-qualified SMO types matching the pipeline-accepted parameters (ServerObject and DatabaseObject), with clear one-line descriptions and repeated .INPUTS per type. As per coding guidelines, this is the expected pattern.


70-79: .OUTPUTS section now aligned with OutputType attributes and behavior

The first .OUTPUTS entry (None.) documents the default no-output case, and the second entry uses a backticked Microsoft.SqlServer.Management.Smo.Database type 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

.INPUTS explicitly states there is no pipeline input, and .OUTPUTS documents System.Int32 with 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 .INPUTS section 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 and None.

The .OUTPUTS section lists both the Alert return type (when PassThru is specified) and None. (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 .INPUTS and .OUTPUTS sections 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 .INPUTS and .OUTPUTS documentation 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 .OUTPUTS sections 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 .INPUTS and .OUTPUTS documentation.

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

johlju added 18 commits December 3, 2025 21:51
johlju added 14 commits December 3, 2025 22:16
…on to improve readability and detail of returned objects
…n to specify return values based on alert properties.
…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.
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 type

The new .INPUTS entries accurately reflect the two pipeline-accepted types and follow the backtick/indentation pattern, and .OUTPUTS now matches [OutputType([Microsoft.SqlServer.Management.Smo.Audit])] and the actual PassThru behavior.

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 .OUTPUTS block for None. 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

📥 Commits

Reviewing files that changed from the base of the PR and between da88e98 and b23b503.

📒 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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/Public/New-SqlDscRole.ps1

⚙️ CodeRabbit configuration file

source/**/*.ps1: # Localization Guidelines

Requirements

  • Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
  • Use localized string keys, not hardcoded strings
  • Assume $script:localizedData is available

String Files

  • Commands/functions: source/en-US/{MyModuleName}.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming Patterns

  • Format: Verb_FunctionName_Action (underscore separators), e.g. Get_Database_ConnectingToDatabase

String 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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/Public/New-SqlDscRole.ps1
**

⚙️ CodeRabbit configuration file

**: # DSC Community Guidelines

Terminology

  • 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 pwsh session): ./build.ps1 -Tasks noop
  • Build project before running tests: ./build.ps1 -Tasks build
  • Always run tests in new pwsh session: Invoke-Pester -Path @({test paths}) -Output Detailed

File 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.ps1

Requirements

  • 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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/Public/New-SqlDscRole.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}

⚙️ CodeRabbit configuration file

{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell Guidelines

Naming

  • 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.ps1 format (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 array

Hashtables

  • 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.ps1
  • source/Public/Test-SqlDscIsLogin.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Test-SqlDscIsLoginEnabled.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/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.ps1
  • source/Public/Remove-SqlDscAudit.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Public/Grant-SqlDscServerPermission.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Revoke-SqlDscServerPermission.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Remove-SqlDscRole.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscRole.ps1
  • source/Public/New-SqlDscAgentAlert.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/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.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/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.ps1
  • source/Public/Disconnect-SqlDscDatabaseEngine.ps1
  • 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 **/resources/**/*.ps1 : Add `InstanceName`, `ServerName`, and `Credential` to `$this.ExcludeDscProperties` in Database Engine resources

Applied to files:

  • source/Public/Get-SqlDscRole.ps1
  • source/Public/Connect-SqlDscDatabaseEngine.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/Assert-SqlDscLogin.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/Private/ConvertTo-RedactedText.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscDatabase.ps1
  • source/Public/Install-SqlDscReportingService.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/Public/Test-SqlDscIsRole.ps1
  • source/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.ps1
  • 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} : `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.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscManagedComputer.ps1
  • source/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.ps1
  • source/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 .INPUTS sections 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 .INPUTS keyword 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 correct

The new .INPUTS and .OUTPUTS entries 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 ($redactedText is always a System.String) and is consistent with the .OUTPUTS help entry.

source/Public/Remove-SqlDscAudit.ps1 (1)

40-51: LGTM! Documentation properly formatted.

The .INPUTS and .OUTPUTS sections are correctly formatted according to the DSC Community style guidelines:

  • Both pipeline-accepted types (Microsoft.SqlServer.Management.Smo.Server and Microsoft.SqlServer.Management.Smo.Audit) are documented with the .INPUTS keyword repeated for each type.
  • Types are formatted as inline code with backticks.
  • Each input has a clear one-line description.
  • The .OUTPUTS section correctly specifies None. 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 .INPUTS keyword
  • 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 ValueFromPipeline parameters in the function

Based on learnings and coding guidelines.

source/Public/Get-SqlDscManagedComputer.ps1 (1)

22-28: Comment-based help for .INPUTS/.OUTPUTS now matches style and behavior

.INPUTS correctly documents that there is no pipeline input (None.), and .OUTPUTS now lists the concrete return type with a clear one-line description that matches both [OutputType([Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer])] and the actual return value. 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 .INPUTS section properly documents the pipeline-accepted type with inline code formatting (backticks) and a concise description, matching both the style guidelines and the $ServerObject parameter's ValueFromPipeline = $true attribute.


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 .OUTPUTS section that specifies "None."

source/Public/Test-SqlDscIsLogin.ps1 (1)

14-22: LGTM! Comment-based help sections correctly formatted.

The .INPUTS and .OUTPUTS sections correctly follow the DSC Community style guidelines:

  • Input type Microsoft.SqlServer.Management.Smo.Server matches the pipeline-accepted parameter
  • Output type System.Boolean matches 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 .INPUTS and .OUTPUTS sections correctly follow the DSC Community style guidelines:

  • Two input types properly documented with repeated .INPUTS keyword:
    • Microsoft.SqlServer.Management.Smo.Server matches the ServerObject pipeline parameter
    • Microsoft.SqlServer.Management.Smo.Login matches the LoginObject pipeline parameter
  • Output type System.Boolean matches 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 .INPUTS keyword 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 guidelines

The .INPUTS entry correctly documents the Microsoft.SqlServer.Management.Smo.Server pipeline input, and the .OUTPUTS entry now matches both [OutputType([Microsoft.SqlServer.Management.Smo.Database[]])] and the final return [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 consistent

The .INPUTS entry correctly documents the pipeline type Microsoft.SqlServer.Management.Smo.Server with a one‑line description, and .OUTPUTS is set to None. 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 -Full to 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 output

Using an empty [OutputType()] here is appropriate for a command that only asserts and throws on failure without emitting objects, and it matches the .OUTPUTS help of None. so tooling and documentation stay in sync.

If needed, you can verify with Get-Command Assert-SqlDscLogin | Select-Object -ExpandProperty OutputType to 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.

.INPUTS documents the pipeline-accepted Microsoft.SqlServer.Management.Smo.Server correctly, and .OUTPUTS documents System.Boolean matching 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

.INPUTS documents the Microsoft.SqlServer.Management.Smo.Server pipeline input for ServerObject, and .OUTPUTS correctly documents Microsoft.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 behavior

The .INPUTS entry correctly documents Microsoft.SqlServer.Management.Smo.Server as the pipeline input for ServerObject, and .OUTPUTS now lists Microsoft.SqlServer.Management.Smo.ServerRole with 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 implementation

The updated .INPUTS and .OUTPUTS sections look good: the Server input and Alert output are correctly backticked, the Alert output matches [OutputType()] and the PassThru-based return, and the separate None. 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 types

The two .INPUTS entries now list Microsoft.SqlServer.Management.Smo.Login and Microsoft.SqlServer.Management.Smo.ServerRole with 1‑line descriptions, matching the Login and ServerRole parameters 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

.INPUTS is explicitly None., and .OUTPUTS now documents both the default no‑output case (None. with explanation) and the System.Int32 exit code when -PassThru is used. The added empty [OutputType()] alongside [OutputType([System.Int32])] matches these two cases and the implementation (return $exitCode only when $PassThru.IsPresent). This is consistent with the established pattern for functions with optional PassThru outputs.

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 type

The .INPUTS section correctly declares None., and .OUTPUTS now documents the Microsoft.SqlServer.Management.Smo.Server return 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 from Connect-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
Copy link

codecov bot commented Dec 3, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94%. Comparing base (79c0cc0) to head (bd2f01e).

Additional details and impacted files

Impacted file tree graph

@@         Coverage Diff          @@
##           main   #2358   +/-   ##
====================================
  Coverage    94%     94%           
====================================
  Files       166     166           
  Lines      9765    9765           
====================================
  Hits       9206    9206           
  Misses      559     559           
Flag Coverage Δ
unit 94% <ø> (ø)
Files with missing lines Coverage Δ
source/Private/Assert-Feature.ps1 100% <ø> (ø)
source/Private/Assert-ManagedServiceType.ps1 100% <ø> (ø)
source/Private/Assert-SetupActionProperties.ps1 98% <ø> (ø)
source/Private/ConvertFrom-ManagedServiceType.ps1 62% <ø> (ø)
source/Private/ConvertTo-AuditNewParameterSet.ps1 93% <ø> (ø)
...rivate/ConvertTo-FormattedParameterDescription.ps1 100% <ø> (ø)
source/Private/ConvertTo-ManagedServiceType.ps1 100% <ø> (ø)
source/Private/ConvertTo-RedactedText.ps1 100% <ø> (ø)
source/Private/Get-AgentAlertObject.ps1 100% <ø> (ø)
source/Private/Get-AgentOperatorObject.ps1 100% <ø> (ø)
... and 109 more
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ServerObject parameter's ValueFromPipeline attribute, 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

📥 Commits

Reviewing files that changed from the base of the PR and between 7cc6c98 and bd2f01e.

📒 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.ps1
  • source/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.ps1
  • source/Public/Set-SqlDscDatabasePermission.ps1

⚙️ CodeRabbit configuration file

source/**/*.ps1: # Localization Guidelines

Requirements

  • Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
  • Use localized string keys, not hardcoded strings
  • Assume $script:localizedData is available

String Files

  • Commands/functions: source/en-US/{MyModuleName}.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming Patterns

  • Format: Verb_FunctionName_Action (underscore separators), e.g. Get_Database_ConnectingToDatabase

String 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.ps1
  • source/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.ps1
  • source/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.ps1
  • source/Public/Set-SqlDscDatabasePermission.ps1
**

⚙️ CodeRabbit configuration file

**: # DSC Community Guidelines

Terminology

  • 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 pwsh session): ./build.ps1 -Tasks noop
  • Build project before running tests: ./build.ps1 -Tasks build
  • Always run tests in new pwsh session: Invoke-Pester -Path @({test paths}) -Output Detailed

File 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.ps1

Requirements

  • 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.ps1
  • source/Public/Set-SqlDscDatabasePermission.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}

⚙️ CodeRabbit configuration file

{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell Guidelines

Naming

  • 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.ps1 format (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 array

Hashtables

  • 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.ps1
  • source/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.ps1
  • source/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 implementation

The updated comment-based help looks good:

  • .INPUTS correctly documents a single System.String value accepted from the pipeline for -Feature.
  • .OUTPUTS now uses inline-code System.Boolean and the type matches both [OutputType([System.Boolean])] and the actual $true/$false return from $supported.

No further changes needed here.

As per coding guidelines, this satisfies the INPUTS/OUTPUTS documentation requirements.

Copy link
Member Author

@johlju johlju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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: :shipit: complete! all files reviewed, all discussions resolved (waiting on @johlju)

Copy link
Member Author

@johlju johlju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

@johlju reviewed 4 of 4 files at r4, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @johlju)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
source/Public/Get-SqlDscTraceFlag.ps1 (1)

43-47: Align .INPUTS/.OUTPUTS with 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

📥 Commits

Reviewing files that changed from the base of the PR and between bd2f01e and 075b09c.

📒 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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1

⚙️ CodeRabbit configuration file

source/**/*.ps1: # Localization Guidelines

Requirements

  • Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
  • Use localized string keys, not hardcoded strings
  • Assume $script:localizedData is available

String Files

  • Commands/functions: source/en-US/{MyModuleName}.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming Patterns

  • Format: Verb_FunctionName_Action (underscore separators), e.g. Get_Database_ConnectingToDatabase

String 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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
**

⚙️ CodeRabbit configuration file

**: # DSC Community Guidelines

Terminology

  • 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 pwsh session): ./build.ps1 -Tasks noop
  • Build project before running tests: ./build.ps1 -Tasks build
  • Always run tests in new pwsh session: Invoke-Pester -Path @({test paths}) -Output Detailed

File 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.ps1

Requirements

  • 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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/Public/Set-SqlDscAgentAlert.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}

⚙️ CodeRabbit configuration file

{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell Guidelines

Naming

  • 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.ps1 format (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 array

Hashtables

  • 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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/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.ps1
  • source/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.ps1
  • source/Public/Get-SqlDscServerProtocol.ps1
  • source/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.ps1
  • 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} : 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 .INPUTS and .OUTPUTS sections 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 period

Based 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 documents Microsoft.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 .INPUTS and .OUTPUTS sections now follow the standardized format:

  • Type names are wrapped in backticks as inline code
  • The .INPUTS keyword 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)

@johlju johlju merged commit 78ece95 into dsccommunity:main Dec 4, 2025
4 of 8 checks passed
@johlju johlju deleted the fix/issue-#2103 branch December 4, 2025 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Commands comment-based help header OUTPUTS should have correct format

1 participant