Hey Stan, I also experienced this, some of the tests indeed take a long time. As an immediate workaround, do you think we can enforce a global timeout of let's say 10 minutes? I don't know if these are taking a long time because of some race condition or because of the lack of resources and probably would need to investigate them individually, but a test case shouldn't run for more than a couple of minutes.
As a bit more of a strategic solution, I can imagine that we could run only the tests of only the changing module and the others which are functionally dependent on it. For instance we still likely need to run all tests for a client or core change (as they can affect other parts of the project) but we may need to run only connect and mm2 tests if the change is in connect, or only mm2 tests if the change is in mm2. Best, Viktor On Tue, Dec 19, 2023 at 3:33 PM Stanislav Kozlovski <stanis...@confluent.io.invalid> wrote: > Hey everybody, > I've heard various complaints that build times in trunk are taking too > long, some taking as much as 8 hours (the timeout) - and this is slowing us > down from being able to meet the code freeze deadline for 3.7. > > I took it upon myself to gather up some data in Gradle Enterprise to see if > there are any outlier tests that are causing this slowness. Turns out there > are a few, in this particular build - > https://ge.apache.org/s/un2hv7n6j374k/ > - which took 10 hours and 29 minutes in total. > > I have compiled the tests that took a disproportionately large amount of > time (20m+), alongside their time, error message and a link to their full > log output here - > https://gist.github.com/stanislavkozlovski/8959f7ee59434f774841f4ae2f5228c2 > > It includes failures from core, streams, storage and clients. > Interestingly, some other tests that don't fail also take a long time in > what is apparently the test harness framework. See the gist for more > information. > > I am starting this thread with the intention of getting the discussion > started and brainstorming what we can do to get the build times back under > control. > > > -- > Best, > Stanislav >
