The frontend needs a way to query profile statuses for a project to display scanner health indicators. The data exists in `scan_profile_project_statuses` but is not yet exposed via the API. ### Proposal Create a `ScanProfileProjectStatus` GraphQL type and expose a `scanProfileStatuses` field on `ProjectType`. The API exposes a single computed `status` enum that resolves the final display state server-side, so the frontend can use it directly for badge rendering without reimplementing threshold or staleness logic. ### Design decision: single computed `status` field The database stores a raw status (`not_configured`, `success`, `warning`, `failed`) along with `last_scan_at` and `consecutive_failure_count`. The model has internal helpers (`stale?`, `active?`, `profile_failed?`) that layer additional logic on top. Rather than exposing the raw DB status plus three separate boolean fields (`stale`, `active`, `profileFailed`), the GraphQL API exposes a single `status` enum that resolves the final display state. This avoids confusing overlap (e.g., "why do we have `stale` if we have `status`?") and gives the frontend one field to switch on for badge color/icon. **Status resolution logic:** | DB status | Condition | GraphQL `status` | |-----------|-----------|------------------| | `not_configured` | — | `NOT_CONFIGURED` | | `success` | `last_scan_at` is nil or recent (\< 90 days) | `ACTIVE` | | `success` | `last_scan_at` \> 90 days ago | `STALE` | | `warning` | `last_scan_at` recent | `WARNING` | | `warning` | `last_scan_at` \> 90 days ago | `STALE` | | `failed` | `last_scan_at` recent | `FAILED` | | `failed` | `last_scan_at` \> 90 days ago | `STALE` | Key points: - `ACTIVE` = the profile is healthy (scans succeeding, not stale). This is the "green" state. - `WARNING` = 1-2 consecutive failures. Intermediate state before full failure. - `FAILED` = 3+ consecutive failures. The profile is broken. - `STALE` = any configured profile with no scan activity in 90 days, regardless of last known result. Staleness takes priority over the underlying status. - `NOT_CONFIGURED` = no profile applied for this scan type. - The raw counters (`consecutiveFailureCount`, `consecutiveSuccessCount`) and `lastScanAt` are still exposed for detail views and tooltips. ### Implementation details **Files to create/change:** | File | Change | |------|--------| | `ee/app/graphql/types/security/scan_profile_project_status_type.rb` | New GraphQL type | | `ee/app/graphql/types/security/scan_profile_status_enum.rb` | New enum: `NOT_CONFIGURED`, `ACTIVE`, `WARNING`, `FAILED`, `STALE` | | `ee/app/graphql/ee/types/project_type.rb` | Add `scan_profile_statuses` field and resolver method | **GraphQL enum (`ScanProfileStatusEnum`):** ```graphql enum ScanProfileStatus { NOT_CONFIGURED # No profile applied for this scan type ACTIVE # Scans succeeding and not stale WARNING # 1-2 consecutive scan failures FAILED # 3+ consecutive scan failures STALE # No scan activity in 90 days } ``` **GraphQL type fields:** | Field | Type | Nullable | Description | |-------|------|----------|-------------| | `scanProfile` | `ScanProfileType!` | No | The scan profile this status belongs to (includes `id`, `name`, `scanType`) | | `status` | `ScanProfileStatus!` | No | Computed display status: NOT_CONFIGURED, ACTIVE, WARNING, FAILED, or STALE | | `consecutiveFailureCount` | `Int!` | No | Number of consecutive failed scans | | `consecutiveSuccessCount` | `Int!` | No | Number of consecutive successful scans | | `lastScanAt` | `Time` | Yes | Timestamp of the last profile-triggered scan | | `buildId` | `CiJobID` | Yes | ID of the last CI job that triggered this status | **Authorization:** `:read_security_scan_profiles` (developer+ access, same as the existing `securityScanProfiles` field). **Resolver:** Simple association load on `Project#scan_profile_project_statuses`, gated by `licensed_feature_available?(:security_scan_profiles)`. **Status resolver method on the GraphQL type:** ```ruby def status if object.not_configured? 'not_configured' elsif object.stale? 'stale' elsif object.profile_failed? 'failed' elsif object.warning? 'warning' else 'active' end end ``` Note: `stale?` is checked before `profile_failed?` and `warning?` because staleness takes priority. If a profile has 3+ failures but no scan in 90 days, it shows as `STALE` rather than `FAILED`. Return values use lowercase strings that match the enum `value:` declarations; the GraphQL framework maps them to uppercase names in the response. **Example query:** ```graphql query { project(fullPath: "my-group/my-project") { scanProfileStatuses { scanProfile { id name scanType } status consecutiveFailureCount consecutiveSuccessCount lastScanAt buildId } } } ``` **Example response:** ```json { "data": { "project": { "scanProfileStatuses": [ { "scanProfile": { "id": "gid://gitlab/Security::ScanProfile/1", "name": "Default SAST", "scanType": "SAST" }, "status": "ACTIVE", "consecutiveFailureCount": 0, "consecutiveSuccessCount": 12, "lastScanAt": "2026-03-17T14:30:00Z", "buildId": "gid://gitlab/CommitStatus/123" }, { "scanProfile": { "id": "gid://gitlab/Security::ScanProfile/2", "name": "Default Secret Detection", "scanType": "SECRET_DETECTION" }, "status": "WARNING", "consecutiveFailureCount": 2, "consecutiveSuccessCount": 0, "lastScanAt": "2026-03-16T09:15:00Z", "buildId": "gid://gitlab/CommitStatus/456" } ] } } } ``` ### Test plan `ee/spec/graphql/types/security/scan_profile_project_status_type_spec.rb`: - Has expected fields: `scan_profile`, `status`, `consecutive_failure_count`, `consecutive_success_count`, `last_scan_at`, `build_id` - Does NOT have fields: `scan_type`, `stale`, `active`, `profile_failed` (these are internal model methods or derived fields, not exposed directly) - Authorization: requires `:read_security_scan_profiles` `ee/spec/graphql/types/security/scan_profile_status_enum_spec.rb`: - Has expected values: `NOT_CONFIGURED`, `ACTIVE`, `WARNING`, `FAILED`, `STALE` `ee/spec/requests/api/graphql/project/scan_profile_statuses_spec.rb`: - Returns profile statuses for a project with applied profiles - Returns empty array for a project with no profiles - Returns `null` when license is not available - Respects authorization (non-developer cannot access) - Status resolution: - Returns `ACTIVE` when DB status is `success` and `last_scan_at` is recent - Returns `STALE` when DB status is `success` but `last_scan_at` \> 90 days ago - Returns `STALE` when DB status is `failed` but `last_scan_at` \> 90 days ago (staleness takes priority) - Returns `WARNING` when DB status is `warning` and `last_scan_at` is recent - Returns `FAILED` when DB status is `failed` and `consecutive_failure_count >= 3` and `last_scan_at` is recent - Returns `NOT_CONFIGURED` when DB status is `not_configured` - Returns `ACTIVE` when DB status is `success` and `last_scan_at` is nil (freshly applied profile) ### Acceptance criteria - [ ] `ScanProfileProjectStatus` GraphQL type exists with fields: `scanProfile`, `status`, `consecutiveFailureCount`, `consecutiveSuccessCount`, `lastScanAt`, `buildId` - [ ] `ScanProfileStatusEnum` exists with values: `NOT_CONFIGURED`, `ACTIVE`, `WARNING`, `FAILED`, `STALE` - [ ] `status` field returns a single computed display status (not the raw DB value) - [ ] Staleness takes priority: a stale profile shows `STALE` regardless of underlying DB status - [ ] `scanProfileStatuses` field is exposed on `ProjectType` - [ ] Field is gated by `:read_security_scan_profiles` authorization - [ ] Field is gated by `security_scan_profiles` license - [ ] Field is marked as `experiment` for milestone 18.11 - [ ] All changes are covered by specs ### Related - Parent: [#591555](https://gitlab.com/gitlab-org/gitlab/-/work_items/591555) - Implementation plan: [#591916 (closed)](https://gitlab.com/gitlab-org/gitlab/-/work_items/591916) - Blocked by: [#593131](https://gitlab.com/gitlab-org/gitlab/-/work_items/593131), [#593132](https://gitlab.com/gitlab-org/gitlab/-/work_items/593132) - Blocks: nothing (frontend can start consuming once this is merged)