Respect attached profiles in SchedulerService

Gal Katzrequested to merge
gkatz_read_profiles_in_scheduler_service into master

What does this MR do and why?

Wires DependencyManagement::SecurityUpdate::SchedulerService to read values from an attached :dependency_scanning_post_processing security profile, gated by the security_remediation_profiles feature flag.

When the FF is on and a profile is attached, open_merge_requests_limit and severity_level are read from the profile via the new Security::ScanProfile#effective_configuration method, with defaults applied for missing keys.

Default values

Store thin, read fat - Defaults SSOT lives at ScanProfiles::Configuration::Defaults::DependencyScanningPostProcessing::VALUES. The configuration JSONB column persists only the user's overrides , and never the defaults themselves. effective_configuration merges the defaults under those overrides at read time, so callers see the full picture without the DB ever storing a redundant copy.

Implications:

  • Changing a default is one-file, no migration; it applies to every existing record on next read.
  • The stored value always reflects user intent and a default flip never overwrites what users explicitly set.
  • Adding a new profile type is one new defaults file under ee/app/models/security/scan_profiles/configuration/defaults/.

When no profile is attached or the FF is off, behavior is unchanged: MAX_OPEN_MERGE_REQUEST_LIMIT and the full SORTED_SEVERITY_LEVELS iteration are preserved.

Changelog: added
EE: true

Related issue

[Backend] Wire SchedulerService to read from re... (#603218 - closed) • Gal Katz • 19.2

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.

Edited by Gal Katz

Merge request reports