Skip to content

New-SqlDscLogin: command to create SQL Server logins#2132

Merged
johlju merged 61 commits intodsccommunity:mainfrom
johlju:f/command-new-sqldsclogin
Aug 19, 2025
Merged

New-SqlDscLogin: command to create SQL Server logins#2132
johlju merged 61 commits intodsccommunity:mainfrom
johlju:f/command-new-sqldsclogin

Conversation

@johlju
Copy link
Copy Markdown
Member

@johlju johlju commented Aug 13, 2025

Pull Request (PR) description

  • New-SqlDscLogin
    • Added new public command to create a new login on a SQL Server Database
      Engine instance.
    • Supports creating SQL Server logins, Windows user logins, Windows group
      logins, certificate-based logins, and asymmetric key-based logins.

This Pull Request (PR) fixes the following issues

None.

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 August 13, 2025 17:30
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Aug 13, 2025

Walkthrough

Adds a new public PowerShell helper New-SqlDscLogin with unit and integration tests, localization strings, docs and CI wiring; updates Remove-SqlDscLogin integration tests to use the helper; extends SMO test stubs; replaces several New-InvalidArgumentException calls with New-ArgumentException; and updates editor/CI/guideline files plus .gitignore.

Changes

Cohort / File(s) Summary
Version control ignore
/.gitignore
Add coverage.xml to ignore list.
Public command implementation
/source/Public/New-SqlDscLogin.ps1
Add New-SqlDscLogin cmdlet implementing parameter-set driven creation of SMO logins (SqlLogin, SqlLoginHashed, WindowsUser, WindowsGroup, Certificate, AsymmetricKey) with ShouldProcess, existence check, password/options handling, -Disabled, -Force, and -PassThru.
Localization strings
/source/en-US/SqlServerDsc.strings.psd1
Add ShouldProcess caption/verbose/warning and created/already-exists messages for New-SqlDscLogin.
Unit tests and stubs
/tests/Unit/Public/New-SqlDscLogin.Tests.ps1, tests/Unit/Stubs/SMO.cs
Add comprehensive Pester unit tests for New-SqlDscLogin; extend SMO Login stub with MockCreateCalled, Disable(), Enable(), and Certificate, AsymmetricKey, Language fields.
Integration tests and docs
/tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1, .../Prerequisites.Integration.Tests.ps1, .../Remove-SqlDscLogin.Integration.Tests.ps1, tests/Integration/Commands/README.md
Add New-SqlDscLogin integration tests and README entries; create local SqlIntegrationTest user and SqlIntegrationTestGroup prerequisites; update Remove-SqlDscLogin integration tests to use New-SqlDscLogin and make tests more self-contained.
Changelog
/CHANGELOG.md
Document Unreleased entry describing New-SqlDscLogin, tests, docs, and CI/context notes.
CI pipeline
/azure-pipelines.yml, /.build/Test-ShouldRunDscResourceIntegrationTests.ps1
Make PR target branch resolution conditional on env var; normalize and lowercase resource gating outputs; add New-SqlDscLogin integration test to SQL Server Commands group; remove some debug output in the helper script.
Editor settings
.vscode/settings.json
Append cSpell words: pullrequest, targetbranch, hqrm, sqlps, securestring, encryptorname, wsfc.
VS Code tasks
.vscode/tasks.json
Expand test task args to include -PesterPath (multiple dirs) and -CodeCoverageThreshold "0", add presentation and problemMatcher entries; update hqrmtest args similarly.
Repository docs & guidelines
/.github/instructions/..., CONTRIBUTING.md
Update Markdown wrapping guideline; change recommended terminating error to New-ArgumentException; add PowerShell guideline requiring pipeline parameters in all parameter sets.
Argument-exception replacements
/source/Classes/...
Replace multiple New-InvalidArgumentException calls with New-ArgumentException across several classes (messages and argument names unchanged).

Sequence Diagram(s)

sequenceDiagram
  actor User
  participant Cmd as New-SqlDscLogin
  participant Exists as Test-SqlDscIsLogin
  participant SMO as SMO.Server/Login
  User->>Cmd: Invoke with ServerObject, Name, parameter-set...
  Cmd->>Exists: Test if login exists
  Exists-->>Cmd: Exists? (true/false)
  alt exists == true
    Cmd-->>User: Throw terminating error (login exists)
  else
    Cmd->>User: ShouldProcess prompt (WhatIf/Confirm)
    alt proceed
      Cmd->>SMO: Create login (type, defaults, options, password)
      opt -Disabled
        Cmd->>SMO: Call Disable()
      end
      opt -PassThru
        SMO-->>User: Return created Login object
      end
    else declined / WhatIf
      Cmd-->>User: No change (WhatIf/declined)
    end
  end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c068476 and f3c7fa1.

📒 Files selected for processing (1)
  • azure-pipelines.yml (8 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
⏰ 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)
azure-pipelines.yml (3)

107-113: Good: explicit debug + lowercase normalization before export

Lowercasing at the source simplifies downstream conditions and avoids case pitfalls. The extra diagnostics will help trace gating decisions.


115-115: Export looks correct (string 'true'/'false' as output)

Exporting a normalized string output aligns with Azure Pipelines expression expectations.


293-293: Integration test scaffolding verified for New-SqlDscLogin

The integration test tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 exists and includes the required BeforeDiscovery, BeforeAll, and Describe blocks as per guidelines.

✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Comment thread tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 Outdated
Copy link
Copy Markdown

@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: 9

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 14c5107 and 571fc83.

📒 Files selected for processing (10)
  • .gitignore (1 hunks)
  • .vscode/tasks.json (2 hunks)
  • CHANGELOG.md (1 hunks)
  • source/Public/New-SqlDscLogin.ps1 (1 hunks)
  • source/en-US/SqlServerDsc.strings.psd1 (1 hunks)
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/README.md (4 hunks)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
  • tests/Unit/Stubs/SMO.cs (1 hunks)
🧰 Additional context used
📓 Path-based instructions (14)
tests/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/**/*.ps1: All tests should use the Pester framework and use Pester v5.0 syntax.
Parameter validation should never be tested.
Test code should never be added outside of the Describe block.
There should only be one Pester Describe block per test file, and the name of the Describe block should be the same as the name of the public command, private function, or class-based resource being tested.
Each scenario or code path being tested should have its own Pester Context block that starts with the phrase 'When'.
Pester It block descriptions should start with the phrase 'Should'.
It blocks must always call the command or function being tested and result and outcomes should be kept in the same It block.
BeforeAll and BeforeEach blocks should never call the command or function being tested.
BeforeAll, BeforeEach, AfterAll and AfterEach blocks should be used inside the Context block as near as possible to the It block that will use the test data, test setup and teardown.
AfterAll block can be used to clean up any test data.
BeforeEach and AfterEach blocks should be used sparingly.
It is okay to duplicate code in BeforeAll and BeforeEach blocks that are used inside different Context blocks.
Use localized strings in the tests only when necessary.
Files that need to be mocked should be created in Pester's test drive using the $TestDrive variable.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
tests/Integration/Commands/*.Integration.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Integration/Commands/*.Integration.Tests.ps1: Integration tests for public commands should be placed in tests/Integration/Commands and named after the command with the suffix .Integration.Tests.ps1.
All integration tests must use the provided code block prior to the first Describe block to set up the integration test environment.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.ps1: All PowerShell files should use UTF8 without BOM.
All PowerShell files must end with a new line.
Try to limit PowerShell code lines to 120 characters.
Use 4 spaces for indentation in PowerShell files, never use tabs.
Use '#' for single line comments in PowerShell code.
Use comment-blocks for multiline comments with the format <# ... #> where the multiline text is indented 4 spaces.
Use descriptive, clear, and full names for all variables, parameters, and function names. All names must be more than 2 characters. No abbreviations should be used.
Use camelCase for local variable names in PowerShell.
Use Write-Error for error messages.
Use Write-Warning for warning messages.
Use Write-Information for informational messages.
Never use Write-Host.
Never use backtick as line continuation in code.
Use splatting for commands to reduce line length.
PowerShell reserved keywords should be in all lower case.
Single quotes should always be used to delimit string literals wherever possible. Double quoted string literals may only be used when string literals contain ($) expressions that need to be evaluated.
Hashtables properties should always be in PascalCase and be on a separate line.
When comparing a value to $null, $null should be on the left side of the comparison.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/Public/New-SqlDscLogin.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
**/*.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.md: Markdown files should wrap lines after a word when a line exceeds 80 characters.
Use 2 spaces for indentation in Markdown files.

Files:

  • tests/Integration/Commands/README.md
  • CHANGELOG.md
tests/Unit/{Classes,Public,Private}/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Unit tests should be added for all public commands, private functions and class-based resources. Unit tests for class-based resources should be placed in tests/Unit/Classes, for public commands in tests/Unit/Public, and for private functions in tests/Unit/Private. The unit tests should be named after the item being tested with the suffix .Tests.ps1.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/Public/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/Public/*.Tests.ps1: All public commands should always have a test to validate parameter sets using the provided template.
All public commands should also include tests to validate parameter properties.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/**/*.ps1: Never test, mock or use Should -Invoke for Write-Verbose and Write-Debug.
Never use Should -Not -Throw in tests; instead, call the command directly.
All unit tests should use the provided code block prior to the Describe block to set up the test environment and load the correct module.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
source/en-US/SqlServerDsc.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

