Add test_runs field to SecurityPolicyType
What does this MR do and why?
Background
Scheduled Pipeline Execution Policies (SPEP) allow organizations to enforce scheduled pipelines across all projects in a group. However, customers are hesitant to enable these policies in production because they lack visibility into the potential impact — they need to understand how many pipelines will be triggered, how long each will take, and the overall resource cost.
To address this, we are building a test run feature that lets users validate a policy configuration by triggering a dry-run on a single project before enabling the policy at scale. The test run captures pipeline duration and status, which can then be used to estimate the total impact across all projects in scope.
The backend service for creating and tracking test runs was merged in !222053 (merged). This MR adds the GraphQL API layer so the frontend can query test run results when displaying the policy list.
What this MR does
Adds a testRuns connection field to the SecurityPolicyType GraphQL type, allowing clients to fetch test runs associated with scheduled pipeline execution policies. For each test run, the API exposes the run state (running/complete/failed), pipeline timing (start, finish, duration), any error messages, and the project the test was executed against.
Implementation note: The testRuns resolver looks up the Security::Policy record using (security_orchestration_policy_configuration_id, type, policy_index) rather than name. This uses the existing unique composite index index_security_policies_on_unique_config_type_policy_index, ensuring efficient lookups. The policy_index is threaded through from all_policies_with_type → construct_pipeline_execution_schedule_policy → the resolver.
References
- Issue: #586874 (closed)
- Test run feature epic: &20526
- SPEP GA release epic: &17875
- Spike issue: #556127 (closed)
- Backend MR (test run service): !222053 (merged)
- PoC MR: !218585 (closed)
How to set up and validate locally
Prerequisites
-
Enable the feature flag:
Feature.enable(:spep_test_run) -
Set up a group with a security policy project and a scheduled pipeline execution policy (see !222053 (merged) for detailed setup steps).
Step 1: Create a test run via Rails console
policy = Security::Policy.type_pipeline_execution_schedule_policy.last
project = policy.projects.last || Project.find_by_full_path('your-group/your-project')
user = User.find_by_username('your-username')
result = Security::PipelineExecutionPolicies::TestRunService.new(
policy: policy, project: project, user: user
).execute
# Verify the test run was created
result.payload[:test_run]
# => #<Security::ScheduledPipelineExecutionPolicyTestRun id: ..., state: "running", ...>Step 2: Query test runs via GraphQL
Run this query in the GraphiQL explorer (/-/graphql-explorer).
Important: Query at the level where the policy was created. If the policy is configured at the group level, use the namespace query (not project). The testRuns resolver only returns results for policies directly owned by the queried parent.
Group-level query (use this when the policy is created at the group level):
query {
namespace(fullPath: "your-group") {
securityPolicies {
nodes {
name
type
testRuns {
nodes {
id
state
duration
startedAt
finishedAt
errorMessage
project { fullPath }
createdAt
}
}
}
}
}
}Project-level query (use this when the policy is created at the project level):
query {
project(fullPath: "your-group/your-project") {
securityPolicies {
nodes {
name
type
testRuns {
nodes {
id
state
duration
startedAt
finishedAt
errorMessage
project { fullPath }
createdAt
}
}
}
}
}
}Step 3: Verify expected behavior
- Schedule policies should return the test run created in Step 1 under
testRuns.nodes. - Other policy types (scan execution, approval, etc.) should return
testRuns: { nodes: [] }. - If the feature flag is disabled (
Feature.disable(:spep_test_run)),testRunsshould return empty for all policies. - Group-level policies only return test runs when queried via
namespace, not viaproject.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.