HI Maxim, sry I'm kind of distinguish in my build time and parameters between local and on Jenkins. I think both matters.
Local: I think we all agree it needs to run quickly. Ability to run inside Eclipse embedded Tomcat: - This was always difficult because of Red5. Now its just an Apache Wicket webapp. So it should get easier. - It might be easier for new developers to learn this, like using existing IDE functionality to deploy/run-debug quickly - Maybe Tomcat/Eclipse integration also got better over last 5+ years :) I think I'm keen to explore this a bit over the coming weeks. But I'm really also looking at Jenkins build time. Reasons: - If we want to get more PR requests and contributions from new committers we need to efficiently be able to quickly assess them - Nobody wants to wait 45min to 1+ hour to figure out your build has passed - We should be adding more automated unit AND UI end-to-end tests. But if the build starts to take 45min to 1h+, then developers get reluctant to see the value in automated tests. As they probably can do a manual test faster than doing an automated one and wait for the build to complete. So in order to make sure the value in automated testing is understood, keeping build time low on Jenkins/CI-CD really matters too So I think both matters. If we want to scale up the process for more developers, more automated tests, than adding some efficiency in local and automated tests will help us to grow the project. Cheers Seb Sebastian Wagner Director Arrakeen Solutions http://arrakeen-solutions.co.nz/ <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> On Tue, 12 May 2020 at 00:23, Maxim Solodovnik <[email protected]> wrote: > > > On Sun, 10 May 2020 at 06:06, [email protected] <[email protected]> > wrote: > >> We are using some tricks like -pl modules builds. However it is still a >> bit of a waiting game. And hard to understand for anybody new and >> would-like-to-be contributor. >> > >> I think its good we removed some of the unused references to red5-libs. >> > > this is done already > And I doubt it takes significant time (and usually not being built with > `quick` profile) > > >> >> But are there more things we can do to speed up build time? >> >> Looking at: >> >> https://builds.apache.org/view/M-R/view/OpenMeetings/job/openmeetings/3200/ >> >> *openmeetings-utils roughly 9min* >> I don't quite understand why openmeetings-utils takes ~9min ? What is it >> doing? It only runs 1 test. Is it trying to fetch the -SNAPSHOT >> dependencies and timing out on each ? >> > > The time is consumed by SecureRandom initializing in tests > this can be reduced by using fast `-Djava.security.egd=file:/dev/./urandom` > Tests can be skipped al together while developing ... > > >> >> *openmeetings-web tests 19min* >> I think we can't sacrifice tests. We should in fact add more not less. >> But is there any ideas how we can cut down the execution time ? >> Is there any re-use between tests using AbstractWicketTester and restarts >> of OpenMeetings instances ? >> > > `-DskipTests` > No need to modify build for this > > >> >> *Any maven-modules that can become stand-alone jars* >> Like openmeetings-webservices. Seems rather stable and hardly ever >> changes. Could this be an actual repository and own build and managed as >> dependency. Rather then being in same repo ? >> Or other packages that hardly get touched like openmeetings-install or >> openmeetings-db? >> Or other ways of splitting it. >> I understand there is some advantage in having it all in Eclipse Project. >> But practically some of those modules are not touched for months. And they >> just chew up another 3,4,5 minutes on every build you sit there waiting. >> > > You can skip unnecessary modules with quick build > Most changes are applied with `hot-code-replace` while Eclipse is attached > and doesn't require any re-builds > > Most probably it is possible to find faster way using internal web server > integrated into IDE, but I haven't investigate this for a long time ... > > >> >> Cheers >> Seb >> >> Sebastian Wagner >> https://www.linkedin.com/in/sebastianwagner/ >> >> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >> > > > -- > Best regards, > Maxim >