For class-based resources, localized strings should be added in a separate file in source/en-US, named to exactly match the resource class name with the suffix .strings.psd1.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Localized string key names should use underscores as word separators if the key name has more than one word.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/Public/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/Public/*.ps1: Public PowerShell commands should each have their own script file named after the command (with .ps1 extension) and be placed in the folder source/Public.
All public command names must have the noun prefixed with 'SqlDsc', e.g. {Verb}-SqlDsc{Noun}.

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private,Classes}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private,Classes}/*.ps1: Comment-based help should always be before the function-statement for each public command and private function, and before the class-statement for each class-based resource. It should be in the format of a comment block and at least use the keywords: .SYNOPSIS, .DESCRIPTION, .PARAMETER, .EXAMPLE, and .NOTES.
Each comment-based help keyword should be indented with 4 spaces and each keyword's text should be indented 8 spaces.
The text for keyword .DESCRIPTION should be descriptive and must have a length greater than 40 characters. The .SYNOPSIS keyword text should be a short description.
A comment-based help must have at least one example, but preferably more examples to showcase all possible parameter sets and different parameter combinations.
Use PascalCase for function names and parameters in public commands, private functions, and class-based resources.

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private}/*.ps1: All message strings for Write-Debug, Write-Verbose, Write-Error, Write-Warning and other error messages in public commands and private functions should be localized using localized string keys.
All public command and private function names must follow the standard PowerShell Verb-Noun format.
All public command and private function names must use PowerShell approved verbs.
All public commands and private functions should always be advanced functions and have [CmdLetBinding()] attribute.
Public commands and private functions with no parameters should still have an empty parameter block param ().
Every parameter in public commands and private functions should include the [Parameter()] attribute.
A mandatory parameter in public commands and private functions should contain the decoration [Parameter(Mandatory = $true)], and non-mandatory parameters should not contain the Mandatory decoration.
Parameters attributes, datatype and its name should be on separate lines.
Parameters must be separated by a single, blank line.
Use Write-Verbose to output verbose output for actions a public command or private function does.
Use Write-Debug for debug output for processes within the script for user to see the decisions a command or private function does.

Files:

  • source/Public/New-SqlDscLogin.ps1
CHANGELOG.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

The Unreleased section in CHANGELOG.md should always be updated when making changes to the codebase, using the keepachangelog format and providing concrete release notes.

Files:

  • CHANGELOG.md
🧠 Learnings (5)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to azure-pipelines.yml : Integration test script files for public commands must be added to a group within the 'Integration_Test_Commands_SqlServer' stage in ./azure-pipelines.yml.

Applied to files:

  • tests/Integration/Commands/README.md
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests for public commands should be placed in tests/Integration/Commands and named after the command with the suffix .Integration.Tests.ps1.

Applied to files:

  • tests/Integration/Commands/README.md
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : All integration tests must use the provided code block prior to the first Describe block to set up the integration test environment.

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
🪛 LanguageTool
tests/Integration/Commands/README.md

[grammar] ~43-~43: Use correct spacing
Context: ...cLogin | 2 | 1 (Install-SqlDscServer) | DSCSQLTEST ## Integration Tests ### Prerequisites´ ...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~60-~60: Use correct spacing
Context: ...o other tests can use it for validation purposes. ## Dependencies ### SqlServer module Ther...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~121-~121: Use correct spacing
Context: ...lDscLogin integration tests for testing purposes. ### Image media (ISO) The environment varia...

(QB_NEW_EN_OTHER_ERROR_IDS_5)

⏰ 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 (27)
.gitignore (1)

4-4: LGTM: ignoring coverage.xml is appropriate

Prevents accidental commits of coverage artifacts produced by test runs.

.vscode/tasks.json (1)

44-44: LGTM: pass -Tasks build explicitly

This clarifies intent and keeps build.ps1 invocation consistent between tasks.

tests/Integration/Commands/Prerequisites.Integration.Tests.ps1 (1)

47-52: LGTM: adding SqlIntegrationTest user prerequisite

Follows existing pattern in this file and Pester v5 structure. Single quotes, indentation, and It descriptions comply with guidelines.

CHANGELOG.md (1)

26-32: LGTM: prerequisites/tests docs noted under Changed

Clear and actionable; reflects the new SqlIntegrationTest user and test ordering updates.

source/en-US/SqlServerDsc.strings.psd1 (1)

231-238: LGTM! Localization strings follow the naming convention correctly.

The new localization string keys for New-SqlDscLogin are properly prefixed with the function name (Login_Add_) using underscores as word separators, which aligns with the established pattern used by other public commands in this file.

tests/Integration/Commands/README.md (1)

112-112: LGTM! Documentation accurately describes the test setup.

The new user entry for .\SqlIntegrationTest is properly documented and aligns with its usage in the integration tests.

tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (5)

1-31: LGTM! Integration test setup follows the required template.

The test file correctly implements the required integration test setup code block before the first Describe block, including dependency resolution and module import.


32-32: LGTM! Test tags correctly target all SQL Server versions.

The Describe block properly includes all supported SQL Server version tags for integration testing.


69-110: LGTM! Comprehensive SQL Server login test coverage.

The test scenarios thoroughly cover SQL Server login creation including validation, custom database settings, and PassThru functionality with proper cleanup.


158-182: LGTM! Windows user login test with proper cleanup.

The test correctly creates a Windows user login using the prerequisite user and includes proper cleanup in the finally block.


227-235: LGTM! WhatIf functionality test validates ShouldProcess support.

The test correctly verifies that WhatIf prevents actual login creation while allowing the command to execute without errors.

tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (8)

1-52: LGTM! Unit test setup follows the required template.

The test file correctly implements the required unit test setup including dependency resolution, module loading, SMO stubs, and proper cleanup in AfterAll.


53-53: LGTM! Proper use of the 'Public' tag for public command tests.

The Describe block correctly uses the 'Public' tag as required for public command unit tests.


88-103: LGTM! Error handling test correctly validates existing login scenario.

The test properly mocks an existing login condition and verifies the appropriate error is thrown with the expected message pattern.


104-114: LGTM! PassThru parameter test validates object return.

The test correctly verifies that the PassThru parameter returns a non-null login object.


116-126: LGTM! Certificate-based login test covers the parameter set.

The test validates certificate-based login creation with the required CertificateName parameter.


128-134: LGTM! Asymmetric key-based login test covers the parameter set.

The test validates asymmetric key-based login creation with the required AsymmetricKeyName parameter.


196-206: LGTM! Comprehensive test for multiple SQL login options.

The test effectively validates that the function can handle multiple options simultaneously including password policies, disabled state, and custom settings.


208-240: LGTM! Parameter filter tests provide precise mock verification.

The additional context with parameter filters ensures that the mock assertions are specific to the exact invocation being tested, improving test precision.

source/Public/New-SqlDscLogin.ps1 (8)

1-118: LGTM! Comprehensive comment-based help with clear examples.

The comment-based help follows the required format with proper indentation, includes multiple examples covering all parameter sets, and provides clear descriptions for all parameters.


119-123: LGTM! Function declaration follows DSC community guidelines.

The function name follows the required {Verb}-SqlDsc{Noun} pattern, uses an approved PowerShell verb, and includes proper attributes for OutputType and CmdletBinding.


124-201: LGTM! Parameter declarations follow best practices.

All parameters follow the required format with proper attributes, datatypes, and names on separate lines. Mandatory parameters are correctly decorated, and parameter sets are well-organized.


213-226: LGTM! Proper error handling for existing logins.

The function correctly checks for existing logins and throws a terminating error with a localized message, proper error ID, and appropriate error category.


240-268: LGTM! Well-structured switch statement for login types.

The switch statement properly handles all login types and sets the appropriate LoginType enum values and additional properties for Certificate and AsymmetricKey logins.


280-300: LGTM! Correct implementation of SQL login options.

The SQL login creation properly handles password expiration, policy enforcement, and login creation options using bitwise operations for combining flags.


307-311: LGTM! Proper implementation of the Disabled parameter.

The function correctly calls the Disable() method on the login object after creation when the Disabled parameter is specified.


315-318: LGTM! Correct implementation of PassThru parameter.

The function properly returns the login object when PassThru is specified, following PowerShell conventions.

Comment thread .vscode/tasks.json Outdated
Comment thread CHANGELOG.md
Comment thread source/Public/New-SqlDscLogin.ps1
Comment thread tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 Outdated
Comment thread tests/Integration/Commands/README.md Outdated
Comment thread tests/Integration/Commands/README.md Outdated
Comment thread tests/Integration/Commands/README.md
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1 Outdated
Comment thread tests/Unit/Stubs/SMO.cs
@codecov
Copy link
Copy Markdown

codecov Bot commented Aug 13, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94%. Comparing base (9df1132) to head (f3c7fa1).
⚠️ Report is 63 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@         Coverage Diff          @@
##           main   #2132   +/-   ##
====================================
  Coverage    94%     94%           
====================================
  Files       109     110    +1     
  Lines      8132    8171   +39     
====================================
+ Hits       7693    7732   +39     
  Misses      439     439           
Flag Coverage Δ
unit 94% <100%> (+<1%) ⬆️
Files with missing lines Coverage Δ
source/Classes/002.DatabasePermission.ps1 100% <100%> (ø)
source/Classes/002.ServerPermission.ps1 100% <100%> (ø)
source/Classes/020.SqlAudit.ps1 100% <100%> (ø)
source/Classes/020.SqlDatabasePermission.ps1 100% <100%> (ø)
source/Classes/020.SqlPermission.ps1 100% <100%> (ø)
source/Public/New-SqlDscLogin.ps1 100% <100%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@johlju johlju added the needs review The pull request needs a code review. label Aug 14, 2025
{
{ New-SqlDscLogin -ServerObject $script:serverObject -Name $disabledLoginName -SqlLogin -SecurePassword $script:testPassword -Disabled -Confirm:$false } | Should -Not -Throw

$loginObject = $script:serverObject.Logins[$disabledLoginName]
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Add ned command Test-SqlDscIsLoginEnabled (that also uses Test-SqlDscIsLogin to verify exist).

Comment thread tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
Comment thread tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
@johlju johlju force-pushed the f/command-new-sqldsclogin branch from 571fc83 to c18db78 Compare August 16, 2025 17:26
Copy link
Copy Markdown

@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: 3

♻️ Duplicate comments (8)
.vscode/tasks.json (1)

87-87: Re-add dependency restore to the test task to prevent missing modules

Removing -AutoRestore means running tests won’t automatically bootstrap required dependencies. Add -ResolveDependency (or re-introduce -AutoRestore) so local runs don’t fail due to missing modules.

Apply:

-            "args": ["-Tasks", "test"],
+            "args": ["-ResolveDependency", "-Tasks", "test"],
tests/Unit/Stubs/SMO.cs (1)

481-484: Disable() now sets IsDisabled = true — matches expectations

This aligns the stub with expected SMO-like behavior and unblocks tests asserting disabled state after creation.

tests/Integration/Commands/README.md (3)

43-43: Fix formatting issue before "## Integration Tests" heading.

Remove the extra blank line to fix the formatting issue identified by the static analysis tool.

 New-SqlDscLogin | 2 | 1 (Install-SqlDscServer) | DSCSQLTEST
 
 ## Integration Tests

56-60: Add missing period for consistency.

Add a period at the end of the description for consistency with other sections.

 Creates test logins on the DSCSQLTEST instance for use by other integration
 tests. The main test login `IntegrationTestSqlLogin` is left in place after
-the test completes so other tests can use it for validation purposes
+the test completes so other tests can use it for validation purposes.

121-121: Add missing period to the login description.

Add a period at the end of the description for consistency with other entries.

-IntegrationTestSqlLogin | P@ssw0rd123! | - | SQL Server login created by New-SqlDscLogin integration tests for testing purposes
+IntegrationTestSqlLogin | P@ssw0rd123! | - | SQL Server login created by New-SqlDscLogin integration tests for testing purposes.
tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1)

154-154: Update the error message pattern to match the localized string more precisely.

The test should use a more specific pattern that matches the actual localized error message format.

-                { New-SqlDscLogin -ServerObject $script:serverObject -Name $script:testSqlLoginName -SqlLogin -SecurePassword $script:testPassword -Confirm:$false } | Should -Throw -ExpectedMessage "*The login '$script:testSqlLoginName' already exists on the instance '$($script:serverObject.InstanceName)'*"
+                { New-SqlDscLogin -ServerObject $script:serverObject -Name $script:testSqlLoginName -SqlLogin -SecurePassword $script:testPassword -Confirm:$false } | Should -Throw -ExpectedMessage "*The login '$script:testSqlLoginName' already exists on the instance*"
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)

69-77: Consider verifying the Create method invocation.

While the test verifies that Test-SqlDscIsLogin is called, it could be enhanced to verify that the Create method on the login object is actually invoked.

source/Public/New-SqlDscLogin.ps1 (1)

210-211: Consider using a more descriptive variable name.

The variable name could be more descriptive to clarify its purpose.

 # Determine login type from parameter set
-$loginType = $PSCmdlet.ParameterSetName
+$loginTypeParameterSet = $PSCmdlet.ParameterSetName

Also update all references to $loginType to $loginTypeParameterSet in lines 234, 240, and 280.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 571fc83 and c18db78.

📒 Files selected for processing (10)
  • .gitignore (1 hunks)
  • .vscode/tasks.json (2 hunks)
  • CHANGELOG.md (1 hunks)
  • source/Public/New-SqlDscLogin.ps1 (1 hunks)
  • source/en-US/SqlServerDsc.strings.psd1 (1 hunks)
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/README.md (4 hunks)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
  • tests/Unit/Stubs/SMO.cs (1 hunks)
🧰 Additional context used
📓 Path-based instructions (14)
tests/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/**/*.ps1: All tests should use the Pester framework and use Pester v5.0 syntax.
Parameter validation should never be tested.
Test code should never be added outside of the Describe block.
There should only be one Pester Describe block per test file, and the name of the Describe block should be the same as the name of the public command, private function, or class-based resource being tested.
Each scenario or code path being tested should have its own Pester Context block that starts with the phrase 'When'.
Pester It block descriptions should start with the phrase 'Should'.
It blocks must always call the command or function being tested and result and outcomes should be kept in the same It block.
BeforeAll and BeforeEach blocks should never call the command or function being tested.
BeforeAll, BeforeEach, AfterAll and AfterEach blocks should be used inside the Context block as near as possible to the It block that will use the test data, test setup and teardown.
AfterAll block can be used to clean up any test data.
BeforeEach and AfterEach blocks should be used sparingly.
It is okay to duplicate code in BeforeAll and BeforeEach blocks that are used inside different Context blocks.
Use localized strings in the tests only when necessary.
Files that need to be mocked should be created in Pester's test drive using the $TestDrive variable.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
tests/Integration/Commands/*.Integration.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Integration/Commands/*.Integration.Tests.ps1: Integration tests for public commands should be placed in tests/Integration/Commands and named after the command with the suffix .Integration.Tests.ps1.
All integration tests must use the provided code block prior to the first Describe block to set up the integration test environment.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.ps1: All PowerShell files should use UTF8 without BOM.
All PowerShell files must end with a new line.
Try to limit PowerShell code lines to 120 characters.
Use 4 spaces for indentation in PowerShell files, never use tabs.
Use '#' for single line comments in PowerShell code.
Use comment-blocks for multiline comments with the format <# ... #> where the multiline text is indented 4 spaces.
Use descriptive, clear, and full names for all variables, parameters, and function names. All names must be more than 2 characters. No abbreviations should be used.
Use camelCase for local variable names in PowerShell.
Use Write-Error for error messages.
Use Write-Warning for warning messages.
Use Write-Information for informational messages.
Never use Write-Host.
Never use backtick as line continuation in code.
Use splatting for commands to reduce line length.
PowerShell reserved keywords should be in all lower case.
Single quotes should always be used to delimit string literals wherever possible. Double quoted string literals may only be used when string literals contain ($) expressions that need to be evaluated.
Hashtables properties should always be in PascalCase and be on a separate line.
When comparing a value to $null, $null should be on the left side of the comparison.

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/Public/New-SqlDscLogin.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
**/*.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.md: Markdown files should wrap lines after a word when a line exceeds 80 characters.
Use 2 spaces for indentation in Markdown files.

Files:

  • tests/Integration/Commands/README.md
  • CHANGELOG.md
source/en-US/SqlServerDsc.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

For class-based resources, localized strings should be added in a separate file in source/en-US, named to exactly match the resource class name with the suffix .strings.psd1.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Localized string key names should use underscores as word separators if the key name has more than one word.

Files:

  • source/en-US/SqlServerDsc.strings.psd1
CHANGELOG.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

The Unreleased section in CHANGELOG.md should always be updated when making changes to the codebase, using the keepachangelog format and providing concrete release notes.

Files:

  • CHANGELOG.md
