afv-library/skills/dx-devops-test-pipeline-configure/references/configuring-test-provider.md
2026-06-26 17:15:29 +00:00

81 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Mode A — Configure a Test Provider
Configures an *Available* (not-yet-configured) test provider on a DevOps Center pipeline, making its test suites available for assignment to pipeline stages.
**Confirmation required:** Yes — explicit confirmation before the provider is configured.
## Inputs
| Variable | Source |
|---|---|
| `doce-org-alias` | Prerequisite 1 |
| `pipelineId` | Prerequisite 4 (pipeline selection) |
| `testProviderId` | Resolved by fetching the pipeline's test providers (Step 1 below) |
Prerequisite 5 (stage) is **not** required — providers are configured at the pipeline level.
---
## Step 1 — Fetch test providers to resolve the provider ID
```bash
sf api request rest \
"/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/testProviders?status=all" \
--target-org <doce-org-alias>
```
Each provider entry includes `testProviderId`, `testProviderName`, and a status (Configured vs. Available). Present a short summary grouped by status:
```text
Test providers for <pipelineName>:
✓ Configured:
- Code Analyzer (63 suites)
- Apex Unit Tests (5 suites)
Available (not yet configured):
- Flow Tests
```
- **Only an Available provider can be configured.** If the pipeline has no available providers, report that and stop — do NOT fabricate a provider or ID.
### If the named provider is already Configured
Do **not** present the confirmation gate and do **not** POST to the configure endpoint (Steps 23) — that would create a duplicate `DevopsPipelineTestProvider`. Instead:
1. State plainly that the provider is already configured, including its synced suite count and last-sync time if returned (e.g. *"Flow Tests is already configured on `<pipelineName>` with 3 suites synced (last sync 2026-06-23)."*).
2. Diagnose the user's actual goal and redirect **by name**:
- If the user says the provider's **suites don't appear when assigning tests to a stage**, this is a **stage-assignment gap, not a provider-configuration gap** — the suites already exist at the pipeline level; they just need to be linked to the stage. Redirect to **`dx-devops-test-suite-assignments-configure`**.
- If the user expects **newly created suites** that aren't yet synced, use **Mode B — Sync a configured provider** (`references/syncing-test-providers.md`) to pull them in.
3. Do not loop back to configuring — finish cleanly after the explanation and redirect.
## Step 2 — Confirmation gate
**Required — do not call the API before the user confirms.**
> "I'll configure `<testProviderName>` on the `<pipelineName>` pipeline. This will make its suites available for assignment to stages. Confirm?"
Do not proceed until the user gives an affirmative response.
## Step 3 — Configure the provider
On confirmation, call the configure endpoint with the provider ID:
```bash
sf api request rest \
"/services/data/v67.0/connect/devops/pipeline/<pipelineId>/testProvider" \
--method POST \
--body '{"testProviderId": "<testProviderId>"}' \
--target-org <doce-org-alias>
```
## On success
> "Provider `<testProviderName>` is now configured on the `<pipelineName>` pipeline. Its suites are available for assignment to stages."
Newly configured suites can then be assigned to stages with `dx-devops-test-suite-assignments-configure`.
---
See `references/gotchas.md` for the duplicate-provider trap and `references/error-handling.md` for status-code responses.