Uchechi, While the build queue can run the builds concurrently, each build is cumulative.
For example, A, B, and C are added to the queue and A causes a problem for C. Merge Queue: A, B, C Suppose we have concurrent builds and batching turned on. We might end up with two builds for these three PRs: Build 1: trunk + A Build 2: trunk + A + B + C Each build is going to be cumulative. The point of the concurrency is so we don't have to wait for an in-progress build to finish before we start validating new PRs from the queue. In this case, build 2 would fail and PRs B and C would get kicked back to the authors. As you can see, the batching and concurrency can complicate matters a bit which is why I suggest we start with no batching or concurrency. Hope this helps! David A On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <ukpauchec...@gmail.com> wrote: > Hi David, > > Thanks for this and for your work improving the Kafka CI. > > I have a question: > > A problem was mentioned about two PRs acting against each other when > there’s no delay and being merged concurrently. Wouldn’t this still happen > in the queue with concurrent merging as well? > Best Regards, > Uchechi. > > On Fri, 24 Jan 2025 at 03:35, David Arthur <mum...@gmail.com> wrote: > > > Greetings, Kafka community! > > > > At long last, the GitHub Merge Queue is upon us. This is a feature that > > many of us have wanted for quite a while. After many months of > discussion, > > the excellent ASF Infra team has delivered! > > > > Since this is quite a significant change, I have written up the details > as > > a KIP. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue > > > > Please let me know what you think. > > > > -- > > David Arthur > > > -- David Arthur