tests/Unit/{Classes,Public,Private}/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Unit tests should be added for all public commands, private functions and class-based resources. Unit tests for class-based resources should be placed in tests/Unit/Classes, for public commands in tests/Unit/Public, and for private functions in tests/Unit/Private. The unit tests should be named after the item being tested with the suffix .Tests.ps1.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/Public/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/Public/*.Tests.ps1: All public commands should always have a test to validate parameter sets using the provided template.
All public commands should also include tests to validate parameter properties.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/**/*.ps1: Never test, mock or use Should -Invoke for Write-Verbose and Write-Debug.
Never use Should -Not -Throw in tests; instead, call the command directly.
All unit tests should use the provided code block prior to the Describe block to set up the test environment and load the correct module.

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
source/Public/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/Public/*.ps1: Public PowerShell commands should each have their own script file named after the command (with .ps1 extension) and be placed in the folder source/Public.
All public command names must have the noun prefixed with 'SqlDsc', e.g. {Verb}-SqlDsc{Noun}.

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private,Classes}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private,Classes}/*.ps1: Comment-based help should always be before the function-statement for each public command and private function, and before the class-statement for each class-based resource. It should be in the format of a comment block and at least use the keywords: .SYNOPSIS, .DESCRIPTION, .PARAMETER, .EXAMPLE, and .NOTES.
Each comment-based help keyword should be indented with 4 spaces and each keyword's text should be indented 8 spaces.
The text for keyword .DESCRIPTION should be descriptive and must have a length greater than 40 characters. The .SYNOPSIS keyword text should be a short description.
A comment-based help must have at least one example, but preferably more examples to showcase all possible parameter sets and different parameter combinations.
Use PascalCase for function names and parameters in public commands, private functions, and class-based resources.

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private}/*.ps1: All message strings for Write-Debug, Write-Verbose, Write-Error, Write-Warning and other error messages in public commands and private functions should be localized using localized string keys.
All public command and private function names must follow the standard PowerShell Verb-Noun format.
All public command and private function names must use PowerShell approved verbs.
All public commands and private functions should always be advanced functions and have [CmdLetBinding()] attribute.
Public commands and private functions with no parameters should still have an empty parameter block param ().
Every parameter in public commands and private functions should include the [Parameter()] attribute.
A mandatory parameter in public commands and private functions should contain the decoration [Parameter(Mandatory = $true)], and non-mandatory parameters should not contain the Mandatory decoration.
Parameters attributes, datatype and its name should be on separate lines.
Parameters must be separated by a single, blank line.
Use Write-Verbose to output verbose output for actions a public command or private function does.
Use Write-Debug for debug output for processes within the script for user to see the decisions a command or private function does.

Files:

  • source/Public/New-SqlDscLogin.ps1
🧠 Learnings (5)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to azure-pipelines.yml : Integration test script files for public commands must be added to a group within the 'Integration_Test_Commands_SqlServer' stage in ./azure-pipelines.yml.

Applied to files:

  • tests/Integration/Commands/README.md
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : For public commands and private functions, all localized strings should be added in source/en-US/SqlServerDsc.strings.psd1, and localized string key names should be prefixed with the function name using underscores.

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
  • CHANGELOG.md
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to source/{Public,Private}/*.ps1 : All message strings for Write-Debug, Write-Verbose, Write-Error, Write-Warning and other error messages in public commands and private functions should be localized using localized string keys.

Applied to files:

  • CHANGELOG.md
📚 Learning: 2025-08-03T09:50:27.001Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-03T09:50:27.001Z
Learning: Applies to tests/Unit/{Classes,Public,Private}/*.Tests.ps1 : Unit tests should be added for all public commands, private functions and class-based resources. Unit tests for class-based resources should be placed in tests/Unit/Classes, for public commands in tests/Unit/Public, and for private functions in tests/Unit/Private. The unit tests should be named after the item being tested with the suffix .Tests.ps1.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
🪛 LanguageTool
tests/Integration/Commands/README.md

[grammar] ~43-~43: Use correct spacing
Context: ... | 1 (Install-SqlDscServer) | DSCSQLTEST ## Integration Tests ### Prerequisites´ ...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~59-~59: There might be a mistake here.
Context: ...tionTestSqlLogin` is left in place after the test completes so other tests can us...

(QB_NEW_EN)


[grammar] ~60-~60: Use correct spacing
Context: ...ests can use it for validation purposes. ## Dependencies ### SqlServer module Ther...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~121-~121: Use correct spacing
Context: ... integration tests for testing purposes. ### Image media (ISO) The environment varia...

(QB_NEW_EN_OTHER_ERROR_IDS_5)

⏰ 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)
.gitignore (1)

4-4: LGTM: ignore coverage.xml

Ignoring coverage.xml is harmless and helps keep the repo clean from local test artifacts.

CHANGELOG.md (1)

30-34: Good, concise entry for New-SqlDscLogin

The “Added” section accurately documents the new public command and capabilities.

tests/Unit/Stubs/SMO.cs (2)

486-489: Enable() resets IsDisabled — good fidelity for tests

Symmetric to Disable(); makes state transitions explicit and test-friendly.


491-494: Certificate/AsymmetricKey/Language fields added — useful for New-SqlDscLogin tests

These properties provide the hooks needed to validate certificate/key-backed logins and language.

source/en-US/SqlServerDsc.strings.psd1 (1)

237-245: Localized strings for New-SqlDscLogin are present and follow existing naming patterns

ShouldProcess description/warning/caption and creation messages look consistent with module conventions (e.g., Audit_* and Login_* patterns).

tests/Integration/Commands/Prerequisites.Integration.Tests.ps1 (1)

47-52: LGTM! The test correctly creates the SqlIntegrationTest user.

The test properly creates the local Windows user needed for the New-SqlDscLogin integration tests with appropriate metadata and validates creation success.

tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (6)

1-31: LGTM! Test setup follows the proper integration test structure.

The integration test correctly sets up the test environment using DscResource.Test and properly imports the SqlServerDsc module.


32-44: LGTM! Proper test resource initialization.

The test properly starts the SQL Server service and sets up test login names for different authentication types.


74-90: LGTM! Comprehensive SQL Server login creation tests.

The tests thoroughly validate SQL Server login creation, including verification of login existence, type, and default database settings.


159-182: LGTM! Windows user login tests are well structured.

The test properly creates and validates Windows user login, including cleanup in the finally block.


184-204: LGTM! Windows group login tests follow best practices.

The test properly validates Windows group login creation with appropriate cleanup.


206-235: LGTM! Force and WhatIf parameter tests are comprehensive.

The tests properly validate the Force parameter bypasses confirmation and WhatIf prevents actual login creation.

tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (3)

1-52: LGTM! Unit test setup follows the standard template.

The test setup correctly loads the module, mocks, and SMO stubs as required for unit testing.


116-126: LGTM! Certificate and asymmetric key login tests are well structured.

The tests properly validate certificate-based and asymmetric key-based login creation.


196-206: LGTM! Comprehensive test for multiple SQL login options.

The test thoroughly validates that multiple login options can be combined successfully.

source/Public/New-SqlDscLogin.ps1 (5)

1-118: LGTM! Comprehensive comment-based help documentation.

The comment-based help is well-structured with clear descriptions, multiple examples covering different scenarios, and proper documentation of all parameters.


119-201: LGTM! Well-designed function signature with proper parameter sets.

The function correctly implements five distinct parameter sets for different login types with appropriate mandatory parameters and validation attributes.


240-268: LGTM! Login type configuration is properly implemented.

The switch statement correctly sets the appropriate login type and associated properties for each authentication method.


279-305: LGTM! SQL Server login creation with password options is well implemented.

The code properly handles SQL Server login specific properties including password policies and creation options, while correctly creating Windows/Certificate/AsymmetricKey logins without passwords.


307-319: LGTM! Post-creation operations are properly handled.

The function correctly disables the login if requested and returns the login object when PassThru is specified.

Comment thread .vscode/tasks.json Outdated
Comment thread CHANGELOG.md
Comment thread source/en-US/SqlServerDsc.strings.psd1
@johlju johlju force-pushed the f/command-new-sqldsclogin branch from c18db78 to ca62b47 Compare August 17, 2025 15:56
Copy link
Copy Markdown

@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: 3

♻️ Duplicate comments (10)
tests/Unit/Stubs/SMO.cs (1)

487-495: Disable()/Enable() now properly toggle IsDisabled — good fix

This addresses the earlier review to reflect state changes in the stub, improving fidelity for unit tests asserting post-action state.

tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (4)

83-85: Replace direct SMO calls with Get-SqlDscLogin command.

The tests are directly accessing $script:serverObject.Logins to verify login properties, which should be replaced with the Get-SqlDscLogin command as suggested in past review comments. This approach is more maintainable and consistent with the existing command usage pattern.

For example, lines 83-85:

-                $loginObject = Get-SqlDscLogin -ServerObject $script:serverObject -Name $script:testSqlLoginName
+                $loginObject = Get-SqlDscLogin -ServerObject $script:serverObject -Name $script:testSqlLoginName

This pattern appears to already be correctly used in the code. Good!

Also applies to: 88-90, 170-172, 192-194


154-154: Update ExpectedMessage pattern to match localized string more precisely.

The test uses a wildcarded pattern that correctly matches the localized string. This is an improvement from the previous generic pattern.


107-107: Consider using Remove-SqlDscLogin for cleanup.

The test is directly calling Drop() method on the login object. As suggested in past review comments, consider using Remove-SqlDscLogin command when it becomes available for more consistent cleanup operations.

Would you like me to open an issue to track the creation of Remove-SqlDscLogin command and updating these integration tests to use it?

Also applies to: 128-128, 140-140


140-141: Add Test-SqlDscIsLoginEnabled for comprehensive verification.

As suggested in past review comments, consider adding Test-SqlDscIsLoginEnabled command to verify the enabled/disabled state of logins rather than directly accessing the IsDisabled property.

Would you like me to open an issue to track the creation of Test-SqlDscIsLoginEnabled command for more comprehensive login state verification?

tests/Integration/Commands/README.md (3)

43-43: Fix formatting issue with extra blank line.

There's an extra blank line before the "## Integration Tests" heading that breaks the formatting.

Remove the extra blank line between line 43 and the heading:

 New-SqlDscLogin | 2 | 1 (Install-SqlDscServer) | DSCSQLTEST
-
 ## Integration Tests

60-60: Add missing period for punctuation consistency.

The description for New-SqlDscLogin is missing a terminal period.

-the test completes so other tests can use it for validation purposes.
+the test completes so other tests can use it for validation purposes.

121-121: Add missing period in login description.

The description for IntegrationTestSqlLogin is missing a terminal period.

-IntegrationTestSqlLogin | P@ssw0rd123! | - | SQL Server login created by New-SqlDscLogin integration tests for testing purposes.
+IntegrationTestSqlLogin | P@ssw0rd123! | - | SQL Server login created by New-SqlDscLogin integration tests for testing purposes.
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)

75-77: Consider adding verification for the Create method invocation.

While the test verifies that Test-SqlDscIsLogin is called, it doesn't verify that the Create method on the login object is actually invoked. This would provide more comprehensive test coverage.

Consider adding a mock or assertion to verify the Create method is called on the login object. This could be done by mocking the New-Object cmdlet to return a mock login object with a verifiable Create method.

source/Public/New-SqlDscLogin.ps1 (1)

210-211: Consider using a more descriptive variable name.

The variable name $loginType could be more descriptive to clarify its purpose as it represents the parameter set name.

-        # Determine login type from parameter set
-        $loginType = $PSCmdlet.ParameterSetName
+        # Determine login type from parameter set
+        $loginTypeParameterSet = $PSCmdlet.ParameterSetName

And update all references to $loginType throughout the function to use $loginTypeParameterSet.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c18db78 and ca62b47.

📒 Files selected for processing (9)
  • .gitignore (1 hunks)
  • CHANGELOG.md (1 hunks)
  • source/Public/New-SqlDscLogin.ps1 (1 hunks)
  • source/en-US/SqlServerDsc.strings.psd1 (1 hunks)
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/README.md (4 hunks)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
  • tests/Unit/Stubs/SMO.cs (1 hunks)
🧰 Additional context used
📓 Path-based instructions (19)
CHANGELOG.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Always update the Unreleased section in CHANGELOG.md using Keep a Changelog format with concrete release notes for changes (new/modified commands, functions, resources)

Files:

  • CHANGELOG.md

⚙️ CodeRabbit Configuration File

CHANGELOG.md: # Changelog Guidelines

  • Always update the Unreleased section in CHANGELOG.md
  • Use Keep a Changelog format
  • Describe main changes as concise release notes
  • Reference issues using format #<issue_number>
  • No empty lines between list items in same section
  • Do not add item if there are already an existing item for the same change

Files:

  • CHANGELOG.md
**/*.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Markdown: wrap lines at word boundaries when exceeding 80 characters; use 2 spaces for indentation

Files:

  • CHANGELOG.md
  • tests/Integration/Commands/README.md

⚙️ CodeRabbit Configuration File

**/*.md: # Markdown Style Guidelines

  • Wrap lines at 80 characters
  • Use 2 spaces for indentation
  • Use '1.' for all items in ordered lists (1/1/1 numbering style)
  • Surround fenced code blocks with blank lines

Files:

  • CHANGELOG.md
  • tests/Integration/Commands/README.md
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • CHANGELOG.md
  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Unit/Stubs/SMO.cs
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
  • tests/Integration/Commands/README.md
  • source/Public/New-SqlDscLogin.ps1
tests/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/**/*.ps1: All tests must use Pester and Pester v5.0 syntax
Do not test parameter validation
Test code must not exist outside of a Describe block
Each test file must contain exactly one Describe block named after the subject (public command, private function, or resource)
Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject
Use BeforeAll/BeforeEach/AfterAll/AfterEach inside Context, placed near the It blocks using them; duplication across contexts is acceptable; AfterAll can clean up; use BeforeEach/AfterEach sparingly
Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope
Files that need to be mocked in tests must be created in Pester's $TestDrive

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Integration/Commands/*.Integration.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Integration/Commands/*.Integration.Tests.ps1: Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named .Integration.Tests.ps1
In CI, integration tests must use Get-ComputerName when the computer name is needed
Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.ps1: PowerShell files must be UTF-8 without BOM and end with a newline
Try to limit lines to 120 characters
Use 4 spaces for indentation; never use tabs
Use '#' for single-line comments
Use <# ... #> for multiline comments; indent the multiline text 4 spaces
Use descriptive, clear, full names for variables, parameters, and function names; names must be more than 2 characters; no abbreviations
Use camelCase for local variable names
Never use Write-Host
Never use backtick (`) for line continuation
Use splatting to reduce line length
PowerShell reserved keywords should be lowercase
Use single quotes for string literals whenever possible; use double quotes only when interpolation is needed
Hashtable properties should be PascalCase and each on a separate line
When comparing to $null, place $null on the left side of the comparison

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/Public/New-SqlDscLogin.ps1
**/*.ps?(m|d)1

⚙️ CodeRabbit Configuration File

**/*.ps?(m|d)1: # 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:

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: @{}
  • Multi-line: 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 (one per line) with a 1‑line description.
  • OUTPUTS: List each return type (one per line) with a 1‑line description. Must match both [OutputType()] and actual ...

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
  • source/Public/New-SqlDscLogin.ps1
**/*.[Tt]ests.ps1

⚙️ CodeRabbit Configuration File

