Draft: Add SPEP test-run feature PoC

What does this MR do and why?

This MR introduces a proof of concept for the Scheduled Pipeline Execution Policy (SPEP) test-run feature. The feature allows users to validate policy configurations and measure pipeline execution duration before enabling policies at scale.

Problem Statement

Customers are hesitant to enable Scheduled Pipeline Execution Policies due to lack of visibility into the potential impact. They need to understand:

• How many pipelines will be triggered at once
• Estimated execution duration for all pipelines
• Resource utilization impact on their infrastructure

Proposed Solution (Phase 1)

This PoC implements the core test-run functionality:

1. GraphQL Mutation: pipelineExecutionSchedulePolicyTestRun - triggers a test-run on a selected project
2. Service Layer: Security::PipelineExecutionSchedulePolicies::TestRunService - handles validation and pipeline execution
3. Data Storage: New security_policy_schedule_test_runs table to store test-run results
4. Feature Flag: spep_test_run for controlled rollout

Key Features

• Single Project Selection: Test on one project at a time
• Owner Permission: Only project owners can initiate test-runs
• Duration Tracking: Captures pipeline execution duration and success/failure status
• Policy Scope Validation: Ensures the project is within the policy's scope

Database Changes

New table: security_policy_schedule_test_runs

• security_policy_id - Reference to the SPEP policy
• project_id - Project the test was run on
• user_id - User who initiated the test
• pipeline_id - Pipeline created (if successful)
• status - pending/running/success/failed
• started_at / finished_at - Timing information
• error_message - Error details if failed

GraphQL API

mutation {
  pipelineExecutionSchedulePolicyTestRun(input: {
    projectPath: "namespace/project"
    policyName: "my-spep-policy"
    policyProjectPath: "namespace/security-policies"
  }) {
    testRun {
      id
      status
      durationSeconds
      pipeline {
        id
        status
      }
    }
    errors
  }
}

Here's the "How to set up and validate locally" section for the MR description:

---

How to set up and validate locally

Prerequisites

1. Enable the feature flag:

   Feature.enable(:spep_test_run)

2. Ensure you have:

   • A project with a security policy project linked
   • A Scheduled Pipeline Execution Policy (SPEP) configured in the policy project
   • Owner access to the target project

1. Trigger a test-run

Use this GraphQL mutation to trigger a test-run on a specific project:

mutation {
  pipelineExecutionSchedulePolicyTestRun(input: {
    projectPath: "your-namespace/your-project"
    policyName: "your-spep-policy-name"
    policyProjectPath: "your-namespace/security-policies"
  }) {
    testRun {
      id
      status
      errorMessage
      pipeline {
        id
        status
      }
    }
    errors
  }
}

2. Fetch test-run results

Once the pipeline completes, query the test-run to get the duration and final status. You can use the id returned from the mutation:

query {
  pipelineExecutionSchedulePolicyTestRun(id: "gid://gitlab/Security::PolicyScheduleTestRun/7") {
    id
    status
    startedAt
    finishedAt
    durationSeconds
    completed
    errorMessage
    project {
      fullPath
    }
    pipeline {
      id
      status
      duration
    }
  }
}

Note: The status, startedAt, finishedAt, and durationSeconds fields are delegated from the associated pipeline, so they will update automatically as the pipeline progresses through its lifecycle.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

Related Issues

• Spike issue: #556127 (closed)
• Parent Epic: &17875