Validation Task

Validation task is added to perform Static Code Analysis checks and generate the validation report to view the errors encountered. You can continue the execution of the pipeline even upon failure by checking the checkbox – Continue On Failure by fixing the errors seen in the log and re-running the release pipeline.

Note: The behavior and configuration of the Validation Task differ based on the selected project type.

Validation Task for Transport Management

Field / Option	Description
Name	Enter any name of your choice for the validation task being created. Note: Only letters, numbers, underscores (_), and periods (.) are permitted.
Description	Any message that is to be conveyed to the task approver can be mentioned here.
Domain Controller	Dropdown to select the domain controller for the transport landscape.
Source	Source system from where transports will be validated.
Target	Target system where the transport is expected to move.
Pipeline Execution	Section indicating execution preferences for the task.
Continue on Failure	Checkbox to allow pipeline execution to continue even if validation fails.
Quality Checks	ATC Checks: Executes ABAP Test Cockpit (ATC) checks to analyze code quality, syntax errors, performance, and security compliance. Impact Analysis: Checks how the changes in the transport affect other dependent or referencing objects across systems. Unit Tests: Runs ABAP Unit Tests to verify the functional correctness of the objects in the transport. User Story Dependencies (Beta): Identifies and validates dependent user stories to prevent conflicts or incomplete deployments. Note: You can select any one or more of the following Quality Checks when configuring the validation task.

Validation Task for CPI and API Projects

Field / Option	Description
Name	Enter any name of your choice for the validation task being created. Note: Only letters, numbers, underscores (_), and periods (.) are permitted.
Description	Any message that is to be conveyed to the task approver can be mentioned here.
CPI / API	Select the respective target environment where validation is to be performed.
Pipeline Execution	Section indicating execution preferences for the task.
Continue on Failure	Checkbox to allow pipeline execution to continue even if validation fails.
Quality Checks	CPI Downgrade Check: The downgrade check evaluates version consistency between deploying artifact version and target environments version for CPI artifacts. Unit Tests: Executes CPI unit tests to validate business logic. User Story Dependencies (Beta): Identifies and validates dependent user stories to prevent conflicts or incomplete deployments. CPI Governance : Enforces organizational policies by validating artifact metadata, naming standards, and deployment readiness—ensuring controlled and compliant releases. Note: You can select any one or more of the following Quality Checks when configuring the validation task.

CPI Downgrade Check – Validation Outcomes

This check ensures version consistency between the source and target environments before deployment. Below are the possible validation outcomes:

✅ Success – Equal or Lower Version

If the target version is lower than or equal to the source version, the validation passes.

• Example Message: "The artifact '' target environment version '1.2' is lower than the source environment version '1.3'."

✅ Success – Artifact Not Present in Target

If the artifact is not present in the target environment (e.g., initial deployment), the validation passes.

• Example Message: "The artifact '' is not present in the target environment ''."

❌ Failure – Target Has Higher Version

If the target version is higher than the source version, the validation fails.

• Example Message: "The artifact '' target environment version '1.4' is higher than the source environment version '1.3'."

⚠️ Warning – Force Deploy Enabled

If Force Deploy is enabled, the deployment proceeds, but a warning is shown.

• Example Message: "The artifact '' target environment version '1.4' is higher than the source environment version '1.3' but force deploy is enabled."

⚠️ Warning – Already Deployed via ReleaseOwl

If the artifact was already deployed via ReleaseOwl and an older version is redeployed, the downgrade is considered intentional. A warning is shown and the artifact is not redeployed.

• Example Scenario: Version 1.1 was deployed, then version 1.2. Attempting to redeploy 1.1 results in:

• Example Message: "The artifact '' target environment version '1.4' is higher than the source environment version '1.3' but artifact is already deployed via ReleaseOwl."