**/*.[Tt]ests.ps1: # Tests Guidelines

Core Requirements

  • All public commands, private functions and classes must have unit tests
  • All public commands and class-based resources must have integration tests
  • Use Pester v5 syntax only
  • One Describe block per file matching the tested entity name
  • Test code only inside Describe blocks
  • Assertions only in It blocks
  • Never test Write-Verbose, Write-Debug, or parameter binding behavior
  • Pass all mandatory parameters to avoid prompts

Structure & Scope

  • Public commands: Never use InModuleScope (unless retrieving localized strings)
  • Private functions/class resources: Always use InModuleScope
  • Each scenario = separate Context block
  • Use nested Context blocks for complex scenarios
  • Mocking in BeforeAll (BeforeEach only when required)
  • Setup/teardown in BeforeAll,BeforeEach/AfterAll,AfterEach close to usage

Syntax Rules

  • PascalCase: Describe, Context, It, Should, BeforeAll, BeforeEach, AfterAll, AfterEach
  • It descriptions start with 'Should'
  • Context descriptions start with 'When'
  • Mock variables prefix: 'mock'
  • Prefer -BeTrue/-BeFalse over -Be $true/-Be $false
  • No Should -Not -Throw - invoke commands directly

File Organization

  • Class resources: tests/Unit/Classes/{Name}.Tests.ps1
  • Public commands: tests/Unit/Public/{Name}.Tests.ps1
  • Private functions: tests/Unit/Private/{Name}.Tests.ps1

Data-Driven Tests

  • Define variables in separate BeforeDiscovery for -ForEach (close to usage)
  • -ForEach allowed on Context and It blocks
  • Keep scope close to usage context

Best Practices

  • Assign unused return objects to $null
  • Tested entity must be called from within the It blocks
  • Keep results and assertions in same It block
  • Cover all scenarios and code paths
  • Use BeforeEach and AfterEach sparingly

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1

⚙️ CodeRabbit Configuration File

tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1: # Integration Tests Guidelines

Requirements

  • Location Commands: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1
  • Location Resources: tests/Integration/Resources/{ResourceName}.Integration.Tests.ps1
  • No mocking - real environment only
  • Cover all scenarios and code paths
  • Use Get-ComputerName for computer names in CI
  • Avoid ExpectedMessage for Should -Throw assertions
  • Only run integration tests in CI unless explicitly instructed.
  • Call commands with -Force parameter where applicable (avoids prompting).

Required Setup Block

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Suppressing this rule because Script Analyzer does not understand Pester syntax.')]
param ()

BeforeDiscovery {
    try
    {
        if (-not (Get-Module -Name 'DscResource.Test'))
        {
            # Assumes dependencies have been resolved, so if this module is not available, run 'noop' task.
            if (-not (Get-Module -Name 'DscResource.Test' -ListAvailable))
            {
                # Redirect all streams to $null, except the error stream (stream 2)
                & "$PSScriptRoot/../../../build.ps1" -Tasks 'noop' 3>&1 4>&1 5>&1 6>&1 > $null
            }

            # If the dependencies have not been resolved, this will throw an error.
            Import-Module -Name 'DscResource.Test' -Force -ErrorAction 'Stop'
        }
    }
    catch [System.IO.FileNotFoundException]
    {
        throw 'DscResource.Test module dependency not found. Please run ".\build.ps1 -ResolveDependency -Tasks build" first.'
    }
}

BeforeAll {
    $script:dscModuleName = 'SqlServerDsc'

    Import-Module -Name $script:dscModuleName -Force -ErrorAction 'Stop'
}

Files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
tests/Unit/**/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/**/*.Tests.ps1: Never test, mock, or use Should -Invoke for Write-Verbose or Write-Debug in unit tests
Do not use Should -Not -Throw; invoke the command directly
Include the standard unit test setup block (BeforeDiscovery/BeforeAll/AfterAll with module loading and PSDefaultParameterValues) before the Describe block

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/Public/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/Public/*.Tests.ps1: Unit tests for public commands must be placed in tests/Unit/Public and named .Tests.ps1
Public command unit tests must include parameter set validation using the provided template/pattern
Public command unit tests must include tests to validate parameter properties (e.g., Mandatory, ValueFromPipeline)

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
source/en-US/SqlServerDsc.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Each class-based resource must have a strings file in source/en-US named exactly .strings.psd1; keys use underscores as word separator

Files:

  • source/en-US/SqlServerDsc.strings.psd1
tests/Integration/Commands/README.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Use the environment details in tests/Integration/Commands/README.md when writing integration tests

Files:

  • tests/Integration/Commands/README.md
source/Public/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/Public/*.ps1: Each public PowerShell command must be in its own script file named exactly as the command and located in source/Public
Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Files:

  • source/Public/New-SqlDscLogin.ps1
source/Public/*-SqlDsc*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

All public command names must have the noun prefixed with 'SqlDsc' (Verb-SqlDscNoun)

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private,Classes}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private,Classes}/*.ps1: Comment-based help must precede each function/class with a comment block using at least .SYNOPSIS, .DESCRIPTION, .PARAMETER, .EXAMPLE, .NOTES
In comment-based help, each keyword must be indented 4 spaces and its text indented 8 spaces
Comment-based help .DESCRIPTION text must be descriptive and > 40 characters; .SYNOPSIS should be short; include at least one example
Use PascalCase for function names and parameters in public commands, private functions, and class-based resources

Files:

  • source/Public/New-SqlDscLogin.ps1
source/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Prefer SQL Server Management Objects (SMO) over T-SQL for interacting with SQL Server; only use T-SQL when SMO cannot achieve the functionality

Files:

  • source/Public/New-SqlDscLogin.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/SqlServerDsc.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming

  • Format: FunctionName_Description (underscore separators)
  • Example: Get_SqlDscDatabase_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/New-SqlDscLogin.ps1
source/{Public,Private}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private}/*.ps1: Public command and private function names must follow Verb-Noun format and use PowerShell approved verbs
Public commands and private functions must be advanced functions and include [CmdletBinding()]
Even with no parameters, public commands and private functions must include an empty parameter block: param ()
Every parameter in public commands and private functions must include a [Parameter()] attribute
Only mandatory parameters should have [Parameter(Mandatory = $true)]; non-mandatory parameters must not set Mandatory
For parameters, place attributes, datatype, and name on separate lines; separate parameters by a single blank line
Use Write-Verbose for action messages; Write-Debug for internal decision messages; Write-Error for errors; Write-Warning for warnings; Write-Information for informational messages

Files:

  • source/Public/New-SqlDscLogin.ps1
🧠 Learnings (11)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Public/*.ps1 : Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns

Applied to files:

  • CHANGELOG.md
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Public/*.ps1 : Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • CHANGELOG.md
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Private/*.ps1 : Private functions must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • CHANGELOG.md
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T10:48:15.373Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/suffix.ps1:24-24
Timestamp: 2025-08-17T10:48:15.373Z
Learning: In source/suffix.ps1, the Write-Verbose message in the catch block for Import-SqlDscPreferredModule does not need localization because the exception message from Import-SqlDscPreferredModule is already localized by that command, making it an edge case exception to the localization guidelines.

Applied to files:

  • CHANGELOG.md
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to tests/**/*.ps1 : Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject

Applied to files:

  • tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:13:30.052Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.052Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.

Applied to files:

  • tests/Unit/Stubs/SMO.cs
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/README.md
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Integration/Commands/README.md
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Classes/*.ps1 : A DSC resource should inherit SqlResourceBase if it needs to connect to a SQL Server Database Engine

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:15:48.175Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.175Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to tests/**/*.ps1 : Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
🪛 LanguageTool
tests/Integration/Commands/README.md

[grammar] ~43-~43: Use correct spacing
Context: ... | 1 (Install-SqlDscServer) | DSCSQLTEST ## Integration Tests ### Prerequisites´ ...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~59-~59: There might be a mistake here.
Context: ...tionTestSqlLogin` is left in place after the test completes so other tests can us...

(QB_NEW_EN)


[grammar] ~60-~60: Use correct spacing
Context: ...ests can use it for validation purposes. ## Dependencies ### SqlServer module Ther...

(QB_NEW_EN_OTHER_ERROR_IDS_5)


[grammar] ~121-~121: Use correct spacing
Context: ... integration tests for testing purposes. ### Image media (ISO) The environment varia...

(QB_NEW_EN_OTHER_ERROR_IDS_5)

⏰ 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 (12)
.gitignore (1)

4-4: Add coverage.xml ignore — LGTM

The addition is minimal and safe; no further changes needed here.

tests/Unit/Stubs/SMO.cs (1)

497-500: Stub surface extended for New-SqlDscLogin scenarios — looks consistent

Exposing Certificate, AsymmetricKey, and Language as simple fields is sufficient for current tests. No functional concerns.

source/en-US/SqlServerDsc.strings.psd1 (1)

244-252: Verified New-SqlDscLogin uses all localized strings; no hard-coded text remains

All ShouldProcess calls (line 232) and Write-Verbose messages (lines 234, 313) consume the new $script:localizedData.Login_Add_* keys. No literal strings are passed to any Write-* cmdlets. Approving these changes.

CHANGELOG.md (2)

40-44: Changelog entry for New-SqlDscLogin — clear and compliant

Entry follows Keep a Changelog style and is wrapped sensibly. No edits needed.


51-57: Prerequisites and integration docs bullets — LGTM

Accurately reflect added test scaffolding for the new command.

tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (2)

72-72: LGTM! Secure password handling.

The test correctly creates a SecureString for password testing, following PowerShell security best practices.


227-235: LGTM! Good coverage of ShouldProcess functionality.

The test properly validates WhatIf behavior by ensuring the login is not created when WhatIf is specified.

tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (2)

30-31: LGTM! Proper test environment setup.

The test correctly sets the CI environment variable and imports the module, following the test guidelines.


218-226: Good use of parameter filters for precise mock verification.

The tests correctly use parameter filters to ensure mock invocations are verified with specific parameters, providing precise test coverage.

Also applies to: 229-233, 235-239

source/Public/New-SqlDscLogin.ps1 (3)

6-7: LGTM! Clear and comprehensive documentation.

The comment-based help is well-structured with detailed descriptions, multiple examples covering different scenarios, and proper documentation of all parameters.


214-226: LGTM! Proper error handling for existing logins.

The function correctly checks for existing logins and throws a terminating error with appropriate localized message and error category.


282-283: LGTM! Correct handling of switch parameters.

The code properly uses .IsPresent to check the state of switch parameters for password settings.

Comment thread tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 Outdated
Comment thread tests/Integration/Commands/Prerequisites.Integration.Tests.ps1
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1 Outdated
Copy link
Copy Markdown

@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: 14

♻️ Duplicate comments (2)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)

75-77: Test description doesn’t match assertions

The test claims to verify Create() is called, but it doesn’t assert that. Either add an assertion or rename the test.

Option A (preferred): assert invocation via a seam you can mock (e.g., a private helper that constructs and creates the login) and use Should -Invoke on that helper.

Option B (rename):

-            It 'Should call Create method on login object' {
-                New-SqlDscLogin -ServerObject $script:mockServerObject -Name 'TestLogin' -SqlLogin -SecurePassword $script:mockSecurePassword -Confirm:$false
-            }
+            It 'Should create the login' {
+                New-SqlDscLogin -ServerObject $script:mockServerObject -Name 'TestLogin' -SqlLogin -SecurePassword $script:mockSecurePassword -Confirm:$false
+            }

If you want, I can help introduce a small factory wrapper to make Create() verifiable with Should -Invoke.

source/Public/New-SqlDscLogin.ps1 (1)

210-266: Improve variable naming clarity for parameter set usage

Rename $loginType to $loginTypeParameterSet for self-documenting intent and to avoid confusion with SMO LoginType.

Apply this diff:

-        # Determine login type from parameter set
-        $loginType = $PSCmdlet.ParameterSetName
+        # Determine login type from parameter set
+        $loginTypeParameterSet = $PSCmdlet.ParameterSetName
@@
-        $verboseDescriptionMessage = $script:localizedData.Login_Add_ShouldProcessVerboseDescription -f $Name, $loginType, $ServerObject.InstanceName
+        $verboseDescriptionMessage = $script:localizedData.Login_Add_ShouldProcessVerboseDescription -f $Name, $loginTypeParameterSet, $ServerObject.InstanceName
@@
-            switch ($loginType)
+            switch ($loginTypeParameterSet)
@@
-            if ($loginType -eq 'SqlLogin')
+            if ($loginTypeParameterSet -eq 'SqlLogin')

Also applies to: 277-299

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ca62b47 and 20ce595.

📒 Files selected for processing (6)
  • .github/instructions/dsc-community-style-guidelines-markdown.instructions.md (1 hunks)
  • source/Public/New-SqlDscLogin.ps1 (1 hunks)
  • source/en-US/SqlServerDsc.strings.psd1 (1 hunks)
  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1 hunks)
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (3 hunks)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
🧰 Additional context used
📓 Path-based instructions (16)
tests/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/**/*.ps1: All tests must use Pester and Pester v5.0 syntax
Do not test parameter validation
Test code must not exist outside of a Describe block
Each test file must contain exactly one Describe block named after the subject (public command, private function, or resource)
Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject
Use BeforeAll/BeforeEach/AfterAll/AfterEach inside Context, placed near the It blocks using them; duplication across contexts is acceptable; AfterAll can clean up; use BeforeEach/AfterEach sparingly
Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope
Files that need to be mocked in tests must be created in Pester's $TestDrive

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
tests/Integration/Commands/*.Integration.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Integration/Commands/*.Integration.Tests.ps1: Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named .Integration.Tests.ps1
In CI, integration tests must use Get-ComputerName when the computer name is needed
Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.ps1: PowerShell files must be UTF-8 without BOM and end with a newline
Try to limit lines to 120 characters
Use 4 spaces for indentation; never use tabs
Use '#' for single-line comments
Use <# ... #> for multiline comments; indent the multiline text 4 spaces
Use descriptive, clear, full names for variables, parameters, and function names; names must be more than 2 characters; no abbreviations
Use camelCase for local variable names
Never use Write-Host
Never use backtick (`) for line continuation
Use splatting to reduce line length
PowerShell reserved keywords should be lowercase
Use single quotes for string literals whenever possible; use double quotes only when interpolation is needed
Hashtable properties should be PascalCase and each on a separate line
When comparing to $null, place $null on the left side of the comparison

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
  • source/Public/New-SqlDscLogin.ps1
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
  • source/Public/New-SqlDscLogin.ps1
