Add Audit Event for "Pipelines Must Succeed" setting

Summary

Add audit events for changes to merge request merge checks, including Pipelines must succeed and related settings, at the group, subgroup, and project levels.

Problem to solve

Today, changes to merge request merge checks (for example, enabling Pipelines must succeed at the group level) can immediately block merges across many projects. When this happens:

  • Audit Events do not show who changed these settings or when.
  • Customers can only discover the change via internal logs (Kibana / Rails logs), which they do not have access to.
  • This makes it hard for compliance, security, and platform teams to understand:
    • Who modified the merge behavior.
    • When the change happened.
    • What the previous and new values were.

For GitLab.com Ultimate and self-managed customers with strict change-control requirements, lack of auditability for merge-blocking settings is a compliance gap.

Intended users

  • Primary: Group / instance administrators, security, compliance, platform engineering.
  • Secondary: Team leads and project maintainers who need to understand merge policy changes.

Proposal

Add audit events whenever merge request merge-check settings are changed at any scope (group, subgroup, project). At minimum, include:

Settings to track (examples from namespace_setting / MR settings UI):

  • only_allow_merge_if_pipeline_succeeds (Pipelines must succeed)
  • allow_merge_on_skipped_pipeline (Pipelines must succeed + allow merges when pipeline is skipped)
  • only_allow_merge_if_all_discussions_are_resolved (All threads must be resolved)
  • Any other settings in the Merge requests section that change:
    • Whether a merge is blocked or allowed.
    • What conditions must be met before a merge can proceed (for example, future additions like extra checks, AI-based code review toggles, etc.).

Where audit events should appear:

  • Group and project Audit Events pages.
  • Instance-level Audit Events (for self-managed / Dedicated).
  • Included in Audit Event Streaming so customers can consume these changes in external SIEM / logging tools.

User experience goal

Admins and auditors should be able to answer, using only Audit Events (UI or streaming):

  • “Who enabled Pipelines must succeed for this group/project, and when?”
  • “What were the previous settings, and what are they now?”
  • “What other merge-blocking conditions changed around the same time?”

No access to internal logs or support tooling should be required.

Further details / considerations

  • Scopes: Changes made at group, subgroup, and project levels should each emit events at their respective scopes, following existing audit-event scoping patterns.
  • Batch updates: When multiple MR settings are changed in one request (as in the existing Rails controller behavior), emit a single audit event with a changes hash that includes all modified keys.
  • Future-proofing: Implementation should be resilient to future additions of merge-related settings in the same controller/service, so that new merge-blocking flags automatically get audit coverage (or are easy to add via a single allowlist).

Permissions and Security

  • Only users who can currently view Audit Events for the relevant scope should see these events.
  • Event contents should not include sensitive data beyond configuration values and actor metadata.

Documentation

Update:

  • Audit Events documentation to list:
    • New event name(s) and example payloads.
    • Scopes where they appear (instance, group, project).
  • Merge request configuration / Pipelines must succeed docs to mention that changes are captured in Audit Events for compliance tracking.
Edited by 🤖 GitLab Bot 🤖