-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Speed up spring-boot-server-tests #25457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is beautiful, Christoph. Thanks very much. |
Unfortunately, this has made Windows grumpy. I think the problem, or at least part of the problem, is that the processes are still running when we attempt to clean up the jar files. I'm hopeful that destroying the processes and then clean up the temp dir will fix it. |
@wilkinsona I'm very sorry - I don't have a Windows machine anymore to test against :/ |
@dreis2211 A wise man once said to me not to worry about breaking some tests… Seriously, please don't worry about it. These things happen after all. I reviewed the changes and it didn't occur to me that it'd cause grief with Windows. |
I saw it's still failing...what about bypassing the cache on Windows as a last resort? |
The Windows builds only run daily unless we trigger them manually so they hadn't run with my latest tweak. I've just triggered a 2.3.x Windows build 🤞. |
The build passed with Thanks again for the changes, @dreis2211. That's a very welcome reduction in the build time. |
Thank you for tackling the Windows stuff 🙏 |
Hi,
this PR improves the build time of
spring-boot-server-tests
by applying some caching in certain places. Specifically:ApplicationBuilder
s, which avoids packaging the JAR (or WAR) for each test invocation. With the cache the packaging now only run once per container and packaging method (e.g. Tomcat & JAR or Undertow & WAR)The second cache is a bit more aggressive and has the implication that the started processes can only be killed after all tests are run. Unfortunately, I found no way to make this a little cleaner in JUnit 5 as the
TestTemplateInvocationContext(Provider)
mechanism only works on the single test invocation level. The same applies to the exposed additional extensions in those contexts, which theAbstractApplicationLauncher
is.On my local machine the new approach reduces the time for testing from almost 8 minutes to roughly 1:30-2 minutes. The bigger part of this comes from the launcher cache, because we don't have to pay the 3-4 second application startup time hit on every test invocation.
Let me know what you think.
Cheers,
Christoph