> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-ai/use-harness-platform/git-experience/validate-pipeline-changes-with-dry-run.md).

# Validate pipeline changes with dry run

Use the dry run validation endpoint to validate pipeline YAML before committing to Git.

{% hint style="success" %}
This feature is in Limited GA and requires enablement. [View all early access features.](/release-notes/features.md)

{% @harness-feature-flag-access/request-feature-flag-access module="platform" pagePath="platform/use-harness-platform/git-experience/validate-pipeline-changes-with-dry-run" featureFlags="%5B%7B%22name%22%3A%22Dry%20run%20semantic%20validation%22%2C%22key%22%3A%22PIPE\_DRY\_RUN\_SEMANTIC\_VALIDATION%22%2C%22status%22%3A%22LIMITED\_GA%22%2C%22description%22%3A%22Adds%20semantic%20checks%20for%20connectors%20and%20codebase%20configuration%20to%20the%20dry%20run%20validation%20endpoint%2C%20for%20V0%20and%20V1%20pipeline%20YAML.%22%7D%5D" %}
{% endhint %}

The dry run validation endpoint allows you to validate pipeline YAML changes while editing files in Git. This helps catch configuration errors before you commit changes to your repository.

## What you will learn from this topic

* How to [use the dry run validation endpoint](#use-the-api-endpoint) to validate pipeline YAML.
* How to [read the validation response](#response-format) for valid and invalid pipelines.
* How [semantic validation](#semantic-validation) checks connectors and codebase settings.
* How to recognize the [limitations](#limitations) of dry run validation.

## What is dry run validation?

Dry run validation is an API endpoint that validates pipeline YAML without executing the pipeline. Use this endpoint to validate your pipeline changes while editing YAML files in Git before saving them.

The validation performs:

* **YAML schema validation**: Verifies the pipeline structure and syntax.
* **Template expansion**: Validates template references and expands templates during validation.
* **Policy evaluation**: Evaluates OPA policies for pipeline on save or on run.
* **Semantic validation**: Checks that the connectors and codebase settings in the pipeline are usable. Go to [Semantic validation](#semantic-validation) for details.

## Semantic validation

Semantic validation goes beyond YAML structure. It catches connector and codebase problems that would otherwise surface only when the pipeline runs. It applies to both the V0 and V1 pipeline YAMLs, including stages within `parallel` blocks.

This feature requires the `PIPE_DRY_RUN_SEMANTIC_VALIDATION` feature flag. Contact [Harness Support](mailto:support@harness.io) to enable.

Semantic validation is advisory. It does not block the dry run. If Harness cannot complete a check, for example because a connector reference is invalid, it skips that check and still returns the other results.

The checks are:

* **Connector references**: Every connector that the pipeline references exists. Blank values and runtime expressions are skipped.
* **Connector types**: Each connector is a type that the step or setting supports. For example, a container image pull requires a Docker, Google Cloud Platform (GCP), Amazon Web Services (AWS), or Azure connector.
* **Codebase and clone settings**: The clone and codebase configurations are valid.
* **Harness Cloud builds**: A Continuous Integration (CI) stage that runs on Harness Cloud does not use a Git connector that runs on a delegate. Harness Cloud builds cannot use delegate-backed Git connectors.

## Use the API endpoint

### Endpoint

```
POST /pipeline/api/v1/orgs/{org}/projects/{project}/dry-run
```

### Request parameters

```json
{
  "pipeline_identifier": "string",
  "pipeline_yaml": "string",
  "branch": "string"
}
```

| Parameter             | Required | Description                                                                                                    |
| --------------------- | -------- | -------------------------------------------------------------------------------------------------------------- |
| `pipeline_yaml`       | Yes      | Complete pipeline YAML as a string                                                                             |
| `pipeline_identifier` | Yes      | Unique identifier of the pipeline                                                                              |
| `branch`              | No       | Git branch where the pipeline is stored. Optional for an inline pipeline; include it for a Git-backed pipeline |

The account, organization, and project identifiers are supplied in the URL path (`org`, `project`) and the `Harness-Account` header, not in the request body.

### Example request

```bash
curl --location 'https://app.harness.io/pipeline/api/v1/orgs/default/projects/MyProject/dry-run' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Harness-Account: <account-id>' \
--data '{
  "pipeline_identifier": "mypipeline",
  "pipeline_yaml": "pipeline:\n  name: my-pipeline\n  identifier: mypipeline\n  ...",
  "branch": "main"
}'
```

## Response format

### Successful validation

When the pipeline YAML is valid, the endpoint returns a success response:

```json
{
  "is_valid": true,
  "validation": []
}
```

### Validation errors

When validation fails, the response includes specific error messages indicating what needs to be fixed:

```json
{
  "is_valid": false,
  "validation": [
    {
      "validation_type": "string",
      "entity_type": "string",
      "entity_identifier": "string",
      "error_message": "Following yaml paths could not be parsed: ...",
      "hint": "string"
    }
  ]
}
```

Each entry in the `validation` array describes one validation result. The endpoint returns a `validation_type` and `entity_type` for each entry.

## Limitations

The dry run validation cannot validate:

* **Expressions**: Pipeline expressions are not validated by the dry run endpoint.
* **Delegate availability**: Whether delegates are available for execution.
* **Cloud provider credentials**: Validity of credentials at execution time.
* **Artifact connectivity**: Whether artifact sources are accessible.
* **Service manifests**: Internal validity of Kubernetes manifests or other service definitions.

## Next steps

You have validated pipeline YAML with the dry run endpoint. Continue with the following:

* [Pipeline YAML quickstart](/harness-ai/use-harness-platform/pipelines/create-pipeline-quickstart.md): Learn the pipeline YAML schema.
* [Input sets and overlays](/harness-ai/use-harness-platform/pipelines/input-sets.md): Manage runtime inputs for your pipelines.

{% @harness-feedback/feedback module="harness-ai" pagePath="harness-ai/use-harness-platform/git-experience/validate-pipeline-changes-with-dry-run" %}