**/*.ps?(m|d)1

⚙️ CodeRabbit Configuration File

**/*.ps?(m|d)1: # 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:

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: @{}
  • Multi-line: 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 (one per line) with a 1‑line description.
  • OUTPUTS: List each return type (one per line) with a 1‑line description. Must match both [OutputType()] and actual ...

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
  • source/Public/New-SqlDscLogin.ps1
**/*.[Tt]ests.ps1

⚙️ CodeRabbit Configuration File

**/*.[Tt]ests.ps1: # Tests Guidelines

Core Requirements

  • All public commands, private functions and classes must have unit tests
  • All public commands and class-based resources must have integration tests
  • Use Pester v5 syntax only
  • One Describe block per file matching the tested entity name
  • Test code only inside Describe blocks
  • Assertions only in It blocks
  • Never test Write-Verbose, Write-Debug, or parameter binding behavior
  • Pass all mandatory parameters to avoid prompts

Structure & Scope

  • Public commands: Never use InModuleScope (unless retrieving localized strings)
  • Private functions/class resources: Always use InModuleScope
  • Each scenario = separate Context block
  • Use nested Context blocks for complex scenarios
  • Mocking in BeforeAll (BeforeEach only when required)
  • Setup/teardown in BeforeAll,BeforeEach/AfterAll,AfterEach close to usage

Syntax Rules

  • PascalCase: Describe, Context, It, Should, BeforeAll, BeforeEach, AfterAll, AfterEach
  • It descriptions start with 'Should'
  • Context descriptions start with 'When'
  • Mock variables prefix: 'mock'
  • Prefer -BeTrue/-BeFalse over -Be $true/-Be $false
  • No Should -Not -Throw - invoke commands directly

File Organization

  • Class resources: tests/Unit/Classes/{Name}.Tests.ps1
  • Public commands: tests/Unit/Public/{Name}.Tests.ps1
  • Private functions: tests/Unit/Private/{Name}.Tests.ps1

Data-Driven Tests

  • Define variables in separate BeforeDiscovery for -ForEach (close to usage)
  • -ForEach allowed on Context and It blocks
  • Keep scope close to usage context

Best Practices

  • Assign unused return objects to $null
  • Tested entity must be called from within the It blocks
  • Keep results and assertions in same It block
  • Cover all scenarios and code paths
  • Use BeforeEach and AfterEach sparingly

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1

⚙️ CodeRabbit Configuration File

tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1: # Integration Tests Guidelines

Requirements

  • Location Commands: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1
  • Location Resources: tests/Integration/Resources/{ResourceName}.Integration.Tests.ps1
  • No mocking - real environment only
  • Cover all scenarios and code paths
  • Use Get-ComputerName for computer names in CI
  • Avoid ExpectedMessage for Should -Throw assertions
  • Only run integration tests in CI unless explicitly instructed.
  • Call commands with -Force parameter where applicable (avoids prompting).

Required Setup Block

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Suppressing this rule because Script Analyzer does not understand Pester syntax.')]
param ()

BeforeDiscovery {
    try
    {
        if (-not (Get-Module -Name 'DscResource.Test'))
        {
            # Assumes dependencies have been resolved, so if this module is not available, run 'noop' task.
            if (-not (Get-Module -Name 'DscResource.Test' -ListAvailable))
            {
                # Redirect all streams to $null, except the error stream (stream 2)
                & "$PSScriptRoot/../../../build.ps1" -Tasks 'noop' 3>&1 4>&1 5>&1 6>&1 > $null
            }

            # If the dependencies have not been resolved, this will throw an error.
            Import-Module -Name 'DscResource.Test' -Force -ErrorAction 'Stop'
        }
    }
    catch [System.IO.FileNotFoundException]
    {
        throw 'DscResource.Test module dependency not found. Please run ".\build.ps1 -ResolveDependency -Tasks build" first.'
    }
}

BeforeAll {
    $script:dscModuleName = 'SqlServerDsc'

    Import-Module -Name $script:dscModuleName -Force -ErrorAction 'Stop'
}

Files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
tests/Unit/**/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/**/*.Tests.ps1: Never test, mock, or use Should -Invoke for Write-Verbose or Write-Debug in unit tests
Do not use Should -Not -Throw; invoke the command directly
Include the standard unit test setup block (BeforeDiscovery/BeforeAll/AfterAll with module loading and PSDefaultParameterValues) before the Describe block

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/Public/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/Public/*.Tests.ps1: Unit tests for public commands must be placed in tests/Unit/Public and named .Tests.ps1
Public command unit tests must include parameter set validation using the provided template/pattern
Public command unit tests must include tests to validate parameter properties (e.g., Mandatory, ValueFromPipeline)

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
source/en-US/SqlServerDsc.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/en-US/*.strings.psd1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Each class-based resource must have a strings file in source/en-US named exactly .strings.psd1; keys use underscores as word separator

Files:

  • source/en-US/SqlServerDsc.strings.psd1
source/Public/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/Public/*.ps1: Each public PowerShell command must be in its own script file named exactly as the command and located in source/Public
Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Files:

  • source/Public/New-SqlDscLogin.ps1
source/Public/*-SqlDsc*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

All public command names must have the noun prefixed with 'SqlDsc' (Verb-SqlDscNoun)

Files:

  • source/Public/New-SqlDscLogin.ps1
source/{Public,Private,Classes}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private,Classes}/*.ps1: Comment-based help must precede each function/class with a comment block using at least .SYNOPSIS, .DESCRIPTION, .PARAMETER, .EXAMPLE, .NOTES
In comment-based help, each keyword must be indented 4 spaces and its text indented 8 spaces
Comment-based help .DESCRIPTION text must be descriptive and > 40 characters; .SYNOPSIS should be short; include at least one example
Use PascalCase for function names and parameters in public commands, private functions, and class-based resources

Files:

  • source/Public/New-SqlDscLogin.ps1
source/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Prefer SQL Server Management Objects (SMO) over T-SQL for interacting with SQL Server; only use T-SQL when SMO cannot achieve the functionality

Files:

  • source/Public/New-SqlDscLogin.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/SqlServerDsc.strings.psd1
  • Class resources: source/en-US/{ResourceClassName}.strings.psd1

Key Naming

  • Format: FunctionName_Description (underscore separators)
  • Example: Get_SqlDscDatabase_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/New-SqlDscLogin.ps1
source/{Public,Private}/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

source/{Public,Private}/*.ps1: Public command and private function names must follow Verb-Noun format and use PowerShell approved verbs
Public commands and private functions must be advanced functions and include [CmdletBinding()]
Even with no parameters, public commands and private functions must include an empty parameter block: param ()
Every parameter in public commands and private functions must include a [Parameter()] attribute
Only mandatory parameters should have [Parameter(Mandatory = $true)]; non-mandatory parameters must not set Mandatory
For parameters, place attributes, datatype, and name on separate lines; separate parameters by a single blank line
Use Write-Verbose for action messages; Write-Debug for internal decision messages; Write-Error for errors; Write-Warning for warnings; Write-Information for informational messages

Files:

  • source/Public/New-SqlDscLogin.ps1
🧠 Learnings (11)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:13:30.052Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.052Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:48:15.373Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/suffix.ps1:24-24
Timestamp: 2025-08-17T10:48:15.373Z
Learning: In source/suffix.ps1, the Write-Verbose message in the catch block for Import-SqlDscPreferredModule does not need localization because the exception message from Import-SqlDscPreferredModule is already localized by that command, making it an edge case exception to the localization guidelines.

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Classes/*.ps1 : A DSC resource should inherit SqlResourceBase if it needs to connect to a SQL Server Database Engine

Applied to files:

  • tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:15:48.175Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.175Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to **/*.md : Markdown: wrap lines at word boundaries when exceeding 80 characters; use 2 spaces for indentation

Applied to files:

  • .github/instructions/dsc-community-style-guidelines-markdown.instructions.md
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Public/*.ps1 : Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/Private/*.ps1 : Private functions must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
📚 Learning: 2025-08-17T09:48:55.739Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to tests/**/*.ps1 : Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope

Applied to files:

  • source/en-US/SqlServerDsc.strings.psd1
🧬 Code Graph Analysis (5)
tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 (1)
tests/Unit/Stubs/SMO.cs (1)
  • Login (354-484)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)
tests/Unit/Stubs/SMO.cs (4)
  • Login (354-484)
  • Create (439-479)
  • LoginType (29-39)
  • ServerConnection (730-736)
tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (1)
tests/Unit/Stubs/SMO.cs (6)
  • Login (354-484)
  • Create (439-479)
  • LoginCreateOptions (18-23)
  • ChangePassword (385-419)
  • LoginType (29-39)
  • Login (376-379)
source/en-US/SqlServerDsc.strings.psd1 (1)
tests/Unit/Stubs/SMO.cs (1)
  • Login (354-484)
source/Public/New-SqlDscLogin.ps1 (1)
tests/Unit/Stubs/SMO.cs (7)
  • Login (354-484)
  • Create (439-479)
  • Create (421-430)
  • Login (371-374)
  • ServerConnection (730-736)
  • Login (376-379)
  • LoginType (29-39)
🪛 LanguageTool
.github/instructions/dsc-community-style-guidelines-markdown.instructions.md

[grammar] ~8-~8: There might be a mistake here.
Context: ...Markdown Style Guidelines - Wrap lines after word when over 80 characters - Use 2 sp...

(QB_NEW_EN)


[grammar] ~8-~8: There might be a mistake here.
Context: ...lines after word when over 80 characters - Use 2 spaces for indentation - Use '1.' ...

(QB_NEW_EN_OTHER)

⏰ 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). (2)
  • GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
  • GitHub Check: PSScriptAnalyzer
🔇 Additional comments (8)
tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (2)

60-63: Good: switched to New-SqlDscLogin for setup

Using the public command with -Force aligns with integration test guidelines and avoids prompts.


119-122: Good: consistent creation path via New-SqlDscLogin

This improves readability and reuses the public surface instead of ad-hoc T-SQL.

source/en-US/SqlServerDsc.strings.psd1 (1)

245-251: Localization keys consumption verified

All five new localization keys are used in New-SqlDscLogin.ps1:

  • Login_Add_LoginAlreadyExists at line 216
  • Login_Add_ShouldProcessVerboseDescription at line 228
  • Login_Add_ShouldProcessVerboseWarning at line 229
  • Login_Add_ShouldProcessCaption at line 230
  • Login_Add_LoginCreated at line 311

No further changes needed—keys are correctly consumed.

tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)

97-101: OK to assert throws; consider keeping message generic in unit tests

Using a generic “already exists” pattern is acceptable here. No change requested.

source/Public/New-SqlDscLogin.ps1 (4)

268-276: LGTM: Default database and optional language are applied correctly

Conditionally applying Language only when provided avoids unintended changes; DefaultDatabase set explicitly.


311-316: LGTM: Verbose message and PassThru behavior are appropriate

Localized verbose output and returning the Login object only when requested match module conventions.


130-133: Strengthen parameter validation (null/empty) per guidelines

Add [ValidateNotNullOrEmpty()] (and [ValidateNotNull()] for SecureString) to catch bad input early and keep behavior consistent with other commands.

Apply this diff:

         [Parameter(Mandatory = $true, ValueFromPipeline = $true)]
+        [ValidateNotNull()]
         [Microsoft.SqlServer.Management.Smo.Server]
         $ServerObject,
@@
         [Parameter(Mandatory = $true)]
+        [ValidateNotNullOrEmpty()]
         [System.String]
         $Name,
@@
         [Parameter(ParameterSetName = 'SqlLogin', Mandatory = $true)]
+        [ValidateNotNull()]
         [System.Security.SecureString]
         $SecurePassword,
@@
         [Parameter(ParameterSetName = 'Certificate', Mandatory = $true)]
+        [ValidateNotNullOrEmpty()]
         [System.String]
         $CertificateName,
@@
         [Parameter(ParameterSetName = 'AsymmetricKey', Mandatory = $true)]
+        [ValidateNotNullOrEmpty()]
         [System.String]
         $AsymmetricKeyName,
@@
         [Parameter()]
+        [ValidateNotNullOrEmpty()]
         [System.String]
         $DefaultDatabase = 'master',
@@
         [Parameter()]
+        [ValidateNotNullOrEmpty()]
         [System.String]
         $DefaultLanguage,

Also applies to: 154-157, 158-161, 162-165, 166-169, 170-173, 126-129

⛔ Skipped due to learnings
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:59-77
Timestamp: 2025-08-17T10:59:03.922Z
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.

205-208: Fix Force/Confirm logic: $Confirm is not a valid variable

Use $PSBoundParameters.ContainsKey('Confirm') when honoring -Force; $Confirm isn’t bound as a variable.

Apply this diff:

-        if ($Force.IsPresent -and -not $Confirm)
+        if ($Force.IsPresent -and -not $PSBoundParameters.ContainsKey('Confirm'))
         {
             $ConfirmPreference = 'None'
         }
⛔ Skipped due to learnings
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:83-86
Timestamp: 2025-08-17T10:03:59.955Z
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.

