forcedotcom/sf-skills

dx-devops-test-pipeline-configure

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

Ver código fuente

Cómo usar

  1. Copia el comando y revisa el paquete antes de instalarlo en tu entorno de agente.
  2. Consulta las herramientas, credenciales y entornos necesarios en el documento original.
  3. Describe las entradas y el resultado deseado; contrasta la salida con las fuentes.
npx skills add https://github.com/forcedotcom/sf-skills --skill dx-devops-test-pipeline-configure

Antes de empezar

  • La instalación no incluye suscripción al modelo, cuota API ni permisos sobre tus archivos.
  • Las estrellas e instalaciones reflejan actividad, no una prueba independiente de calidad o seguridad.
Documento original del Skill

Contenido del repositorio de origen con títulos, ejemplos, código, tablas, enlaces e imágenes preservados.

Configure DevOps Center Pipeline Testing Infrastructure

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 or sf api request rest.


Step 1 — Run prerequisites first (always)

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.


Step 2 — Select the mode

If the user wants to…ModeFollow
Enable / set up / add a provider that is not yet configuredA — Configure a test providerreferences/configuring-test-provider.md
Re-sync / refresh an already-configured provider to pull in new suitesB — Sync a configured providerreferences/syncing-test-providers.md
Set / configure a quality gate, coverage threshold, or testing benchmark on a stageC — Configure a quality gatereferences/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.


Step 3 — Confirmation gate (required in every mode)

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.


Step 4 — Execute and report

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.


Related skills

  • `dx-devops-test-suite-assignments-configure` — after configuring/syncing a provider, assign or map its suites to a stage; also recommends which suites to run for a commit.
  • `dx-devops-test-suite-run` — run a suite, or retrigger a quality gate after fixes meet the threshold.
  • `dx-devops-test-failures-analyze` — explain failures from a run and optionally create a fix work item.

Relacionados por tarea

del mismo repositorio

Más Skills

Todos los Skills
forcedotcom
Comunidad

platform-custom-application-generate

Use this skill when users need to create or configure tab-based Salesforce Custom Applications with navigation, branding, and action overrides. Trigger when users mention custom apps, application metadata, app navigation, or organizing tabs into applications. Use when users want to create app containers for tabs and pages. Do NOT use when the goal is hosting a React UI bundle in the App Launcher — use experience-ui-bundle-custom-app-generate for that case.

instalaciones
1
GitHub Stars
1,1 mil
Actualizado
23 oct
forcedotcom
Comunidad

platform-custom-field-generate

Use when users create, generate, or validate Salesforce Custom Field metadata. Trigger on custom fields, field types, Roll-Up Summary, Master-Detail/Lookup relationships, formula fields, picklists, dependent (controlling) picklists, referencing a value set from a field, or scoping picklist values per record type; also field deployment errors, including a record type that won't deploy without a business process. DO NOT TRIGGER for creating/customizing the value set itself — a new GlobalValueSet o

instalaciones
1
GitHub Stars
1,1 mil
Actualizado
23 oct
forcedotcom
Comunidad

platform-custom-metadata-type-generate

Use to create, generate, or validate Salesforce Custom Metadata Type metadata — the mdt object, fields, and deployable records. Trigger on custom metadata types, CMDT, mdt objects, .md-meta.xml files, or cross-org reference/config data; also admin-maintained mapping/lookup/crosswalk tables (config that changes without a deploy belongs in a CMDT, never hardcoded in Apex/Flow), and CMDT deploy errors. DO NOT TRIGGER for Custom Settings (use platform-custom-setting-generate), business-record object

instalaciones
1
GitHub Stars
1,1 mil
Actualizado
23 oct
forcedotcom
Comunidad

platform-custom-report-type-generate

Use to create, generate, or validate Salesforce Custom Report Type metadata. Trigger on custom report types, CRTs, cross-object reports, report builder data sources, exposing fields for reporting across related objects, inner vs outer joins in reports, report type categories, or deployment errors for .reportType-meta.xml files. Do NOT trigger for running, editing, or filtering existing reports; creating report folders, dashboards, or list views; or non-authoring reporting questions.

instalaciones
1
GitHub Stars
1,1 mil
Actualizado
23 oct