opensearch-project / opensearch-project/sql

[RFC] Enable Merge Queues

Open
#3,606 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

infrastructure RFC
Dominant language
Java
Stars
176
Forks
229
Avg merge
2d 21h
Merged PRs (30d)
43

Description

Problem Statement
Inspired over the past year by Tyler Cipriani's post and using them on other projects: we currently don't have any post-merge protection for our branch. This causes issues with merge skew: two colliding PRs can cause a failing main branch (while passing individually).

Merge queue example: without queues, branches A and B may pass but A+B fails. With queues, B will be tested as A+B instead.

Current State
Because we don't have this protection, we're pretty regularly susceptible to main breaking due to external factors or collisions. If we wanted to be safe, we would need to effectively manually do the same thing as a merge queue: rerun tests right before merging. When we do this, it causes a lot of time to be spent waiting synchronously on CI.

It also means that there's a natural incentive to "just merge," and ignore CI entirely. It's up to maintainer discipline whether the tests always pass or not.

Proposal
We can enable merge queues for our repos (sql and opensearch-spark). Doing this will:

  • Enable us to more confidently merge PRs while protecting the main branch.
  • Speed up merging: the queue can be run in parallel.
  • Guarantee that main is always passing tests.
  • Incentivize fixing flaky tests, as these will have a greater visible impact in the queue.
  • Prevent instances of accidentally merging PRs with failing tests.

The primary drawback is: the queue can get blocked if tests start failing for unrelated reasons (e.g. dependency change). It's up to the team whether we want to prioritize always passing tests, or avoiding the inconvenience of waiting on patches for upstream breakage. There's a permissions role that lets you override the merge queue in an emergency. (There are other shortcomings of GitHub's implementation, but I generally don't consider them significant enough to block implementing this.)

Implementation Discussion
We submit a request to the Org's .github. From there, all we need to do is add a merge_group: trigger to relevant CI actions (most obviously the tests, possibly other actions too). Then the queue will be active for all merged PRs.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked OpenSearch Project .github request and the repository's relevant CI actions, especially the test workflows. Confirm which actions need a merge_group trigger and verify that the merge queue is active for merged PRs in both sql and opensearch-spark.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, devops
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.