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.