You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository is an Ansible Collection for managing SQL Server using the PowerShell dbatools module. Modules are implemented in PowerShell (*.ps1) with small Python documentation shims (*.py). The collection targets cross-platform control nodes (Linux/macOS/Windows) but talks to SQL Server (Windows-style paths, SMO) on Windows servers.
4
+
5
+
Primary languages & tools
6
+
7
+
- PowerShell (modules under `plugins/modules/*.ps1` and module_utils/*.psm1)
8
+
- Python (module documentation files under `plugins/modules/*.py`)
9
+
- YAML (integration tests under `tests/integration/targets/**`)
10
+
- dbatools PowerShell module (runtime dependency)
11
+
12
+
High-level guidance for Copilot edits/suggestions
13
+
14
+
- Preserve idempotency. Modules must set `module.Result.changed` only when actual server-side state changes. Prefer reading server state with dbatools `Get-*` functions and comparing to the desired state.
15
+
- Prefer using dbatools functions (Get-DbaAgentJob, Set-DbaAgentJob, Get-DbaAgentJobOutputFile, Set-DbaAgentJobOutputFile, etc.) rather than manipulating SMO internals directly.
16
+
- Prefer using PSDefaultParameterValues when possible to avoid redundant parameter parsing.
17
+
- Use the shared helpers in `plugins/module_utils/_SqlServerUtils.psm1` (e.g., `Get-LowlyDbaSqlServerAuthSpec`, `Get-SqlCredential`, `ConvertTo-SerializableObject`) instead of reimplementing them.
18
+
- For cross-platform code running on Linux control nodes: avoid using Windows-only path APIs when comparing paths returned by SQL Server tools. Either let the server report the canonical value and compare server-before vs server-after, or perform simple string normalization that is safe on all hosts.
19
+
- Respect `check_mode` by not performing actual changes and by returning what would be changed.
20
+
- When calling dbatools setters that mutate SMO state, prefer to re-read the server-reported value (Get-*) and use that for the module `data` return and change detection. If SMO latency is a concern, implement a small retry (few attempts with short sleeps) when reading back the value — do not add long sleeps in tests.
21
+
- When serializing SMO objects for `module.Result.data`, use `ConvertTo-SerializableObject` to avoid recursion and platform-specific type issues.
22
+
23
+
Code style & constraints
24
+
25
+
- Keep PowerShell code compatible with PowerShell Core and Windows PowerShell where practical.
26
+
- Use Ansible's AnsibleModule patterns: module creation via `[Ansible.Basic.AnsibleModule]::Create($args, $spec, @(Get-LowlyDbaSqlServerAuthSpec))` and `ExitJson()` / `FailJson()` for outputs.
27
+
- Avoid printing or writing secrets; mark password options `no_log` in specs.
28
+
29
+
Testing guidance
30
+
31
+
- Integration tests live in `tests/integration/targets/*`. Tests expect a Windows SQL Server target (CI uses ephemeral VMs/containers). Running tests locally requires a reachable SQL Server instance and credentials in `tests/integration/integration_config.yml`.
32
+
- Add/adjust unit tests for any helper logic in `plugins/module_utils` if you change normalization/serialization.
33
+
- Keep tests deterministic: avoid brittle timing assumptions; use short retries for SMO refresh instead of fixed long sleeps.
34
+
35
+
Documentation
36
+
37
+
- Create antsibull changelog frament files under `changelogs/fragments/` for any changes that affect module behavior or parameters.
38
+
39
+
PR reviewer checklist (help Copilot produce PRs that pass CI)
40
+
41
+
- Ensure modules are idempotent and `changed` is correct.
- Prefer small, well-tested changes to helper functions. Centralized fixes in `module_utils` avoid repeating logic across many modules.
56
+
- For path comparisons and idempotency: prefer server-side verification (Get after Set) or minimal normalization, rather than heavy OS-specific path APIs.
57
+
58
+
Contact
59
+
60
+
If you need clarification about how a module is expected to behave, read the module's docstring in the Python shim (`plugins/modules/*.py`) and the corresponding integration tests under `tests/integration/targets/*` to see expected inputs/outputs.
0 commit comments