run-pipeline
>-
What it does
Run Pipeline
Execute and monitor Harness pipeline runs via MCP.
Instructions
Step 1: Find the Pipeline
Call MCP tool: harness_search
Parameters:
query: "<user's pipeline name or keyword>"
resource_types: ["pipeline"]
compact: true
Or list all pipelines in a project:
Call MCP tool: harness_list
Parameters:
resource_type: "pipeline"
org_id: "<organization>"
project_id: "<project>"
search_term: "<optional filter>"
Step 2: Get Pipeline Details
Call MCP tool: harness_get
Parameters:
resource_type: "pipeline"
resource_id: "<pipeline_identifier>"
org_id: "<organization>"
project_id: "<project>"
Extract from response:
- Required runtime inputs (
<+input>fields) - Pipeline variables with types and defaults
- Stage structure and deployment targets
Step 3: Check Available Input Sets
Call MCP tool: harness_list
Parameters:
resource_type: "input_set"
org_id: "<organization>"
project_id: "<project>"
Input sets provide pre-configured values that can be used or overridden.
Step 4: Execute the Pipeline
Call MCP tool: harness_execute
Parameters:
resource_type: "pipeline"
action: "run"
resource_id: "<pipeline_identifier>"
org_id: "<organization>"
project_id: "<project>"
Step 5: Monitor Execution
Call MCP tool: harness_get
Parameters:
resource_type: "execution"
resource_id: "<execution_id>"
org_id: "<organization>"
project_id: "<project>"
Execution statuses: Running, Success, Failed, Aborted, Waiting (approval/input), Expired
Step 6: Handle Approvals
If execution is waiting for approval:
Call MCP tool: harness_list
Parameters:
resource_type: "approval_instance"
org_id: "<organization>"
project_id: "<project>"
Then approve or reject:
Call MCP tool: harness_execute
Parameters:
resource_type: "approval_instance"
action: "approve" # or "reject"
resource_id: "<approval_id>"
Safety: Production Deployments
CRITICAL: Before executing pipelines targeting production:
- Confirm intent with the user explicitly
- Show what will be deployed (version, service, environment)
- Check if pipeline has approval gates
- Verify the version was tested in lower environments
Response Format
Before Execution
Pipeline: <name>
Project: <project>
Required Inputs: <list variables needing values>
Available Input Sets: <list>
Ready to execute? Confirm to proceed.
After Trigger
Pipeline: <name>
Execution ID: <id>
Status: Running
View in Harness: <openInHarness link>
Execution Complete
Pipeline: <name>
Status: Success/Failed
Duration: <time>
Stages: <stage results table>
Retrying Failed Executions
Retry is an action on pipeline (not execution). Pass the pipeline ID as resource_id and the failed execution's ID as execution_id:
Call MCP tool: harness_execute
Parameters:
resource_type: "pipeline"
action: "retry"
resource_id: "<pipeline_id>"
execution_id: "<execution_id>"
org_id: "<organization>"
project_id: "<project>"
Interrupting Running Executions
To abort an entire pipeline execution:
Call MCP tool: harness_execute
Parameters:
resource_type: "execution"
action: "interrupt"
resource_id: "<execution_id>"
org_id: "<organization>"
project_id: "<project>"
params:
interrupt_type: "AbortAll"
The interrupt_type field inside params is required. Valid values:
| interrupt_type | Effect |
|---|---|
AbortAll | Abort the entire pipeline execution |
UserMarkedFailure | Mark the execution as failed by user |
To abort multiple stuck executions, call harness_execute with params: {interrupt_type: "AbortAll"} for each execution ID.
Examples
- "Run the ci-pipeline" - Search for pipeline, execute with defaults
- "Deploy version 2.0.0 to staging" - Find deploy pipeline, provide version input, execute
- "What's the status of execution xyz123?" - Get execution details
- "Retry the last failed deployment" - List recent failed executions, retry
- "Abort all stuck executions" - List running/waiting executions, interrupt each with
params: {interrupt_type: "AbortAll"} - "Stop execution abc123" - Interrupt the specific execution with
params: {interrupt_type: "AbortAll"}
Performance Notes
- Always confirm the pipeline identifier and required inputs before triggering execution. A failed execution due to missing inputs wastes time.
- When monitoring executions, wait for terminal status (Success, Failed, Aborted) before reporting results. Do not assume intermediate states are final.
- If an execution fails, gather full error context from logs before suggesting fixes. Do not guess at root causes.
Troubleshooting
Pipeline Won't Start
- Check delegate availability with
harness_status - Validate all required inputs have values
- Test connector credentials with
harness_execute(resource_type: "connector", action: "test_connection")
Missing Inputs
- Use
harness_geton the pipeline to see all<+input>fields - Check input sets for pre-configured values
Execution Stuck
- Check for pending approvals with
harness_list(resource_type: "approval_instance") - Check delegate status with
harness_status - Abort stuck executions with
harness_execute(resource_type: "execution", action: "interrupt", params: {interrupt_type: "AbortAll"})
Capabilities
Install
Quality
deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 15 github stars · SKILL.md body (5,402 chars)