Merge queue implementation in azure

[siva228666]

Body

Objective:
Handle failed PRs in a custom merge flow without blocking other valid PRs.
Requirements:
Automatically detect failed PRs based on:
CI failures
Required checks not passing
Policy validation failures
Merge conflicts
Remove/eject failed PRs from the queue without blocking the lane.
Re-queue and merge remaining valid PRs in order:
Respect priority/labels
Apply retry/backoff logic for transient failures

Guidelines

• I have read and understood this category's guidelines before making this post.

[pratikrath126]

You can implement a custom merge queue using Azure Functions or GitHub Actions with a backing store (e.g., Azure Table Storage, Redis, or even GitHub Issues as a queue). Here's a high-level approach:

1. Trigger on PR events (opened, synchronized, review completed) via GitHub webhook.
2. Enqueue the PR with metadata (branch, priority, required checks).
3. Worker process pulls PRs from the queue sequentially:
   • Use GitHub API to verify all required status checks are passing.
   • Check for merge conflicts (try a merge via API or use git merge-base).
   • If checks fail or conflicts exist, eject the PR from the queue (remove it) and continue to next.
   • If passing, merge the PR via API.
4. Retry logic: For transient failures (e.g., CI flakiness), re-queue the PR with exponential backoff (e.g., delay 5min, 15min, 30min) up to N attempts.
5. Priority: Implement multiple priority queues (high/normal/low) or use a priority score in your store.

Useful APIs:

• GET /repos/{owner}/{repo}/commits/{sha}/status to check combined status.
• GET /repos/{owner}/{repo}/collaborators/{username}/permission if needed.
• Merge via PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge.

Considerations:

• GitHub's native Merge Queue (available for GitHub Enterprise) may already meet your needs.
• Azure Logic Apps can orchestrate this with minimal code.
• Ensure idempotency and logging for audit.

Would you like more specific guidance on any part?

[Thiago-code-lab]

Hi @siva228666,

Adding to @pratikrath126's excellent suggestions, if you decide to build this custom engine on Azure, I highly recommend using Azure Durable Functions.

Since your requirements include retry/backoff logic and sequential processing, a standard stateless Azure Function might struggle with timeouts during long waits. The Durable Orchestrator pattern fits this perfectly:

Smart Retries: You can use context.createTimer within the orchestrator to implement your exponential backoff (wait 5m, then 15m) without keeping a server active/billed during the wait.

Queue Management: The orchestrator can serialize the merges. If a PR fails validation (CI/Policy), the function can simply "return" (ejecting it from the logical flow) and immediately trigger the processing of the next PR in the list.

One check before you build:
Does your organization have access to the GitHub Native Merge Queue (available on Team and Enterprise plans)?
It is designed exactly for this "non-blocking" requirement—it creates a temporary branch for validation and automatically ejects failing PRs so they don't block the rest of the queue, requiring zero custom infrastructure.

[dbuzatto]

You can implement this using GitHub webhooks + an Azure-backed queue processor.

High-level approach:

1. Listen to PR events

   • pull_request
   • check_suite
   • status
   • pull_request_review

2. Enqueue PR metadata
   Store:

   • PR number
   • Target branch
   • Required checks status
   • Retry count
   • Current state

   Use Azure Table Storage, Service Bus, or Redis.

3. Single worker per branch
   An Azure Function processes PRs sequentially:

   • Revalidate required checks
   • Check mergeability via GitHub API
   • Verify required approvals
   • Merge if valid
   • If failed:
     • Remove from queue (policy/conflict)
     • Retry with backoff (transient CI failure)

4. Always revalidate before merge
   Prevent race conditions and stale status issues.

Key principle:
👉 One processor per branch + strict revalidation + state tracking.

If you're on GitHub Enterprise Cloud, also check whether native Merge Queue fits your needs before building custom logic.

[pankajrawat24]

Hi,

What you’re describing is basically a non-blocking merge queue, where a bad PR gets skipped instead of blocking the whole lane — and that’s totally doable, but it requires a small orchestration layer on top of GitHub.

How you can design it

At a high level, you need three pieces:

1. Queue of PRs (ordered by priority/labels)

Store PRs with metadata like:

• priority / labels
• retry count
• last validation status

2. A processor that handles one PR at a time per branch

This worker should:

• Pull the next PR in order
• Re-validate everything just before merge:
  • required checks
  • policy validations
  • merge conflicts
  • approvals (if needed)

3. Decision logic per PR

• ✅ If everything passes → merge
• ❌ If permanent failure (policy, conflicts) → eject from queue
• 🔁 If transient failure (CI flake) → requeue with backoff

---

Handling the “don’t block the lane” requirement

The important part is:

Never let one failing PR block the queue

So your processor should always:

take next PR → validate → 
    if invalid → remove it → move to next
    if valid → merge → move to next

This keeps the lane flowing.

---

Retry / backoff strategy

For CI-type failures, add something like:

• attempt 1 → retry after 5 min
• attempt 2 → retry after 15 min
• attempt 3 → retry after 30 min
• after N attempts → eject from queue

That way flaky checks don’t permanently block the PR, but also don’t loop forever.

---

Implementation options

You can implement this using:

• GitHub Actions + a queue (Redis / DB / even issues as state)
• or an external worker (Azure Functions, Node service, etc.)

Events you’ll likely listen to:

• pull_request
• status / check_suite
• pull_request_review

And for validation you’ll rely on the GitHub REST API:

• check combined status
• check mergeable state
• perform the merge

---

One thing to consider first

Before building this from scratch, check if your org can use GitHub Merge Queue.
It already handles:

• temporary merge branches for validation
• automatic ejection of failing PRs
• non-blocking sequencing

If it fits your workflow, it saves a lot of engineering effort.

---

TL;DR

Yes — you can build this, but the key ideas are:

• single sequential processor per branch
• always re-validate before merge
• eject invalid PRs immediately
• retry only transient failures with backoff

That gives you a safe, non-blocking merge lane.

[Navyansh999]

In short, the key is: automated status detection → auto-eject failed PRs → sequential revalidation → ordered merge with retry logic.

[Jamonygr]

For Azure DevOps, I would model this as a small orchestration service rather than trying to make one pipeline responsible for the whole queue.

The service can watch pull request status through service hooks or scheduled checks, then use branch policies and build validation as the source of truth. When a PR fails CI, hits a policy issue, or has merge conflicts, the service can mark it as blocked, leave a clear comment for the author, and continue with the next valid PR.

That keeps the queue moving without hiding failures. It also gives you a place to handle priority labels, retry logic for temporary failures, and audit logging. The most important part is that every automated decision should be visible to the team, so authors understand why a PR was removed from the lane and how to re-enter it.