dx-devops-test-suite-assignments-configure

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Configure DevOps Center Suite Assignments

配置DevOps Center套件分配

Recommends which existing test suites to run for a change, and manages how suites are assigned and mapped to pipeline stages. These operations share the same suite-stage metadata: a recommendation surfaces relevant suites and flags gaps, and those gaps lead directly into assignment.

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

Important: All DevOps Center data lives in the Salesforce org — NOT the local repo. Never search the filesystem for suite configuration. Always query the org with

sf data query

sf api request rest

为变更推荐应运行的现有测试套件，并管理套件到流水线阶段的分配与映射方式。这些操作共享相同的套件-阶段元数据：推荐会展示相关套件并标记缺口，而这些缺口可直接引导至分配操作。

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

**重要提示：**所有DevOps Center数据存储在Salesforce组织中——而非本地仓库。切勿在文件系统中搜索套件配置。始终使用

sf data query

或

sf api request rest

查询组织。

Step 1 — Run prerequisites first (always)

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

Run the prerequisite checks in

references/prerequisite-checks.md

before any query or system call. On any failure, surface the plain-language message and stop.

Mode A (recommend): Prerequisites 1–4 (org login, plugin, DevOps Center org auth, pipeline identified). No stage required — recommendation reads the pipeline-level Review trigger.
Modes B–D (assign/map/classes): Prerequisites 1–4 and Prerequisite 5 (stage). You need
```
doce-org-alias
```
,
```
pipelineId
```
, and
```
stageId
```
.

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

references/prerequisite-checks.md

中的前置检查。若检查失败，展示通俗易懂的提示信息并停止操作。

**模式A（推荐）：**前置检查1–4（组织登录、插件、DevOps Center组织授权、流水线已识别）。无需指定阶段——推荐操作读取流水线级别的Review触发器。
**模式B–D（分配/映射/类操作）：**前置检查1–4 以及前置检查5（阶段）。需要
```
doce-org-alias
```
、
```
pipelineId
```
和
```
stageId
```
。

Step 2 — Select the mode

步骤2 — 选择模式

If the user wants to…	Mode	Follow
Know which suites to run for a commit/diff, or what covers their changes	A — Recommend suites	`references/recommendation-logic.md`
Assign one suite to a stage as a one-off	B — Assign a single suite	`references/suite-assignment-modes.md`
Bulk-map multiple suites to a stage as a testing strategy	C — Map multiple suites	`references/suite-assignment-modes.md`
Add/remove individual test classes within a suite assignment	D — Add/remove classes	`references/suite-assignment-modes.md`

Mode A is pure reasoning (no writes). Modes B–D mutate org state via the same

testSuiteStages

endpoint (

references/api-endpoint.md

How A feeds B–D: When recommendation flags a relevant suite that is not assigned to the stage, that gap is the input to Mode B/C. When it flags a new method with no suite coverage, direct the developer to author tests manually (v1 constraint — never suggest generating tests here).

用户需求	模式	参考文档
了解针对某次提交/差异应运行哪些套件，或哪些套件覆盖了他们的变更	A — 推荐套件	`references/recommendation-logic.md`
一次性将单个套件分配到某个阶段	B — 分配单个套件	`references/suite-assignment-modes.md`
将多个套件批量映射到某个阶段作为测试策略	C — 映射多个套件	`references/suite-assignment-modes.md`
在套件分配中添加/移除单个测试类	D — 添加/移除类	`references/suite-assignment-modes.md`

模式A为纯推理操作（无写入）。模式B–D通过同一个

testSuiteStages

端点修改组织状态（参考

references/api-endpoint.md

）。

模式A如何衔接模式B–D：当推荐标记出某个相关套件未分配到该阶段时，此缺口将作为模式B/C的输入。当推荐标记出某个新方法无套件覆盖时，引导开发人员手动编写测试（v1版本限制——此处切勿建议生成测试）。

Step 3 — Governance & confirmation (Modes B–D)

步骤3 — 治理与确认（模式B–D）

Modes B–D must confirm before any write:

Mode B — single confirmation prompt naming the suite, stage, and event.
Mode C — a mandatory impact-preview table (Suite / Stage / Event / Action) before the confirmation gate.
Mode D — re-present the final test list before confirming. Rejected tests must be EXCLUDED from the payload. If tests were modified during review, re-present the final list before requesting confirmation. Never call without explicit approval.

Do not call the API until the user gives an affirmative response. If the user declines, stop without writing. Full wording for each gate is in

references/suite-assignment-modes.md

Mode A (recommendation) makes no writes and needs no confirmation gate.

模式B–D在执行任何写入操作前必须获得确认：

模式B — 显示包含套件、阶段和事件名称的单个确认提示。
模式C — 在确认环节前展示强制影响预览表格（套件 / 阶段 / 事件 / 操作）。
模式D — 在确认前重新展示最终测试列表。被拒绝的测试必须从请求体中排除。若在审核过程中修改了测试内容，需重新展示最终列表后再请求确认。未经明确批准，切勿调用API。

在用户给出肯定答复前，请勿调用API。若用户拒绝，停止操作且不执行写入。每个确认环节的完整措辞请参考

references/suite-assignment-modes.md

。

模式A（推荐）无写入操作，无需确认环节。

Step 4 — Execute and report

步骤4 — 执行与报告

Follow the chosen reference file:

```
references/recommendation-logic.md
```
— Mode A: diff classification, provider matching, ranking, gap flagging, output format.
```
references/suite-assignment-modes.md
```
— Modes B–D: inputs, confirmation wording, success messages.
```
references/api-endpoint.md
```
— the shared
```
testSuiteStages
```
POST payload schema (Modes B–D).
```
references/error-handling.md
```
— status-code → plain-language tables.

Never expose raw API errors, stack traces, or JSON to the user.

遵循所选的参考文档：

```
references/recommendation-logic.md
```
— 模式A：差异分类、提供商匹配、排序、缺口标记、输出格式。
```
references/suite-assignment-modes.md
```
— 模式B–D：输入参数、确认措辞、成功提示信息。
```
references/api-endpoint.md
```
— 模式B–D共享的
```
testSuiteStages
```
POST请求体 schema。
```
references/error-handling.md
```
— 状态码对应通俗易懂信息的表格。

切勿向用户展示原始API错误、堆栈跟踪或JSON内容。