Skip to content

Label System

Auto Merge manages MR labels declaratively using a desired-state model. It computes the target label set for each MR and applies only the diff.

Applied automatically based on MR state. All Auto Merge labels are prefixed with 🚌 ➤ for easy identification.

Label in GitLabMeaning
🚌 ➤ Mergable ✓Ready to merge (pipeline passed, approved)
🚌 ➤ Next Up 🎯Next in the merge queue, will be merged once pipeline passes
🚌 ➤ Waiting for CI ⏳Pipeline running or pending
🚌 ➤ Rebase required 🛠️Needs rebase onto target branch
🚌 ➤ Rebasing ♻️Currently being rebased by Auto Merge
🚌 ➤ Rebase Failed ⚠️Automatic rebase failed, manual intervention needed
🚌 ➤ Conflict ⚔️Has merge conflicts
🚌 ➤ Todo 🚧Unresolved discussions or failed pipeline
🚌 ➤ Not Approved 🤔Waiting for approval
🚌 ➤ Empty ⬜MR has no commits
🚌 ➤ Merged 🎉Successfully merged by Auto Merge

Each MR has exactly one status label at any time.

Approved MRs waiting to merge receive a queue position label showing their place in the merge queue (e.g., 🚌 #1, 🚌 #2, 🚌 #3). Positions update automatically as MRs are merged or reprioritized.

These labels are set manually by developers and never added or removed by Auto Merge.

🚌 ★ Important ⚡ — prioritizes an MR. Effects:

  • Processed before other MRs of the same status
  • Lower-priority pipelines may be cancelled when runners are scarce

LowPriority — deprioritizes an MR. Effects:

  • Processed only when no other MRs are queued
  • Sorted after all regular MRs in the merge queue

🚌 ★ No Cancel 🛡️ — protects an MR’s pipeline from automatic cancellation. Useful for pipelines that must run to completion regardless of priority.

Draft MRs receive special treatment:

  1. Running pipelines are cancelled
  2. All Auto Merge labels are removed
  3. Excluded from merge queue and rebase

When marked as ready, the MR re-enters normal processing.

  1. MR is opened or updated
  2. Auto Merge categorizes the MR (approved? pipeline status? conflicts?)
  3. Desired labels are computed
  4. Diff between current and desired labels is applied
  5. Old status/queue labels are removed, new ones added

This desired-state approach prevents label flickering that would occur with imperative add/remove logic.