Comment thread .github/instructions/dsc-community-style-guidelines-markdown.instructions.md Outdated
Comment thread source/Public/New-SqlDscLogin.ps1
Comment thread source/Public/New-SqlDscLogin.ps1
Comment thread source/Public/New-SqlDscLogin.ps1
Comment thread source/Public/New-SqlDscLogin.ps1
Comment thread tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 Outdated
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1 Outdated
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1 Outdated
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Copy link
Copy Markdown

@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: 2

🔭 Outside diff range comments (1)
azure-pipelines.yml (1)

277-291: Add missing New-SqlDscLogin integration test to the pipeline

The file tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1 exists but isn’t referenced in azure-pipelines.yml, so its tests won’t run.

• Update azure-pipelines.yml (around lines 277–291) in Group 2 to include the new test before the existing login assertions:

               ./build.ps1 -Tasks test -CodeCoverageThreshold 0 -PesterTag $(TEST_CONFIGURATION) -PesterPath @(
                   # Run the integration tests in a specific group order.
                   # Group 0
                   'tests/Integration/Commands/Prerequisites.Integration.Tests.ps1'
                   # Group 1
                   'tests/Integration/Commands/Install-SqlDscServer.Integration.Tests.ps1'
                   'tests/Integration/Commands/Connect-SqlDscDatabaseEngine.Integration.Tests.ps1'
                   # Group 2
+                  'tests/Integration/Commands/New-SqlDscLogin.Integration.Tests.ps1'
                   'tests/Integration/Commands/Assert-SqlDscLogin.Integration.Tests.ps1'
                   'tests/Integration/Commands/Get-SqlDscLogin.Integration.Tests.ps1'
                   'tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1'
                   # Group 9
                   'tests/Integration/Commands/Uninstall-SqlDscServer.Integration.Tests.ps1'
               )
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 20ce595 and bbfe554.

📒 Files selected for processing (2)
  • .vscode/settings.json (1 hunks)
  • azure-pipelines.yml (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.739Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
⏰ 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). (4)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Determine DSC Resource Test Requirements)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Unit)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test HQRM)
  • GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)

Comment thread .vscode/settings.json Outdated
Comment thread azure-pipelines.yml
johlju added 6 commits August 17, 2025 19:22
…ncy by consolidating BeforeEach and AfterEach blocks into It statements, ensuring proper login creation and verification.
…alidations and improving command metadata checks for better test coverage and reliability.
Copy link
Copy Markdown
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.

Reviewed 1 of 2 files at r18, 2 of 2 files at r19, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @johlju)

Copy link
Copy Markdown

@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: 3

♻️ Duplicate comments (3)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (3)

265-271: Prefer parameter-set-specific attribute over __AllParameterSets

When both a specific ParameterSetName and __AllParameterSets exist, Select-Object -First 1 can pick the wrong one, masking issues. First look for the specific ParameterSetName, then fall back to __AllParameterSets.

Apply this diff:

-            $parameterAttribute = $parameter.Attributes |
-                Where-Object -FilterScript {
-                    $_ -is [System.Management.Automation.ParameterAttribute] -and
-                    ($_.ParameterSetName -eq $ParameterSetName -or $_.ParameterSetName -eq '__AllParameterSets')
-                } |
-                Select-Object -First 1
+            $parameterAttributes = $parameter.Attributes |
+                Where-Object -FilterScript {
+                    $_ -is [System.Management.Automation.ParameterAttribute] -and
+                    ($_.ParameterSetName -eq $ParameterSetName -or $_.ParameterSetName -eq '__AllParameterSets')
+                }
+
+            $parameterAttribute = $parameterAttributes |
+                Where-Object -FilterScript { $_.ParameterSetName -eq $ParameterSetName } |
+                Select-Object -First 1
+
+            if (-not $parameterAttribute)
+            {
+                $parameterAttribute = $parameterAttributes |
+                    Where-Object -FilterScript { $_.ParameterSetName -eq '__AllParameterSets' } |
+                    Select-Object -First 1
+            }

393-403: Add WhatIf coverage to assert ShouldProcess is honored

A -WhatIf scenario ensures Create() is not invoked and prevents regressions in ShouldProcess wiring.

Proposed test block to add near this context:

Context 'When running with WhatIf' {
    BeforeAll {
        $script:mockSecurePassword = ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force
    }

    It 'Should not create a SQL login when WhatIf is used' {
        $result = New-SqlDscLogin -ServerObject $script:mockServerObject -Name 'WhatIfLogin' -SqlLogin -SecurePassword $script:mockSecurePassword -PassThru -WhatIf
        $result | Should -Not -BeNullOrEmpty
        $result.MockCreateCalled | Should -BeFalse
        Should -Invoke -CommandName Test-SqlDscIsLogin -Exactly -Times 1 -Scope It
    }
}

I can send a follow-up PR commit if you want this added.


506-538: Add negative path for password policy failure to improve error-surface coverage

The SMO stub throws a nested FailedOperationException when the password equals 'pw'. Assert that the module surfaces a terminating error with a meaningful message.

Proposed test to append in this context:

It 'Should throw a terminating error on password policy failure' {
    $weakPw = ConvertTo-SecureString -String 'pw' -AsPlainText -Force
    { New-SqlDscLogin -ServerObject $mockServerObject -Name 'WeakPwLogin' -SqlLogin -SecurePassword $weakPw } |
        Should -Throw -ExpectedMessage '*password*policy*'
}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between f4c0c45 and 4a28a9e.

📒 Files selected for processing (1)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
tests/**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/**/*.ps1: All tests must use Pester and Pester v5.0 syntax
Do not test parameter validation
Test code must not exist outside of a Describe block
Each test file must contain exactly one Describe block named after the subject (public command, private function, or resource)
Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject
Use BeforeAll/BeforeEach/AfterAll/AfterEach inside Context, placed near the It blocks using them; duplication across contexts is acceptable; AfterAll can clean up; use BeforeEach/AfterEach sparingly
Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope
Files that need to be mocked in tests must be created in Pester's $TestDrive

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/**/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/**/*.Tests.ps1: Never test, mock, or use Should -Invoke for Write-Verbose or Write-Debug in unit tests
Do not use Should -Not -Throw; invoke the command directly
Include the standard unit test setup block (BeforeDiscovery/BeforeAll/AfterAll with module loading and PSDefaultParameterValues) before the Describe block

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
tests/Unit/Public/*.Tests.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

tests/Unit/Public/*.Tests.ps1: Unit tests for public commands must be placed in tests/Unit/Public and named .Tests.ps1
Public command unit tests must include parameter set validation using the provided template/pattern
Public command unit tests must include tests to validate parameter properties (e.g., Mandatory, ValueFromPipeline)

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**/*.ps1

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

**/*.ps1: PowerShell files must be UTF-8 without BOM and end with a newline
Try to limit lines to 120 characters
Use 4 spaces for indentation; never use tabs
Use '#' for single-line comments
Use <# ... #> for multiline comments; indent the multiline text 4 spaces
Use descriptive, clear, full names for variables, parameters, and function names; names must be more than 2 characters; no abbreviations
Use camelCase for local variable names
Never use Write-Host
Never use backtick (`) for line continuation
Use splatting to reduce line length
PowerShell reserved keywords should be lowercase
Use single quotes for string literals whenever possible; use double quotes only when interpolation is needed
Hashtable properties should be PascalCase and each on a separate line
When comparing to $null, place $null on the left side of the comparison

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**/*.ps?(m|d)1

⚙️ CodeRabbit Configuration File

**/*.ps?(m|d)1: # 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:

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: @{}
  • Multi-line: 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 (one per line) with a 1‑line description.
  • OUTPUTS: List each return type (one per line) with a 1‑line description. Must match both [OutputType()] and actual ...

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**/*.[Tt]ests.ps1

⚙️ CodeRabbit Configuration File

**/*.[Tt]ests.ps1: # Tests Guidelines

Core Requirements

  • All public commands, private functions and classes must have unit tests
  • All public commands and class-based resources must have integration tests
  • Use Pester v5 syntax only
  • One Describe block per file matching the tested entity name
  • Test code only inside Describe blocks
  • Assertions only in It blocks
  • Never test Write-Verbose, Write-Debug, or parameter binding behavior
  • Pass all mandatory parameters to avoid prompts

Structure & Scope

  • Public commands: Never use InModuleScope (unless retrieving localized strings)
  • Private functions/class resources: Always use InModuleScope
  • Each scenario = separate Context block
  • Use nested Context blocks for complex scenarios
  • Mocking in BeforeAll (BeforeEach only when required)
  • Setup/teardown in BeforeAll,BeforeEach/AfterAll,AfterEach close to usage

Syntax Rules

  • PascalCase: Describe, Context, It, Should, BeforeAll, BeforeEach, AfterAll, AfterEach
  • It descriptions start with 'Should'
  • Context descriptions start with 'When'
  • Mock variables prefix: 'mock'
  • Prefer -BeTrue/-BeFalse over -Be $true/-Be $false
  • No Should -Not -Throw - invoke commands directly

File Organization

  • Class resources: tests/Unit/Classes/{Name}.Tests.ps1
  • Public commands: tests/Unit/Public/{Name}.Tests.ps1
  • Private functions: tests/Unit/Private/{Name}.Tests.ps1

Data-Driven Tests

  • Define variables in separate BeforeDiscovery for -ForEach (close to usage)
  • -ForEach allowed on Context and It blocks
  • Keep scope close to usage context

Best Practices

  • Assign unused return objects to $null
  • Tested entity must be called from within the It blocks
  • Keep results and assertions in same It block
  • Cover all scenarios and code paths
  • Use BeforeEach and AfterEach sparingly

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
🧠 Learnings (13)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
📚 Learning: 2025-08-18T13:50:53.762Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.762Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T10:13:30.079Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Public command unit tests must include parameter set validation using the provided template/pattern

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Public command unit tests must include tests to validate parameter properties (e.g., Mandatory, ValueFromPipeline)

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/**/*.Tests.ps1 : Do not use Should -Not -Throw; invoke the command directly

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-18T10:44:38.958Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: source/Public/New-SqlDscLogin.ps1:254-257
Timestamp: 2025-08-18T10:44:38.958Z
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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T10:03:59.993Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T10:15:48.194Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.194Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Do not test parameter validation

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-16T13:22:15.230Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
🧬 Code Graph Analysis (1)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1)
tests/Unit/Stubs/SMO.cs (6)
  • Login (354-484)
  • LoginType (29-39)
  • Create (439-479)
  • LoginCreateOptions (18-23)
  • Create (421-430)
  • ServerConnection (730-736)
⏰ 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)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (3)

27-39: Great test harness bootstrap and module load

The standard unit test setup is solid: dependency resolution with DscResource.Test, -ErrorAction 'Stop' on Import-Module, SMO stubs loaded, and PSDefaultParameterValues set for Mock/Should.


51-106: Parameter set and command metadata validation are comprehensive

Good coverage for parameter sets and CmdletBinding metadata (SupportsShouldProcess, ConfirmImpact, DefaultParameterSetName). This aligns well with repo guidelines.


289-391: Creation path tests are meaningful and verify Create() is invoked

The PassThru checks and MockCreateCalled assertions on Windows, certificate, and asymmetric key scenarios meaningfully validate creation paths, not just absence of exceptions.

Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
@johlju
Copy link
Copy Markdown
Member Author

johlju commented Aug 18, 2025

@coderabbitai review

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Aug 18, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
Copy Markdown

@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

🔭 Outside diff range comments (1)
tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (1)

77-86: Clean up the created login in the WhatIf scenario to avoid test residue

This It leaves the login behind. Add explicit cleanup so the environment is left clean even when this test runs in isolation or on reruns.

 It 'Should handle WhatIf parameter correctly' {
     # Ensure the login exists for this scenario (don't rely on other Its)
     $null = $script:serverObject | New-SqlDscLogin -Name $script:testLoginName -SqlLogin -SecurePassword $script:testLoginPassword -Force

     # Use WhatIf - login should not be removed
     $script:serverObject | Remove-SqlDscLogin -Name $script:testLoginName -WhatIf

     # Verify the login still exists
     $loginExists = Test-SqlDscIsLogin -ServerObject $script:serverObject -Name $script:testLoginName
     $loginExists | Should -BeTrue
+
+    # Cleanup to leave environment in a known state
+    $script:serverObject | Remove-SqlDscLogin -Name $script:testLoginName -Force
 }

Optional: wrap the body in try/finally and perform cleanup in finally for robustness.

♻️ Duplicate comments (1)
tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (1)

149-156: Nice: local SecureString scope matches earlier guidance

Using a local variable inside the It block avoids scope bleed and aligns with previous feedback.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 4a28a9e and e48b06e.

