How can I disable specific modules in Hudson without modifying the committed pom?

I'm using Hudson for a huge java project. 2 teams are involved on the project, making breaking the build very sensible and reports of failing unit tests or build breaks must be triggered as fast a possible! To achieve that, we are using one daily continuous build that is triggered very often and is just running the "clean test" goals on changed modules only and on thei开发者_如何学Cr dependencies.

This is fine but not enough, the build is still too slow and I would like to deactivate some modules that are running integration test at the end of the build process and that are not relevant for the "hourly" work, especially for the team working on the UI part.

Is there a way to configure Hudson to disable some modules without hacking the pom files?

"This is fine but not enough, the build is still too slow and I would like to deactivate some modules that are running integration test at the end of the build process"

I would buy these teams a good maven book. The integration tests are not supposed to be in the test goal.The integration test belong into the integration-test lifecycle phase.

If these teams are not willing to adhere to the standard it is time to kick their tush. Sorry for the direct language but you only ask for trouble by not adhering to a standard, without a significant reason. I have to do that once in a while too, but it usually ends in sink or swim. Mostly for the developers, sometimes me. :(

As far as I know Hudson/Jenkins only executes your build files, I think is not on CI's scope to deal with project customization.

So for me hacking the POM files seems to be the only choice.

Another way to speed things up is to only build the modules that change (as those that haven't will still be in your local or enterprise repo from last time).In the advanced build configuration for a Maven project, there is the option: "Incremental build - only build changed modules", which does this. Excluding modules that have changed just because they have integration tests seems quite dangerous. As really, the whole point of CI is to build as soon as you can after a change.

What you could do, which shouldn't involve too much change though is to split your tests into slow and fast using a technique such as build profiles. E.g. less that 1 sec is fast. It is easy enough to split them up like this and will also high-light to the Devs which are the slow tests. You could then create a chain of builds so that the fast builds run first giving the developers feedback in the fastest time possible. If that build succeeds it can trigger the slower tests, still giving feedback in the minimum reasonable time. These tests still add value and should be run as frequently as possible.

If you do decide to chain your jobs, have a look at the build pipeline plugin which was set up for kind of scenario.