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

Reply via email to