### Problem With the table and source tagging in place, we need the core logic that updates profile statuses when scans complete, and handles profile lifecycle events (apply/remove). This includes the state machine logic for warning/failed thresholds, concurrency protection, and the pipeline trigger mechanism. ### Proposal Create `Security::ScanProfileStatus::UpdateService` and `UpdateWorker`, add a pipeline `after_transition` trigger, and add lifecycle callbacks to `ScanProfileProject` for profile apply/remove. ### Implementation details **Files to create/change:** | File | Change | |---|---| | `ee/app/services/security/scan_profile_status/update_service.rb` | New service | | `ee/app/workers/security/scan_profile_status/update_worker.rb` | New worker | | `ee/app/workers/all_queues.yml` | Register worker queue | | `ee/app/models/ee/ci/pipeline.rb` | Add `after_transition` trigger for the worker | | `ee/app/models/security/scan_profile_project.rb` | Add `after_create_commit` and `after_destroy_commit` callbacks | **Service (`UpdateService`):** - Accepts a `pipeline`, filters to builds with `source: security_scan_profiles` - For each completed profile-triggered build: 1. Detects scan type from build report artifacts (reuses `Security::LatestPipelineInformation#build_reports`) 2. Looks up the project's scan profile for that type 3. Reads existing status record, calculates new counters, resolves status 4. Upserts the `ScanProfileProjectStatus` record - License check: `security_scan_profiles` - Feature flag check: `security_scan_profiles_feature` **State transition logic:** | Current State | Scan Result | New State | Failure Count | Success Count | |---|---|---|---|---| | any | success | `success` (Active) | 0 | prev + 1 | | any | failed (1st) | `warning` | 1 | 0 | | any | failed (2nd) | `warning` | 2 | 0 | | any | failed (3rd+) | `failed` | 3+ | 0 | **Worker (`UpdateWorker`):** - Triggered via `after_transition any => [:success, :failed, :canceled]` on `Ci::Pipeline` (same pattern as `PipelineAnalyzersStatusUpdateWorker`) - Only runs for `default_branch?` pipelines - Uses `Gitlab::ExclusiveLeaseHelpers#in_lock` scoped to `project_id` to prevent TOCTOU race conditions - Re-enqueues after 10 seconds if lock cannot be obtained - `data_consistency :delayed`, `idempotent!`, `urgency :low`, `feature_category :security_asset_inventories` **Lifecycle callbacks on `ScanProfileProject`:** - `after_create_commit :initialize_profile_status` — upserts a status record with `status: :success` (Active), `last_scan_at: nil`, counters at 0 - `after_destroy_commit :mark_profile_status_unconfigured` — updates status to `not_configured`, resets counters, preserves `last_scan_at` ### Test plan `ee/spec/services/security/scan_profile_status/update_service_spec.rb`: - On success: status is `success`, failure count resets to 0, success count increments - On 1st failure: status transitions to `warning`, failure count is 1, success count resets to 0 - On 2nd consecutive failure: status remains `warning`, failure count is 2 - On 3rd consecutive failure: status transitions to `failed`, failure count is 3 - After `warning` then success: status resets to `success`, failure count resets to 0 - After `failed` then success: status resets to `success` - Only processes builds with `source: security_scan_profiles` - Ignores builds from other sources (YAML, policies) - Does nothing when no profile is applied - Does nothing when license is not available - Does nothing when feature flag is disabled `ee/spec/workers/security/scan_profile_status/update_worker_spec.rb`: - Calls `UpdateService` for a valid pipeline on default branch - Does nothing if pipeline is not found - Does nothing if pipeline is not on default branch - Re-enqueues the job if the lock cannot be obtained `ee/spec/models/security/scan_profile_project_spec.rb` (additions): - After creating a `ScanProfileProject`, a `ScanProfileProjectStatus` record exists with `status: :success` and `last_scan_at: nil` - After destroying a `ScanProfileProject`, the status record has `status: :not_configured` and `last_scan_at` is preserved - Re-applying a profile (create after destroy) resets status to `success` ### Risks - **TOCTOU race condition:** The service reads `consecutive_failure_count`, increments it, then upserts. Mitigated by exclusive lease in the worker scoped to `project_id`. - **Worker triggered for every pipeline:** Service exits early if no profile-triggered builds exist. The `joins(:job_source).where(source: :security_scan_profiles)` query is efficient. - **`after_create_commit` failure:** The upsert is a simple single-row operation. If it fails, the status record will be created on the next scan completion. ### Acceptance criteria - [ ] Profile status updates only when a profile-triggered job completes (source filtering) - [ ] `consecutive_failure_count` increments on failure and resets to 0 on success - [ ] `consecutive_success_count` increments on success and resets to 0 on failure - [ ] Status transitions to `warning` on 1st/2nd consecutive failure; transitions to `failed` on 3rd - [ ] Status resets to `success` on any successful scan (from `warning` or `failed`) - [ ] Applying a profile creates an initial Active status record with `last_scan_at: nil` - [ ] Removing a profile sets status to Unconfigured but retains `last_scan_at` - [ ] Profile status upserts are protected against TOCTOU race conditions via Redis-based exclusive lease - [ ] Worker only processes default branch pipelines - [ ] No changes to `analyzer_project_statuses` or inventory behavior - [ ] All changes are covered by specs ### Related - Parent: [#591555](https://gitlab.com/gitlab-org/gitlab/-/work_items/591555) - Implementation plan: [#591916](https://gitlab.com/gitlab-org/gitlab/-/work_items/591916) - Blocked by: [#593130](https://gitlab.com/gitlab-org/gitlab/-/work_items/593130), [#593131](https://gitlab.com/gitlab-org/gitlab/-/work_items/593131) - Blocks: [#593133](https://gitlab.com/gitlab-org/gitlab/-/work_items/593133)