Decide: should advanced scan configuration be per profile or per trigger?

The three draft layouts for showing advanced configuration in the scan profile UI can't be resolved until we settle whether advanced settings should be presented per profile or per trigger. Need a call from @m-omokoh, with input from @gkatz1 and @c_north.

Raised by Celeste on the epic:

I think we should check again with @m-omokoh if the advance settings should be separate from the triggers. I can't decide this with certainty because I don't have knowledge of the level of granularity that users expect. E.g. Do we anticipate users will have different settings for SECURE_ANALYZERS_PREFIX when triggered by an MR vs a Branch pipeline?

Why this is not obvious

The backend stores configuration per trigger, not per profile. It hangs off security_scan_profile_triggers via a nullable foreign key, and securityScanProfileUpdate can only write it through the triggers array — there's no per-profile configuration storage. A profile-level UI would therefore be a presentation-layer fiction over per-trigger data, and it has to decide what to show when two triggers hold different values for the same setting.

For Secret Detection, the configurable triggers are MERGE_REQUEST_PIPELINE and DEFAULT_BRANCH_PIPELINE. GIT_PUSH_EVENT (push protection) can't carry configuration at all — it's rejected by UNCONFIGURABLE_TRIGGER_TYPES_BY_SCAN_TYPE in Security::ScanProfileTrigger.

Three draft MRs compare layouts, currently showing raw CI variable names only, pending #627250:

  • !252986 (closed) "Show advanced configuration in the profile modal" — one bottom table, a row per trigger per setting, with a Trigger column. Gal's preferred option, though he flagged the Trigger column may not fit the available space.
  • !253278 (closed) "Show advanced configuration in each trigger card" — a table inside each trigger's own card.
  • !253279 (closed) "Show one advanced configuration per profile" — one bottom table, one row per setting, naming triggers only where values differ.
  • Celeste has also proposed a fourth variant: one bottom table, marking each value with scan-trigger icons instead of a separate column.

What this blocks

  • Resolving the three draft MRs above.
  • Whether the "Add variable" modal in edit mode needs a trigger selector at all — if configuration becomes per-profile, that selector disappears.
  • #624190 (closed) "[Frontend] Support custom Secret Detection profiles in existing UI" and #624191 (closed) "[Frontend] Scan profile drawer: view, create, edit and delete custom profiles".

Forward-looking note (not yet committed)

Michael Fangman has stated intent, not committed scope, for schedule-based triggers to come to advanced scan configuration profiles after the initial release, carrying their own run-cadence setting. If that lands, per-trigger differences become more likely, not less.

Related

  • #627250 "Add human-friendly name field for security scan profile configuration variables"
  • #604715 "Source of Truth: Configuration Approach for the New Secret Detection Analyzer"

@m-omokoh could you make a call on this? cc @gkatz1 @c_north for input.

Edited by 🤖 GitLab Bot 🤖