[go: up one dir, main page]
Skip to content

Improve reporting for when a merge request is merged via another MR

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Show in the API whether a merge request was merged manually or via another merge request, and provide details about the related merge request that caused the merge when applicable. This improves compliance tracking and auditing capabilities for organizations that need to ensure proper code review processes.

Problem to solve

Currently, while the GitLab UI shows whether a merge request was "merged manually" or "merged via MR", this information is not available through the API. Organizations that need to audit their merge request processes cannot programmatically verify if merge requests were properly reviewed and approved before being merged, especially in cases where one merge request is automatically merged due to another merge request being merged.

As a compliance manager, I want to be able to query through the API whether a merge request was merged manually or via another MR, so I can ensure our code review policies are being followed and all changes have proper approvals.

Intended users

User experience goal

The user should be able to use the API to determine how a merge request was closed (manually merged or merged via another MR) and access information about any related merge requests that caused the merge, similar to the information already shown in the GitLab UI's activity feed.

Proposal

User can infer the following once we expose those fields:

  • When the state is merged and both source_merge_request_id and source_commit_id are nil: This MR is merged via UI
  • When the state is merged and source_merge_request_id is not nil: This MR was marked as merged because of the MR source_merge_request_id points to
  • when the state is merged and source_commit_id is not nil. This MR was marked as merged because it was manually merged

Further details

Use cases:

  • Compliance teams need to verify that all merged code has received proper review and approval
  • Organizations want to audit their merge request processes
  • Teams need to track how code changes are making it into their main branch
  • Release managers need to verify proper release procedures are being followed

Benefits:

  • Improved compliance monitoring and reporting
  • Better visibility into merge request workflows
  • Easier automation of merge request auditing
  • Reduced manual work in verifying proper code review processes

Permissions and Security

Existing merge request permissions would apply to this feature:

  • No impact to members with no access (0)
  • Reporter (20) and above can view this information through the API
  • No changes needed to existing permission model

Documentation

The following documentation updates would be needed:

  1. API documentation to describe the new fields and endpoints
  2. Update to the merge request documentation to describe how merge attribution is tracked
  3. Examples of using the API to audit merge request processes

Availability & Testing

Testing requirements:

  • Unit tests for new API fields and system notes
  • Integration tests for merge request workflows
  • End-to-end tests verifying proper attribution in different merge scenarios

Available Tier

  • Free
  • Premium/Silver
  • Ultimate/Gold

This feature should be available in Free tier and above

Feature Usage Metrics

Track:

  • Number of API requests for merge request attribution information
  • Distribution of merge methods (manual vs via MR)
  • Usage of this information in compliance reports

What does success look like, and how can we measure that?

Success metrics:

  • Adoption rate of the new API fields by Premium+ customers
  • Reduction in support tickets related to merge request attribution queries
  • Customer feedback about improved compliance monitoring capabilities

What is the type of buyer?

This feature targets the Security & Compliance buyer persona, particularly in regulated industries where code review processes must be strictly followed and audited.

Is this a cross-stage feature?

No, this feature primarily affects the Create stage group, specifically the Source Code sub-category.

What is the competitive advantage or differentiation for this feature?

This feature strengthens GitLab's position in enterprise environments where compliance and governance are critical requirements. It demonstrates GitLab's commitment to supporting complex organizational requirements around code review processes and compliance.

Links / references

Related tickets:

Edited by 🤖 GitLab Bot 🤖