Add internal visibility option to send_bot_message policy action

Alan (Maciej) Paruszewskirequested to merge
feature/security-policy-bot-comment-visibility into master

What does this MR do and why?

Adds an opt-in visibility field (public | internal, default public) to the send_bot_message action of the merge request approval policy YAML schema.

Today, the bot comment a security policy posts on a merge request when a policy is violated is always a public note. This lets a policy author configure that comment to be posted as an internal note instead, visible only to project members with at least the Reporter role — useful for confidential-vulnerability-sensitive projects.

Scope, by design:

  • Backend + JSON schema + docs only. No frontend/policy-editor UI changes.
  • No feature flag: the field is opt-in per policy and defaults to public (no behavior change for existing policies), so none of the standard flag types (gitlab_com_derisk, wip, beta, ops, experiment) fit.
  • Visibility is set only when the bot comment is first created. Note#confidential cannot be changed on an already-persisted note, so a later change to a policy's visibility setting does not affect a comment already posted on a merge request. This is documented in the field description.
  • If multiple violated policies apply different visibility settings to the same merge request, the single aggregated comment is created as internal if any of them set internal (fail-safe default).

References

Screenshots or screen recordings

N/A — backend/schema/docs change, no UI.

How to set up and validate locally

  1. Create an approval policy with a send_bot_message action that sets visibility: internal:

    actions:
  - type: send_bot_message
    enabled: true
    visibility: internal

  2. Trigger a policy violation on a merge request in a project scoped by that policy.

  3. Confirm the bot's violation comment is created as an internal note (visible only to project members with at least the Reporter role).

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.

Merge request reports