Track merge request retarget events

Kai Armstrongrequested to merge
feature/track-mr-retarget-event into master

What

Fire an internal event each time a merge request is automatically retargeted because its target branch was deleted, which typically happens after a stacked dependency MR is merged (Feature B → Feature A → main; merging A retargets B to main).

Adds:

  • A new internal event, retarget_merge_request_on_target_branch_merge.
  • A total counter metric (7d / 28d / all) at counts.count_total_retarget_merge_request_on_target_branch_merge.
  • The track_internal_event call inside the existing target_branch_was_deleted branch of MergeRequests::UpdateService. This is the only code path that runs on auto-retarget, so the event fires exactly once per retargeted MR and is not coupled to the system-note text.

Why

We currently have no analytics on how often the automatic retarget flow fires on GitLab.com. This event gives us a foundation for measuring stacked-MR workflow usage and any future iteration on it.

How was it tested?

  • Extended the existing target_branch_was_deleted context in spec/services/merge_requests/update_service_spec.rb with trigger_internal_events + increment_usage_metrics assertions.
  • Added a negative assertion that a normal target-branch change does not fire the event.
  • spec/lib/gitlab/internal_events/event_definitions_spec.rb and spec/lib/gitlab/usage/metric_definition_validate_all_spec.rb validate the new YAML files.

Coverage / known limitations

  • The retarget chain runs only when the merged MR's source branch is being deleted (MergeRequests::DeleteSourceBranchWorker → MergeRequests::RetargetChainService). Merges that leave the source branch in place are out of scope and won't emit this event.
  • RetargetChainService caps work at MAX_RETARGET_MERGE_REQUESTS = 4. MRs beyond that cap are silently skipped by the existing code and won't appear in the metric.

Merge request reports