dx-devops-test-pipeline-configure
installsforks
How to install dx-devops-test-pipeline-configure?
forcedotcom/sf-skills/dx-devops-test-pipeline-configure
$npx -y skills add forcedotcom/sf-skills --skill dx-devops-test-pipeline-configureConfigures DevOps Center pipeline testing infrastructure: enables a test provider so its suites become available, re-syncs a configured provider to pull in new suites, or creates a quality gate with rules on a stage. Routes by intent across three modes after running shared prereq
SKILL.md
| 1 | # Configure DevOps Center Pipeline Testing Infrastructure |
| 2 | |
| 3 | Sets up and configures a DevOps Center pipeline's testing infrastructure. This skill handles three closely related "configure your pipeline" operations that share the same org context, prerequisites, and entity scope (the pipeline level). Pick the mode that matches the user's intent. |
| 4 | |
| 5 | > **API version:** All DevOps testing system calls target Salesforce API **v67.0** (minimum required). |
| 6 | |
| 7 | **Important:** All DevOps Center data (pipelines, stages, providers, suites, gates) lives in the Salesforce org — NOT the local repo. Never search the filesystem for pipeline configuration. Always query the org with `sf data query` or `sf api request rest`. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Step 1 — Run prerequisites first (always) |
| 12 | |
| 13 | Before any query or system call, run the prerequisite checks in `references/prerequisite-checks.md`. On any failure, surface the plain-language message and stop — never write to an unverified environment. |
| 14 | |
| 15 | - **Modes A & B (provider configure/sync):** run Prerequisites 1–4 (org login, Agentforce DX plugin, DevOps Center org auth, pipeline identified). Prerequisite 5 (stage) is **not** required — providers are configured at the pipeline level. |
| 16 | - **Mode C (quality gate):** run Prerequisites 1–4 **and** Prerequisite 5 (stage). Prereq 5 gives the `DevopsPipelineStage` only — the target `DevopsTestSuiteStage` record Id is resolved separately in Mode C's Step 0 (trigger → suite-stage row). |
| 17 | |
| 18 | Carry forward the resolved `doce-org-alias`, `pipelineId`, and (Mode C) `stageId` / `testSuiteStageId`. |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Step 2 — Select the mode |
| 23 | |
| 24 | | If the user wants to… | Mode | Follow | |
| 25 | |---|---|---| |
| 26 | | Enable / set up / add a provider that is **not yet configured** | **A — Configure a test provider** | `references/configuring-test-provider.md` | |
| 27 | | Re-sync / refresh an **already-configured** provider to pull in new suites | **B — Sync a configured provider** | `references/syncing-test-providers.md` | |
| 28 | | Set / configure a quality gate, coverage threshold, or testing benchmark on a stage | **C — Configure a quality gate** | `references/configuring-quality-gate.md` | |
| 29 | |
| 30 | **Disambiguating A vs B (the critical decision):** First fetch the pipeline's providers (`GET .../testProviders?status=all`) — both modes start there. Then: |
| 31 | |
| 32 | - Provider is **Available** (not configured) → **Mode A** (configure). |
| 33 | - Provider is **Configured** but suites are stale/missing → **Mode B** (sync). |
| 34 | - Provider is **Configured** and the user can't see suites *when assigning to a stage* → this is a **stage-assignment gap, not a configuration gap**. Redirect to `dx-devops-test-suite-assignments-configure`. |
| 35 | |
| 36 | ⚠ **Never POST to the configure endpoint for an already-configured provider** — it creates duplicate `DevopsPipelineTestProvider` records. See `references/gotchas.md`. |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ## Step 3 — Confirmation gate (required in every mode) |
| 41 | |
| 42 | Every mode mutates org state and **must** show a confirmation gate before any write. Each mode's reference file contains its exact gate wording (Mode C additionally requires a mandatory impact preview before the gate). Do not call any write API until the user gives an affirmative response. If the user declines, stop without writing. |
| 43 | |
| 44 | --- |
| 45 | |
| 46 | ## Step 4 — Execute and report |
| 47 | |
| 48 | Follow the chosen reference file for the exact API calls, success messages, and error handling: |
| 49 | |
| 50 | - `references/configuring-test-provider.md` — Mode A |
| 51 | - `references/syncing-test-providers.md` — Mode B |
| 52 | - `references/configuring-quality-gate.md` — Mode C |
| 53 | - `references/error-handling.md` — consolidated status-code → plain-language tables for all modes |
| 54 | - `references/gotchas.md` — duplicate-provider trap, API-name differences, trigger-type rules |
| 55 | |
| 56 | Never expose raw API errors, stack traces, or JSON payloads to the user — always translate to plain language. |
| 57 | |
| 58 | --- |
| 59 | |
| 60 | ## Related skills |
| 61 | |
| 62 | - **`dx-devops-test-suite-assignments-configure`** — after configuring/syncing a provider, assign or map its suites to a stag |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
