Hi, I think the tests are not integration tests, but are extensive in their coverage, often with sleeps.
If the build system/code structure could be setup in a way that when we make a change only those modules that depend on the change get built and tested, that would be much better. I don't think Maven can currently do that in a multi-project (?). Another approach is to do something similar to the workflow in most GitHub projects where Travis builds almost everything on every trigger including pull requests. eg [1]. Not sure if that's possible using the Apache SVN infra, or if it fits the CTR workflow, but it does save local build cycles. Best Regards Ian 1 https://github.com/swagger-api/swagger-codegen/pull/2351 On 11 March 2016 at 09:46, Radu Cotescu <[email protected]> wrote: > Hi Olli, > > I think it's dangerous to build only the changed modules as most of them > export API and provide implementations consumed by the other bundles from > the launchpad. Sometimes, although the API stays compatible, the > implementation might subtly change and produce havoc. > > I guess the suggestion to bind all integration tests (which are definitely > slower than unit tests) to the integrationTests profile, that's not > activated by default, makes more sense. > > Cheers, > Radu > > On Fri, 11 Mar 2016 at 10:37 Oliver Lietz <[email protected]> wrote: > > > On Friday 11 March 2016 10:19:13 Bertrand Delacretaz wrote: > > > Hi, > > > > Hi, > > > > > Here are typical times on my box for a full "mvn clean install" build, > > > first a few modules that take more than a minute: > > > > > > [INFO] Apache Sling Discovery Commons ..................... SUCCESS > > [03:30 > > > min] [INFO] Apache Sling Health Check Core ..................... > SUCCESS > > > [01:08 min] [INFO] Apache Sling Sample Integration Tests .............. > > > SUCCESS [01:21 min] [INFO] Apache Sling JCR Installer > > > ......................... SUCCESS [01:53 min] [INFO] Apache Sling > > > Validation Framework Integration Tests FAILURE [01:01 min] [INFO] > Apache > > > Sling Launchpad Testing ..................... SUCCESS [02:43 min] > > > > > > And then the really bad ones which add up to enough time for a (quick) > > > barbecue: > > > > > > [INFO] Apache Sling Resource-Based Discovery Service ...... SUCCESS > > [21:12 > > > min] [INFO] Apache Sling Oak-Based Discovery Service ........... > FAILURE > > > [57:18 min] [INFO] Apache Sling Event Support ......................... > > > SUCCESS [09:02 min] > > > > > > Do we agree that this second category is bad? > > > > > > I suppose the result is that people rarely or never run a full build > > > with tests - IMO the full build should be coffee break compatible, so > > > around 10-15 minutes. > > > > > > I haven't looked in detail yet at the second category above, does > > > someone familiar with those tests have suggestions? > > > Reduce the number of iterations unless a specific Maven profile is > > active? > > > Create a JUnit SlowTests category? > > > > are these slow tests really unit tests or integration tests? We already > > have a > > profile integrationTests which could be used to run (more) slow tests. > > IMHO we should stop doing full builds and only build modules which have > > changed. > > > > Regards, > > O. > > > > > -Bertrand > > > > >
