Docs - Point CI documentation at ci-azure instead of AppVeyor (#10521)

Author: andreasjordan

.github/CODEOWNERS

@@ -5,4 +5,6 @@
 /.github/CODEOWNERS @potatoqualitee @niphlod @andreasjordan
 /.github/copilot-instructions.md @potatoqualitee @niphlod @andreasjordan
 /.github/dependabot.yml @potatoqualitee @niphlod @andreasjordan
-/appveyor.yml @potatoqualitee @niphlod @andreasjordan
+/tests/appveyor.*.ps1 @potatoqualitee @niphlod @andreasjordan
+/tests/gha.shim.ps1 @potatoqualitee @niphlod @andreasjordan
+/tests/pester.groups.ps1 @potatoqualitee @niphlod @andreasjordan

.github/CONTRIBUTING-TESTING.md

@@ -446,18 +446,19 @@ git commit -m "Fix login handling (do Get-DbaLogin, Set-DbaLogin)"
 git commit -m "Update comments [skip ci]"
 ```
 
-### AppVeyor Build Matrix
+### CI Build Matrix
 
-The CI runs tests across multiple scenarios in parallel:
+The `ci-azure` workflow runs tests across multiple scenarios in parallel on self-hosted Azure runners:
 
 ```yaml
-# From appveyor.yml
+# From .github/workflows/ci-azure.yml
 matrix:
-  - scenario: SINGLE (split into 3 parts for speed)
-  - scenario: MULTI
-  - scenario: COPY
-  - scenario: HADR
-  - scenario: RESTART
+  - scenario: SINGLE (split into 5 parts for speed, sql2022)
+  - scenario: MULTI (sql2022 + sql2017)
+  - scenario: COPY (sql2017 + sql2022)
+  - scenario: HADR (sql2019)
+  - scenario: RESTART (sql2019)
+  - scenario: default (no instance)
 ```
 
 ---

.github/copilot-instructions.md

@@ -223,7 +223,7 @@ dbatools/
 ### Configuration Files
 - **CLAUDE.md** - Single source for repository-wide PowerShell style and workflow conventions
 - **tests/CLAUDE.md** - Single source for ongoing test policy and Pester 6 rules
-- **appveyor.yml** - AppVeyor CI (Windows testing with SQL Server 2008-2017)
+- **.github/workflows/ci-azure.yml** - the test suite of record (Windows testing on self-hosted Azure runners, SQL Server 2017/2019/2022)
 - **.github/workflows/integration-tests.yml** - GitHub Actions (cross-platform testing)
 
 ## CI/CD Validation Pipeline
@@ -249,14 +249,17 @@ dbatools/
 4. Installs SqlPackage
 5. Runs platform-specific test suite (`.github/scripts/gh-actions.ps1` or `gh-winactions.ps1`)
 
-### AppVeyor CI (appveyor.yml)
+### ci-azure (.github/workflows/ci-azure.yml)
 
-Runs on every push, 5 scenarios in parallel:
-- **2008R2:** SQL Server 2008 R2 Express
-- **2016:** SQL Server 2016 Developer
-- **2016_2017:** SQL Server 2016 + 2017 (for Copy-* commands)
-- **service_restarts:** Service restart testing
-- **default:** 2008 R2 + 2016 combo
+The test suite of record. Runs on pushes to `development` and on PRs targeting it, on self-hosted Azure VMSS runners, with these scenarios in parallel:
+- **SINGLE:** SQL Server 2022, split into five parts
+- **MULTI:** SQL Server 2022 + 2017, for tests needing two instances
+- **COPY:** SQL Server 2017 + 2022, for `Copy-*` commands
+- **HADR:** SQL Server 2019 with availability groups configured
+- **RESTART:** SQL Server 2019, for service restart testing
+- **default:** no instance, for tests that don't need a running server
+
+It drives the `tests/appveyor.*.ps1` build scripts, which kept their name when the project moved off AppVeyor; `tests/gha.shim.ps1` supplies the AppVeyor build API they call. There is no `appveyor.yml` in the repository.
 
 **Magic commit commands:**
 - Add `(do Get-DbaFoo)` to commit message to run only `Get-DbaFoo` tests

CONTRIBUTING.md

@@ -18,7 +18,7 @@ As of 2023 the project has been restructured but we also have a few different re
 
 1. [dataplat/appveyor-lab](https://github.com/dataplat/appveyor-lab)
 
-    We use Appveyor for running the Pester tests for each function. We have this repository to store content that is used in our tests. This keeps the current repository clean from excess files just for testing. **Maintainers will determine if tests require files be placed in this repository**.
+    We have this repository to store content that is used in our tests. The name predates the move off AppVeyor; CI still clones it for test fixtures. This keeps the current repository clean from excess files just for testing. **Maintainers will determine if tests require files be placed in this repository**.
 
 1. [dataplat/docs](https://github.com/dataplat/docs)
 
@@ -128,7 +128,7 @@ A few notes:
 
 ## Pester 🧪
 
-Our project uses [Pester](https://pester.dev) for our testing framework. Appveyor runs a matrix of environments that test against various versions of SQL Server. We do have some commands that cannot be tested easily but the majority we use Pester to ensure the code behaves properly. Appveyor runs these tests for each-and-every commit in our repository.
+Our project uses [Pester](https://pester.dev) for our testing framework. CI runs a matrix of environments that test against various versions of SQL Server. We do have some commands that cannot be tested easily but the majority we use Pester to ensure the code behaves properly. CI runs these tests for each-and-every commit in our repository.
 
 We strive to have the Pester tests where any user can pull the project and run the same test in their environment (on a test lab of course or in our Docker image).
 
@@ -146,34 +146,33 @@ Tests make sure a "contract" is made between the code and its behavior: once a t
 
 You can inspect/copy/cannibalize existing tests. You'll see that every test file is named with a simple convention `Verb-Noun*.Tests.ps1`, and this is required by [Pester](https://GitHub.com/pester/Pester), which is the de-facto standard for running tests in PowerShell.
 
-## AppVeyor Environment
+## CI Environment
 
-AppVeyor is hooked up to test any commit, including PRs. Each commit triggers several builds, each referred to as a "scenario". We have the scenarios setup where the dbatools log is published as an artifact should you need to view why test are failing.
+CI is hooked up to test any commit, including PRs. The suite of record is the `ci-azure` GitHub Actions workflow (`.github/workflows/ci-azure.yml`), which runs on self-hosted Azure VMSS runners. Each commit triggers several builds, each referred to as a "scenario". We have the scenarios setup where the dbatools log is published as an artifact should you need to view why test are failing.
 
-- SINGLE: a server with a single SQL Server 2022 instance available ($TestConfig.InstanceSingle)
+- SINGLE: a server with a single SQL Server 2022 instance available ($TestConfig.InstanceSingle), split into five parts that run in parallel
 - MULTI: a server with two instances (SQL Server 2022 and SQL Server 2017) available for tests that need multiple instances ($TestConfig.InstanceMulti1 and $TestConfig.InstanceMulti2)
 - COPY: a server with two instances (SQL Server 2017 and SQL Server 2022) available for tests that need multiple instances ($TestConfig.InstanceCopy1 and $TestConfig.InstanceCopy2)
-- HADR: a single SQL Server 2022 instance available with Hadr configured ($TestConfig.InstanceHadr)
-- RESTART: used to test service restarts ($TestConfig.InstanceRestart)
-- 2008R2SP2Express: a server with a single SQL Server 2008 R2 Express Edition available to test some commands against an old version ($TestConfig.InstanceSingle)
+- HADR: a single SQL Server 2019 instance available with Hadr configured ($TestConfig.InstanceHadr)
+- RESTART: a single SQL Server 2019 instance used to test service restarts ($TestConfig.InstanceRestart)
 - default: a server with no instance for all tests that don't need a running instance
 
-Builds are split among "scenario"(s) because not every test requires everything to be up and running, and resources on AppVeyor are constrained.
-AppVeyor is set up to recognize what "scenario" is required by your test, simply inspecting for the presence of $TestConfig.Instance*.
+Builds are split among "scenario"(s) because not every test requires everything to be up and running, and runner capacity is constrained.
+CI is set up to recognize what "scenario" is required by your test, simply inspecting for the presence of $TestConfig.Instance*.
 
 Most PRs will target `public/*.ps1` files to add functionality or resolve bugs.
 Our test runner will try and figure out what tests needs to be run based on the files modified in the PR, plus all the dependencies.
 
-If the automatic detection doesn't work, and you don't want to wait for the entire test suite to run (i.e. you need to run only `Get-DbaFoo` on AppVeyor), you can use a **_magic command_** within the commit message, namely `(do Get-DbaFoo)` . This will run only test files within the test folder matching this mask `tests\*Get-DbaFoo*.Tests.ps1`.
+If the automatic detection doesn't work, and you don't want to wait for the entire test suite to run (i.e. you need to run only `Get-DbaFoo` in CI), you can use a **_magic command_** within the commit message, namely `(do Get-DbaFoo)` . This will run only test files within the test folder matching this mask `tests\*Get-DbaFoo*.Tests.ps1`.
 
-<!-- TODO: how to run your own AppVeyor before pushing a PR -->
+The build scripts CI drives are the `tests/appveyor.*.ps1` files. They keep that name for historical reasons - the harness was carried over unchanged when the project moved off AppVeyor, and `tests/gha.shim.ps1` supplies the AppVeyor build API it still calls.
 
 ## Codecov
 
 We utilize Codecov as many other PowerShell community projects are doing. You can see those coverage reports directly on Codecov site for our project.
 
 [Codecov - dataplat/dbatools](https://app.codecov.io/gh/dataplat/dbatools/tree/development)
 
-This system allows us to see the percentage of the coverage for our tests. A rough goal is getting as close to 80% coverage, some commands we have that are just not achievable due to various limitations. As part of our test framework that runs on Appveyor we upload a coverage file to Codecov so it stays current.
+This system allows us to see the percentage of the coverage for our tests. A rough goal is getting as close to 80% coverage, some commands we have that are just not achievable due to various limitations. As part of our test framework that runs in CI we upload a coverage file to Codecov so it stays current.
 
 If you want to start contributing new tests, choose the ones with no coverage. You can also inspect functions with low coverage and improve existing tests. [See improving test](https://dbatools.io/improving-tests/).

tests/CLAUDE.md

@@ -4,7 +4,7 @@ This guide provides the ongoing standards and best practices for running and wri
 
 **This file is the single source for test policy.** General PowerShell style remains authoritative in the repository's root `CLAUDE.md` and applies to test files too.
 
-## Local (not appveyor) Testing Setup
+## Local (not CI) Testing Setup
 
 To test commands locally during development:
 
@@ -34,7 +34,7 @@ This allows you to manually test commands against actual SQL Server instances be
 
 ## CHOOSING A TEST INSTANCE
 
-`$TestConfig` exposes several SQL Server instances, defined in `private/testing/Get-TestConfig.ps1`. The choice is not cosmetic: `pester.groups.ps1` autodetects which `$TestConfig.Instance*` variable a test file references and assigns the file to that AppVeyor scenario. **Always pick the lightest instance that can demonstrate the behaviour** - reaching for a heavier one moves the test into a scarcer, slower scenario for no benefit.
+`$TestConfig` exposes several SQL Server instances, defined in `private/testing/Get-TestConfig.ps1`. The choice is not cosmetic: `pester.groups.ps1` autodetects which `$TestConfig.Instance*` variable a test file references and assigns the file to that CI scenario. **Always pick the lightest instance that can demonstrate the behaviour** - reaching for a heavier one moves the test into a scarcer, slower scenario for no benefit.
 
 | Instance | Use it for | Scenario |
 |---|---|---|
@@ -53,7 +53,7 @@ Get-TestInstanceUsage | Group-Object -Property InstanceList -NoElement | Sort-Ob
 
 Two consequences worth knowing before you write the test:
 
-- **Only `InstanceSingle`, `InstanceMulti1` and `InstanceMulti2` exist on GitHub Actions.** A test written against `InstanceCopy*`, `InstanceHadr` or `InstanceRestart` runs on AppVeyor only. For new or changed command behavior, the required real-boundary coverage must also run on GitHub Actions or an Azure test runner; provision the needed boundary instead of omitting the regression test.
+- **Every scenario runs on the self-hosted Azure runners** driven by `.github/workflows/ci-azure.yml`, so `InstanceCopy*`, `InstanceHadr` and `InstanceRestart` all get exercised there. The container-based `integration-tests.yml` workflow is narrower: only `InstanceSingle`, `InstanceMulti1` and `InstanceMulti2` exist on it. For new or changed command behavior, the required real-boundary coverage must run on one of these; provision the needed boundary instead of omitting the regression test.
 - **`InstanceRestart` tests share machine state.** They run in file order within a `Describe`, and one test's leftovers become the next test's fixture. If a test mutates machine state that `AfterAll` cannot reliably undo - archived certificates, service accounts, registry values - restore it in a `try`/`finally` inside the `It` itself.
 
 ## TESTING FOR WARNINGS