> For the complete documentation index, see [llms.txt](https://sealights-docs.tricentis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sealights-docs.tricentis.com/setup-and-configuration/command-line-interface/validate-your-pipeline-setup.md).

# Validate Your Pipeline Setup

After creating your Initial Build Map, you can validate that your pipeline is correctly configured end-to-end before enabling continuous build modification monitoring. This is done by manually triggering a build modification for a specific transport, letting you confirm that SeaLights detects the code change and displays it correctly in the Coverage Dashboard.

## Prerequisites

Before proceeding, confirm that your Initial Build Map is complete and visible in the SeaLights Coverage Dashboard. See [Create an Initial Build Map for your Pipeline](broken://pages/6f4WDLP7ZxZdqhvqwcMb). The check also needs the production usage data that the Initial Build Map creates for the pipeline's PRD RFC Destination.

The agent server must also be running, because the command runs its work on the server. See [Start the Agent Server](broken://pages/jjXJbDJ9CnFBYzl2NDMP). If the server cannot be reached, the command exits with code `12`.

## Step 1: Choose a Transport

Select a transport number from your QAS system that:

* Has already been **imported into the QAS system** — only imported transports can be reported to SeaLights.
* Contains code changes you know how to test.
* Has a corresponding test in your testing tool that covers those changed objects.
* Changes objects in packages that the Initial Build Map covers (or in customer packages, whose names start with `Z` or `Y`). Build Modifications only include objects from those packages, so changes to objects in other packages do not appear. Deleted objects are not limited. See [Which objects are included](broken://pages/JZVVGs3ieGcAwmbZ8qqj#which-objects-are-included).
* Has **not previously been reported to SeaLights** — each transport can only be reported once.

Choosing a transport with a known test lets you verify the complete flow: code change detected → visible in SeaLights → covered by a test run.

## Step 2: Trigger a Build Modification

Run the following from your PowerShell window:

{% hint style="info" %}
The command does not start while an initial build map or a build modification run is already running for the same pipeline (including a scheduled run that is in progress). It then exits with code `10` or `11`. Wait for the running task to finish and run the command again.
{% endhint %}

{% hint style="info" %}
When you specify a transport number, the agent uses the **current** time as the build timestamp (not the transport's historical import time). This ensures the build appears at the correct position in the SeaLights dashboard timeline.
{% endhint %}

{% hint style="info" %}
This manual check does not change where scheduled monitoring resumes. If the transport was imported after that point, scheduled monitoring still processes it later, under its import time. See [Where monitoring resumes](broken://pages/JZVVGs3ieGcAwmbZ8qqj#where-monitoring-resumes).
{% endhint %}

## Step 3: Verify in SeaLights

Once the command completes, verify the result in the SeaLights Coverage Dashboard:

1. Open the **Build history** window for your application.
2. Confirm the transport appears as a new Build Modification in the format `<Transport name>|<datetime>`, where the datetime is the time you ran the command.
3. Select the Build Modification and open the **Code Changes** tab to verify the modified objects are listed correctly.

<figure><img src="https://1120332842-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMsXHfFNCMXIaXf5BTCm6%2Fuploads%2FdhLK1LdQrJNlSAkBq2WU%2Fimage.png?alt=media&amp;token=0bb484d4-8aec-45e2-9335-b288492a22f5" alt=""><figcaption></figcaption></figure>

<figure><img src="https://1120332842-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMsXHfFNCMXIaXf5BTCm6%2Fuploads%2FePxf01cuCwH8rKsq0c8d%2Fimage.png?alt=media&amp;token=ffdebb80-e3db-4c1c-8ed4-ceec435f4015" alt=""><figcaption></figcaption></figure>

## Next Steps

With your pipeline validated, complete the following steps to begin collecting coverage data:

1. [**Collect Footprints data for your Pipeline**](broken://pages/BtrDV52TrGwLRpGXR4Nd) — configure the Agent to collect details for test executions in Tosca. When you run a test, the Agent matches the ABAP components that you executed against objects in the latest Build Modification and sends this data to SeaLights as a Footprint.
2. **Run your tests** — the default configuration automatically manages the test stage. SeaLights will match the executed ABAP components against the Build Modification and report coverage.
3. **Enable continuous monitoring** by proceeding to [Monitor your Pipeline for Build Modifications](broken://pages/JZVVGs3ieGcAwmbZ8qqj).

{% hint style="info" %}
Step 3 applies to customers moving forward with a full SeaLights deployment. If you are in an evaluation phase, your setup is complete — continuous monitoring can be enabled at any time when you are ready to go live.
{% endhint %}