📒 Files selected for processing (1)
  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (6 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
**/*.ps?(m|d)1

⚙️ CodeRabbit Configuration File

**/*.ps?(m|d)1: # 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:

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: @{}
  • Multi-line: 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 (one per line) with a 1‑line description.
  • OUTPUTS: List each return type (one per line) with a 1‑line description. Must match both [OutputType()] and actual ...

Files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
**/*.[Tt]ests.ps1

⚙️ CodeRabbit Configuration File

**/*.[Tt]ests.ps1: # Tests Guidelines

Core Requirements

  • All public commands, private functions and classes must have unit tests
  • All public commands and class-based resources must have integration tests
  • Use Pester v5 syntax only
  • One Describe block per file matching the tested entity name
  • Test code only inside Describe blocks
  • Assertions only in It blocks
  • Never test Write-Verbose, Write-Debug, or parameter binding behavior
  • Pass all mandatory parameters to avoid prompts

Structure & Scope

  • Public commands: Never use InModuleScope (unless retrieving localized strings)
  • Private functions/class resources: Always use InModuleScope
  • Each scenario = separate Context block
  • Use nested Context blocks for complex scenarios
  • Mocking in BeforeAll (BeforeEach only when required)
  • Setup/teardown in BeforeAll,BeforeEach/AfterAll,AfterEach close to usage

Syntax Rules

  • PascalCase: Describe, Context, It, Should, BeforeAll, BeforeEach, AfterAll, AfterEach
  • It descriptions start with 'Should'
  • Context descriptions start with 'When'
  • Mock variables prefix: 'mock'
  • Prefer -BeTrue/-BeFalse over -Be $true/-Be $false
  • No Should -Not -Throw - invoke commands directly

File Organization

  • Class resources: tests/Unit/Classes/{Name}.Tests.ps1
  • Public commands: tests/Unit/Public/{Name}.Tests.ps1
  • Private functions: tests/Unit/Private/{Name}.Tests.ps1

Data-Driven Tests

  • Define variables in separate BeforeDiscovery for -ForEach (close to usage)
  • -ForEach allowed on Context and It blocks
  • Keep scope close to usage context

Best Practices

  • Assign unused return objects to $null
  • Tested entity must be called from within the It blocks
  • Keep results and assertions in same It block
  • Cover all scenarios and code paths
  • Use BeforeEach and AfterEach sparingly

Files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1

⚙️ CodeRabbit Configuration File

tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1: # Integration Tests Guidelines

Requirements

  • Location Commands: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1
  • Location Resources: tests/Integration/Resources/{ResourceName}.Integration.Tests.ps1
  • No mocking - real environment only
  • Cover all scenarios and code paths
  • Use Get-ComputerName for computer names in CI
  • Avoid ExpectedMessage for Should -Throw assertions
  • Only run integration tests in CI unless explicitly instructed.
  • Call commands with -Force parameter where applicable (avoids prompting).

Required Setup Block

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Suppressing this rule because Script Analyzer does not understand Pester syntax.')]
param ()

BeforeDiscovery {
    try
    {
        if (-not (Get-Module -Name 'DscResource.Test'))
        {
            # Assumes dependencies have been resolved, so if this module is not available, run 'noop' task.
            if (-not (Get-Module -Name 'DscResource.Test' -ListAvailable))
            {
                # Redirect all streams to $null, except the error stream (stream 2)
                & "$PSScriptRoot/../../../build.ps1" -Tasks 'noop' 3>&1 4>&1 5>&1 6>&1 > $null
            }

            # If the dependencies have not been resolved, this will throw an error.
            Import-Module -Name 'DscResource.Test' -Force -ErrorAction 'Stop'
        }
    }
    catch [System.IO.FileNotFoundException]
    {
        throw 'DscResource.Test module dependency not found. Please run ".\build.ps1 -ResolveDependency -Tasks build" first.'
    }
}

BeforeAll {
    $script:dscModuleName = 'SqlServerDsc'

    Import-Module -Name $script:dscModuleName -Force -ErrorAction 'Stop'
}

Files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
🧠 Learnings (5)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
📚 Learning: 2025-08-17T10:13:30.079Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.

Applied to files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-18T13:50:53.789Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.

Applied to files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T10:15:48.194Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.194Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject

Applied to files:

  • tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.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). (4)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test HQRM)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Unit)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Determine DSC Resource Test Requirements)
  • GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
🔇 Additional comments (1)
tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1 (1)

89-93: LGTM: Good defensive setup for the negative test

Ensuring non-existence upfront makes the Should -Throw assertion reliable and idempotent.

Comment thread tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
Comment thread tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
Comment thread tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
Comment thread tests/Integration/Commands/Remove-SqlDscLogin.Integration.Tests.ps1
Copy link
Copy Markdown
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.

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

@johlju
Copy link
Copy Markdown
Member Author

johlju commented Aug 18, 2025

@coderabbitai review

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Aug 18, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
Copy Markdown

@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: 2

♻️ Duplicate comments (4)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (4)

265-272: Prefer specific ParameterSetName attribute before falling back to __AllParameterSets

Current selection may grab __AllParameterSets first and mask per-set differences. Select the specific set first, then fall back.

-            $parameterAttribute = $parameter.Attributes |
-                Where-Object -FilterScript {
-                    $_ -is [System.Management.Automation.ParameterAttribute] -and
-                    ($_.ParameterSetName -eq $ParameterSetName -or $_.ParameterSetName -eq '__AllParameterSets')
-                } |
-                Select-Object -First 1
+            $parameterAttributes = $parameter.Attributes |
+                Where-Object -FilterScript {
+                    $_ -is [System.Management.Automation.ParameterAttribute] -and
+                    ($_.ParameterSetName -eq $ParameterSetName -or $_.ParameterSetName -eq '__AllParameterSets')
+                }
+
+            $parameterAttribute = $parameterAttributes |
+                Where-Object -FilterScript { $_.ParameterSetName -eq $ParameterSetName } |
+                Select-Object -First 1
+
+            if (-not $parameterAttribute)
+            {
+                $parameterAttribute = $parameterAttributes |
+                    Where-Object -FilterScript { $_.ParameterSetName -eq '__AllParameterSets' } |
+                    Select-Object -First 1
+            }

463-471: Compare LoginType consistently (avoid string-vs-enum)

LoginType is an enum in the stub; comparing to 'SqlLogin' is type-mismatched. Compare to the enum or call ToString().

-                $login.LoginType | Should -Be 'SqlLogin'
+                $login.LoginType.ToString() | Should -Be 'SqlLogin'

Alternatively:

$login.LoginType | Should -Be ([Microsoft.SqlServer.Management.Smo.LoginType]::SqlLogin)

487-493: Same enum comparison issue in hashed-login scenario

Align with the change above to prevent brittle comparisons.

-                $login.LoginType | Should -Be 'SqlLogin'
+                $login.LoginType.ToString() | Should -Be 'SqlLogin'

Alternatively:

$login.LoginType | Should -Be ([Microsoft.SqlServer.Management.Smo.LoginType]::SqlLogin)

289-539: Add WhatIf coverage to assert ShouldProcess is honored (no Create when -WhatIf is used)

A -WhatIf scenario guards the ShouldProcess wiring. Recommend adding a context that verifies no Create occurred while the path executes normally.

Add this new context near the other creation tests:

Context 'When running with WhatIf' {
    BeforeAll {
        $script:mockSecurePassword = ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force
    }

    It 'Should not create a SQL login when WhatIf is used' {
        $result = New-SqlDscLogin -ServerObject $script:mockServerObject -Name 'WhatIfLogin' -SqlLogin -SecurePassword $script:mockSecurePassword -PassThru -WhatIf
        $result | Should -Not -BeNullOrEmpty
        $result.MockCreateCalled | Should -BeFalse
        Should -Invoke -CommandName Test-SqlDscIsLogin -Exactly -Times 1 -Scope It
    }
}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between e48b06e and 2ff3719.

📒 Files selected for processing (1)
  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**/*.ps?(m|d)1

⚙️ CodeRabbit Configuration File

**/*.ps?(m|d)1: # 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:

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: @{}
  • Multi-line: 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 (one per line) with a 1‑line description.
  • OUTPUTS: List each return type (one per line) with a 1‑line description. Must match both [OutputType()] and actual ...

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
**/*.[Tt]ests.ps1

⚙️ CodeRabbit Configuration File

**/*.[Tt]ests.ps1: # Tests Guidelines

Core Requirements

  • All public commands, private functions and classes must have unit tests
  • All public commands and class-based resources must have integration tests
  • Use Pester v5 syntax only
  • One Describe block per file matching the tested entity name
  • Test code only inside Describe blocks
  • Assertions only in It blocks
  • Never test Write-Verbose, Write-Debug, or parameter binding behavior
  • Pass all mandatory parameters to avoid prompts

Structure & Scope

  • Public commands: Never use InModuleScope (unless retrieving localized strings)
  • Private functions/class resources: Always use InModuleScope
  • Each scenario = separate Context block
  • Use nested Context blocks for complex scenarios
  • Mocking in BeforeAll (BeforeEach only when required)
  • Setup/teardown in BeforeAll,BeforeEach/AfterAll,AfterEach close to usage

Syntax Rules

  • PascalCase: Describe, Context, It, Should, BeforeAll, BeforeEach, AfterAll, AfterEach
  • It descriptions start with 'Should'
  • Context descriptions start with 'When'
  • Mock variables prefix: 'mock'
  • Prefer -BeTrue/-BeFalse over -Be $true/-Be $false
  • No Should -Not -Throw - invoke commands directly

File Organization

  • Class resources: tests/Unit/Classes/{Name}.Tests.ps1
  • Public commands: tests/Unit/Public/{Name}.Tests.ps1
  • Private functions: tests/Unit/Private/{Name}.Tests.ps1

Data-Driven Tests

  • Define variables in separate BeforeDiscovery for -ForEach (close to usage)
  • -ForEach allowed on Context and It blocks
  • Keep scope close to usage context

Best Practices

  • Assign unused return objects to $null
  • Tested entity must be called from within the It blocks
  • Keep results and assertions in same It block
  • Cover all scenarios and code paths
  • Use BeforeEach and AfterEach sparingly

Files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
🧠 Learnings (18)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
📚 Learning: 2025-08-17T10:13:30.079Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-18T13:50:53.789Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Public command unit tests must include parameter set validation using the provided template/pattern

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Public command unit tests must include tests to validate parameter properties (e.g., Mandatory, ValueFromPipeline)

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/**/*.Tests.ps1 : Do not use Should -Not -Throw; invoke the command directly

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-18T10:44:38.990Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T10:03:59.993Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T10:15:48.194Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.194Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Use localized strings in tests only when necessary, retrieving values from $script:localizedData inside InModuleScope

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Do not test parameter validation

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Each scenario/path should be in Context blocks starting with 'When'; It block descriptions should start with 'Should' and must call the subject; results and assertions stay within the same It; BeforeAll/BeforeEach must not call the subject

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-16T13:22:15.230Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#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:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Use BeforeAll/BeforeEach/AfterAll/AfterEach inside Context, placed near the It blocks using them; duplication across contexts is acceptable; AfterAll can clean up; use BeforeEach/AfterEach sparingly

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Test code must not exist outside of a Describe block

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/**/*.Tests.ps1 : Include the standard unit test setup block (BeforeDiscovery/BeforeAll/AfterAll with module loading and PSDefaultParameterValues) before the Describe block

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/**/*.ps1 : Each test file must contain exactly one Describe block named after the subject (public command, private function, or resource)

Applied to files:

  • tests/Unit/Public/New-SqlDscLogin.Tests.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). (4)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Determine DSC Resource Test Requirements)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test Unit)
  • GitHub Check: dsccommunity.SqlServerDsc (Quality Test and Unit Test HQRM)
  • GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
🔇 Additional comments (2)
tests/Unit/Public/New-SqlDscLogin.Tests.ps1 (2)

5-25: Solid bootstrap of DscResource.Test with fail-fast import

Good defensive fallback to build script and -ErrorAction Stop on import. This follows the repo pattern and improves reliability.


27-39: Good module load and SMO stub wiring

Import with -ErrorAction Stop and explicit Add-Type for SMO stubs are spot on for deterministic tests.

Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Comment thread tests/Unit/Public/New-SqlDscLogin.Tests.ps1
Copy link
Copy Markdown

@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: 1

♻️ Duplicate comments (1)
azure-pipelines.yml (1)

95-99: Normalize PR target branch by stripping refs/heads/ and using $(defaultBranch) fallback.

SYSTEM_PULLREQUEST_TARGETBRANCH often includes a refs/heads/ prefix. Prefixing origin/ without stripping can produce invalid refs (e.g., origin/refs/heads/main). Use $(defaultBranch) as the fallback, not a hardcoded name.

Apply:

-                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
-                    $targetBranch = "origin/$env:SYSTEM_PULLREQUEST_TARGETBRANCH"
-                } else {
-                    $targetBranch = "origin/$(defaultBranch)"
-                }
+                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
+                    $targetBranchName = $env:SYSTEM_PULLREQUEST_TARGETBRANCH -replace '^refs/heads/', ''
+                    $targetBranch = "origin/$targetBranchName"
+                } else {
+                    $targetBranch = "origin/$(defaultBranch)"
+                }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 2ff3719 and 532bc16.

