dx-devops-test-pipeline-configure

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Configure DevOps Center Pipeline Testing Infrastructure

配置DevOps Center管道测试基础设施

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.

API version: All DevOps testing system calls target Salesforce API v67.0 (minimum required).

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

sf api request rest

设置并配置DevOps Center管道的测试基础设施。此技能处理三个紧密相关的“配置管道”操作，这些操作共享相同的组织上下文、前置条件和实体范围（管道级别）。选择与用户意图匹配的模式。

API版本： 所有DevOps测试系统调用均针对Salesforce API v67.0（最低要求版本）。

重要提示： 所有DevOps Center数据（管道、阶段、提供商、套件、质量门）都存储在Salesforce组织中 —— 而非本地代码仓库。切勿在文件系统中搜索管道配置信息。始终使用

sf data query

或

sf api request rest

查询组织数据。

Step 1 — Run prerequisites first (always)

步骤1 — 先运行前置检查（必须执行）

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.

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.
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).

Carry forward the resolved

doce-org-alias

pipelineId

, and (Mode C)

stageId

testSuiteStageId

在执行任何查询或系统调用之前，先运行

references/prerequisite-checks.md

中的前置检查。若检查失败，显示通俗易懂的提示信息并停止操作 —— 切勿向未验证的环境写入数据。

模式A和B（提供商配置/同步）： 运行前置检查1-4（组织登录、Agentforce DX插件、DevOps Center组织授权、管道识别）。前置检查5（阶段）不需要 —— 提供商在管道级别进行配置。
模式C（质量门）： 运行前置检查1-4 以及前置检查5（阶段）。前置检查5仅提供
```
DevopsPipelineStage
```
—— 目标
```
DevopsTestSuiteStage
```
记录ID会在模式C的步骤0（触发→套件阶段行）中单独解析。

保留解析后的

doce-org-alias

、

pipelineId

以及（模式C下的）

stageId

testSuiteStageId

。

Step 2 — Select the mode

步骤2 — 选择模式

If the user wants to…	Mode	Follow
Enable / set up / add a provider that is not yet configured	A — Configure a test provider	`references/configuring-test-provider.md`
Re-sync / refresh an already-configured provider to pull in new suites	B — Sync a configured provider	`references/syncing-test-providers.md`
Set / configure a quality gate, coverage threshold, or testing benchmark on a stage	C — Configure a quality gate	`references/configuring-quality-gate.md`

Disambiguating A vs B (the critical decision): First fetch the pipeline's providers (

GET .../testProviders?status=all

) — both modes start there. Then:

Provider is Available (not configured) → Mode A (configure).
Provider is Configured but suites are stale/missing → Mode B (sync).
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
```
.

⚠ Never POST to the configure endpoint for an already-configured provider — it creates duplicate

DevopsPipelineTestProvider

records. See

references/gotchas.md

如果用户想要…	模式	参考文档
启用/设置/添加尚未配置的提供商	A — 配置测试提供商	`references/configuring-test-provider.md`
重新同步/刷新已配置的提供商以获取新套件	B — 同步已配置的提供商	`references/syncing-test-providers.md`
在阶段设置/配置质量门、覆盖率阈值或测试基准	C — 配置质量门	`references/configuring-quality-gate.md`

区分模式A与B的关键决策： 首先获取管道的提供商信息（

GET .../testProviders?status=all

）—— 两种模式均从此步骤开始。然后：

提供商状态为可用（未配置）→ 模式A（配置）。
提供商状态为已配置但套件信息过时/缺失 → 模式B（同步）。
提供商状态为已配置但用户在分配到阶段时无法看到套件 → 这是阶段分配问题，而非配置问题。请重定向至
```
dx-devops-test-suite-assignments-configure
```
。

⚠ 切勿对已配置的提供商调用配置端点的POST请求 —— 这会创建重复的

DevopsPipelineTestProvider

记录。详见

references/gotchas.md

。

Step 3 — Confirmation gate (required in every mode)

步骤3 — 确认环节（所有模式均需执行）

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.

所有模式都会修改组织状态，必须在执行任何写入操作前显示确认环节。每种模式的参考文档中都包含确切的确认提示措辞（模式C还需要在确认环节前显示强制影响预览）。在用户给出肯定答复前，切勿调用任何写入API。若用户拒绝，停止操作且不写入任何数据。

Step 4 — Execute and report

步骤4 — 执行并报告

Follow the chosen reference file for the exact API calls, success messages, and error handling:

```
references/configuring-test-provider.md
```
— Mode A
```
references/syncing-test-providers.md
```
— Mode B
```
references/configuring-quality-gate.md
```
— Mode C
```
references/error-handling.md
```
— consolidated status-code → plain-language tables for all modes
```
references/gotchas.md
```
— duplicate-provider trap, API-name differences, trigger-type rules

Never expose raw API errors, stack traces, or JSON payloads to the user — always translate to plain language.

遵循所选参考文档中的具体API调用、成功提示和错误处理规则：

```
references/configuring-test-provider.md
```
—— 模式A
```
references/syncing-test-providers.md
```
—— 模式B
```
references/configuring-quality-gate.md
```
—— 模式C
```
references/error-handling.md
```
—— 整合了所有模式的状态码→通俗易懂提示的对照表
```
references/gotchas.md
```
—— 重复提供商陷阱、API名称差异、触发类型规则

切勿向用户暴露原始API错误、堆栈跟踪或JSON负载 —— 始终转换为通俗易懂的语言。