📒 Files selected for processing (2)
  • CHANGELOG.md (2 hunks)
  • azure-pipelines.yml (7 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
CHANGELOG.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Always update the Unreleased section in CHANGELOG.md using Keep a Changelog format with concrete release notes for changes (new/modified commands, functions, resources)

Files:

  • CHANGELOG.md

⚙️ CodeRabbit Configuration File

CHANGELOG.md: # Changelog Guidelines

  • Always update the Unreleased section in CHANGELOG.md
  • Use Keep a Changelog format
  • Describe main changes as concise release notes
  • Reference issues using format #<issue_number>
  • No empty lines between list items in same section
  • Do not add item if there are already an existing item for the same change

Files:

  • CHANGELOG.md
**/*.md

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Markdown: wrap lines at word boundaries when exceeding 80 characters; use 2 spaces for indentation

Files:

  • CHANGELOG.md

⚙️ CodeRabbit Configuration File

**/*.md: # Markdown Style Guidelines

  • Wrap lines at word boundaries when over 80 characters
  • Use 2 spaces for indentation
  • Use '1.' for all items in ordered lists (1/1/1 numbering style)
  • Surround fenced code blocks with blank lines

Files:

  • CHANGELOG.md
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • CHANGELOG.md
  • azure-pipelines.yml
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
🧠 Learnings (12)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns

Applied to files:

  • CHANGELOG.md
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/Public/*.ps1 : Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • CHANGELOG.md
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/Private/*.ps1 : Private functions must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • CHANGELOG.md
📚 Learning: 2025-08-17T10:48:15.384Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/suffix.ps1:24-24
Timestamp: 2025-08-17T10:48:15.384Z
Learning: In source/suffix.ps1, the Write-Verbose message in the catch block for Import-SqlDscPreferredModule does not need localization because the exception message from Import-SqlDscPreferredModule is already localized by that command, making it an edge case exception to the localization guidelines.

Applied to files:

  • CHANGELOG.md
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • CHANGELOG.md
  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • CHANGELOG.md
  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
🧬 Code Graph Analysis (1)
CHANGELOG.md (1)
tests/Unit/Stubs/SMO.cs (1)
  • Login (354-484)
⏰ 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)
azure-pipelines.yml (1)

285-289: Good: New-SqlDscLogin integration test wired into Group 2.

The new command’s test is correctly added alongside related login commands in the SQL Server Commands stage.

CHANGELOG.md (2)

12-14: Changelog fix entry reads clearly and matches the pipeline change.

The description concisely explains the boolean condition correction for DSC resource integration test gating.


43-49: Changelog entry for New-SqlDscLogin looks complete and aligned with module conventions.

Covers purpose, supported login types, and parameter set constraints. Nicely scoped.

Comment thread azure-pipelines.yml Outdated
Copy link
Copy Markdown

@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: 2

♻️ Duplicate comments (1)
azure-pipelines.yml (1)

95-99: Normalize PR target branch: strip refs/heads/ before prefixing with origin/

SYSTEM_PULLREQUEST_TARGETBRANCH often includes a refs/heads/ prefix. Without stripping, the computed ref becomes origin/refs/heads/, which may not match what Test-ShouldRunDscResourceIntegrationTests.ps1 expects. Also prefer $(defaultBranch) for fallback (you already do).

Apply this diff:

-                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
-                    $targetBranch = "origin/$env:SYSTEM_PULLREQUEST_TARGETBRANCH"
-                } else {
-                    $targetBranch = "origin/$(defaultBranch)"
-                }
+                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
+                    $targetBranchName = $env:SYSTEM_PULLREQUEST_TARGETBRANCH -replace '^refs/heads/', ''
+                    $targetBranch = "origin/$targetBranchName"
+                } else {
+                    $targetBranch = "origin/$(defaultBranch)"
+                }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 532bc16 and bc9da38.

📒 Files selected for processing (1)
  • azure-pipelines.yml (8 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
⏰ 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). (2)
  • GitHub Check: PSScriptAnalyzer
  • GitHub Check: PSScriptAnalyzer
🔇 Additional comments (2)
azure-pipelines.yml (2)

107-109: LGTM: helpful debug echo before exporting output variable

Printing the computed ShouldRunDscResourceIntegrationTests value aids troubleshooting and does not affect behavior.


311-311: New-SqlDscLogin integration tests correctly added

All verification steps passed—no further changes required.

Comment thread azure-pipelines.yml Outdated
Comment thread azure-pipelines.yml Outdated
Copy link
Copy Markdown

@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: 1

♻️ Duplicate comments (2)
azure-pipelines.yml (2)

95-99: Strip refs/heads/ from PR target branch before prefixing with origin/

SYSTEM_PULLREQUEST_TARGETBRANCH often includes refs/heads/*. Using it verbatim yields origin/refs/heads/, which most git commands don’t accept. Strip the prefix before composing targetBranch. Also keep the fallback to $(defaultBranch).

-                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
-                    $targetBranch = "origin/$env:SYSTEM_PULLREQUEST_TARGETBRANCH"
-                } else {
-                    $targetBranch = "origin/$(defaultBranch)"
-                }
+                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
+                    $targetBranchName = $env:SYSTEM_PULLREQUEST_TARGETBRANCH -replace '^refs/heads/', ''
+                    $targetBranch = "origin/$targetBranchName"
+                } else {
+                    $targetBranch = "origin/$(defaultBranch)"
+                }

120-142: Gate the debug job on System.Debug to reduce noise

This always-on diagnostic job adds noise and time to normal runs. Gate it on System.Debug so it only runs when troubleshooting.

       - job: Debug_DSC_Resource_Test_Flag
         displayName: 'Debug: DSC Resource Test Flag'
         dependsOn: Determine_DSC_Resource_Test_Requirements
+        condition: and(succeeded(), eq(lower(variables['System.Debug']), 'true'))
         pool:
           vmImage: 'windows-latest'
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between b1fa2e4 and 23e40bb.

📒 Files selected for processing (1)
  • azure-pipelines.yml (8 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
⏰ 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 (2)
azure-pipelines.yml (2)

107-118: Good: normalize ShouldRun to lowercase and export both long and short outputs

Lowercasing once at the source avoids brittle case handling in YAML expressions and across stages. The dual outputs (long + short alias) improve readability.


317-319: LGTM: added New-SqlDscLogin integration tests to Commands group

Correct path and placement (Group 2) alongside related login commands. This satisfies the guideline to wire new public command integration tests into CI.

Comment thread azure-pipelines.yml
Copy link
Copy Markdown

@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

♻️ Duplicate comments (2)
azure-pipelines.yml (2)

95-98: Normalize SYSTEM_PULLREQUEST_TARGETBRANCH (strip refs/heads/) and keep defaultBranch fallback

Current logic can yield origin/refs/heads/, which breaks git diff. Strip the prefix before composing the remote ref. This mirrors earlier guidance.

-                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
-                    $targetBranch = "origin/$env:SYSTEM_PULLREQUEST_TARGETBRANCH"
-                } else {
-                    $targetBranch = "origin/$(defaultBranch)"
-                }
+                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
+                    $targetBranchName = $env:SYSTEM_PULLREQUEST_TARGETBRANCH -replace '^refs/heads/', ''
+                    $targetBranch = "origin/$targetBranchName"
+                } else {
+                    $targetBranch = "origin/$(defaultBranch)"
+                }

118-137: Gate the debug job on System.Debug and fix misleading comment

Run the debug job only when diagnostics are requested; also the comment about “both lowercase” is inaccurate and may mislead future edits.

       - job: Debug_DSC_Resource_Test_Flag
         displayName: 'Debug: DSC Resource Test Flag'
         dependsOn: Determine_DSC_Resource_Test_Requirements
+        condition: and(succeeded(), eq(lower(variables['System.Debug']), 'true'))
         pool:
           vmImage: 'windows-latest'
         variables:
-          # Use the correct output format: step_name.variable_name (both lowercase)
+          # Use the correct output format: step_name.variable_name (match actual casing)
           ShouldRun: $[ dependencies.Determine_DSC_Resource_Test_Requirements.outputs['determineDscResourceTests.ShouldRunDscResourceIntegrationTests'] ]
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 23e40bb and e79c361.

📒 Files selected for processing (2)
  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1 (2 hunks)
  • azure-pipelines.yml (8 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (15)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/{Public,Private,Classes}/*.ps1 : Use PascalCase for function names and parameters in public commands, private functions, and class-based resources

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T10:15:48.194Z
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: tests/Unit/Public/Remove-SqlDscLogin.Tests.ps1:36-39
Timestamp: 2025-08-17T10:15:48.194Z
Learning: Public command unit tests guideline: Never use InModuleScope unless accessing localized strings from $script:localizedData. PSDefaultParameterValues for InModuleScope should be kept in public command tests to support localized string retrieval when necessary.

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/Public/*.ps1 : Each public PowerShell command must be in its own script file named exactly as the command and located in source/Public

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/{Public,Private}/*.ps1 : Public commands and private functions must be advanced functions and include [CmdletBinding()]

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/{Public,Private}/*.ps1 : Public command and private function names must follow Verb-Noun format and use PowerShell approved verbs

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/Public/*.ps1 : Public commands must localize Write-Debug/Verbose/Error/Warning and other messages using keys from source/en-US/SqlServerDsc.strings.psd1; keys prefixed with function name using underscores; data available as $script:localizedData

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/Private/*.ps1 : Each private function must be in its own script file named exactly as the function and located in source/Private (even if used by a single public command)

Applied to files:

  • .build/Test-ShouldRunDscResourceIntegrationTests.ps1
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
⏰ 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)
azure-pipelines.yml (1)

314-314: New-SqlDscLogin integration test added in the correct group/order

Good placement alongside related login commands. This aligns with the guidelines for Commands integration tests.

Comment thread .build/Test-ShouldRunDscResourceIntegrationTests.ps1
Comment thread .build/Test-ShouldRunDscResourceIntegrationTests.ps1
Comment thread azure-pipelines.yml
Comment thread azure-pipelines.yml Outdated
johlju added 2 commits August 18, 2025 22:42
… to use ShouldRunDscResourceIntegrationTests output variable
Copy link
Copy Markdown

@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: 1> [!CAUTION]

Some comments are outside the diff and can’t be posted inline due to platform limits.

🔭 Outside diff range comments (1)
azure-pipelines.yml (1)

444-451: Fix stage condition: incorrect dependency scope and mismatched parentheses

  • At stage-level, use stageDependencies and include the job name when accessing outputs. dependencies here won’t resolve across stages.
  • There’s one extra closing parenthesis, which will break the expression.

Apply this diff:

   condition: |
-      and(
-        succeeded(),
-        eq(dependencies.Quality_Test_and_Unit_Test.outputs['Determine_DSC_Resource_Test_Requirements.determineDscResourceTests.ShouldRunDscResourceIntegrationTests'], 'true'))
-      )
+      and(
+        succeeded(),
+        eq(stageDependencies.Quality_Test_and_Unit_Test.Determine_DSC_Resource_Test_Requirements.outputs['determineDscResourceTests.ShouldRunDscResourceIntegrationTests'], 'true')
+      )
♻️ Duplicate comments (1)
azure-pipelines.yml (1)

95-99: Normalize PR target branch (strip refs/heads) and use defaultBranch fallback

As previously noted, SYSTEM_PULLREQUEST_TARGETBRANCH often includes a refs/heads/ prefix. Without stripping it, BaseBranch comparisons may fail.

Apply this diff:

-                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
-                    $targetBranch = "origin/$env:SYSTEM_PULLREQUEST_TARGETBRANCH"
-                } else {
-                    $targetBranch = "origin/$(defaultBranch)"
-                }
+                if ($env:SYSTEM_PULLREQUEST_TARGETBRANCH) {
+                    $targetBranchName = $env:SYSTEM_PULLREQUEST_TARGETBRANCH -replace '^refs/heads/', ''
+                    $targetBranch = "origin/$targetBranchName"
+                } else {
+                    $targetBranch = "origin/$(defaultBranch)"
+                }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

💡 Knowledge Base configuration:

  • Jira integration is disabled
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between e79c361 and c068476.

📒 Files selected for processing (1)
  • azure-pipelines.yml (8 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
azure-pipelines.yml

📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)

Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Files:

  • azure-pipelines.yml
**

⚙️ CodeRabbit Configuration File

**: # DSC Community Guidelines

Terminology

  • Command: Public command
  • Function: Private function
  • Resource: DSC class-based resource

Build & Test Workflow

  • Run project scripts in PowerShell from repository root
  • Build after source changes: .\build.ps1 -Tasks build
  • Test workflow: Build → Invoke-Pester -Path @('<test paths>') -Output Detailed
  • New session required after class changes

File Organization

  • Public commands: source/Public/{CommandName}.ps1
  • Private functions: source/Private/{FunctionName}.ps1
  • Unit tests: tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
  • Integration tests: tests/Integration/Commands/{CommandName}.Integration.Tests.ps1

Requirements

  • Always update CHANGELOG.md Unreleased section
  • Localize all strings using string keys
  • Check DscResource.Common before creating private functions
  • Separate reusable logic into private functions
  • Add unit tests for all commands/functions/resources
  • Add integration tests for all public commands and resources

Files:

  • azure-pipelines.yml
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to source/en-US/SqlServerDsc.strings.psd1 : All localized strings for public commands and private functions must be added to source/en-US/SqlServerDsc.strings.psd1 following existing key patterns
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
Learnt from: johlju
PR: dsccommunity/SqlServerDsc#2132
File: tests/Unit/Public/New-SqlDscLogin.Tests.ps1:0-0
Timestamp: 2025-08-18T13:50:53.789Z
Learning: In SqlServerDsc unit tests, SMO stub objects can be used to verify method calls like Create() on Login objects by adding mock verifications with Should -Invoke, providing more robust testing than just checking for no exceptions.
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to azure-pipelines.yml : Add each public command integration test script to a group within the Integration_Test_Commands_SqlServer stage in ./azure-pipelines.yml, choosing the appropriate group

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests must exist for all public commands, not mock any commands, be placed at tests/Integration/Commands, and be named <Command>.Integration.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Public/*.Tests.ps1 : Unit tests for public commands must be placed in tests/Unit/Public and named <Command>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Include the standard integration test setup block (BeforeDiscovery/BeforeAll with module loading) before the first Describe block

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Classes/*.Tests.ps1 : Unit tests for class-based resources must be placed in tests/Unit/Classes and named <Resource>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Unit/Private/*.Tests.ps1 : Unit tests for private functions must be placed in tests/Unit/Private and named <Function>.Tests.ps1

Applied to files:

  • azure-pipelines.yml
📚 Learning: 2025-08-17T09:48:55.756Z
Learnt from: CR
PR: dsccommunity/SqlServerDsc#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-17T09:48:55.756Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : In CI, integration tests must use Get-ComputerName when the computer name is needed

Applied to files:

  • azure-pipelines.yml
⏰ 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). (2)
  • GitHub Check: PSScriptAnalyzer
  • GitHub Check: PSScriptAnalyzer
🔇 Additional comments (2)
azure-pipelines.yml (2)

107-116: Good: output normalization for gating is robust

Lowercasing ShouldRunDscResourceIntegrationTests before exporting avoids brittle case issues in conditions. No changes needed here.


293-293: Correct: Added New-SqlDscLogin integration test to Commands group

The new public command integration test is properly added under Integration_Test_Commands_SqlServer (Group 2), matching the project guidelines and the retrieved learning.

Comment thread azure-pipelines.yml Outdated
Copy link
Copy Markdown
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:

Reviewed 1 of 2 files at r21, 1 of 2 files at r25, 1 of 1 files at r27, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @johlju)

@johlju johlju merged commit 4881d27 into dsccommunity:main Aug 19, 2025
44 checks passed
@johlju johlju deleted the f/command-new-sqldsclogin branch August 19, 2025 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs review The pull request needs a code review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant