| Re: [platform-releng-dev] platform HIPP - running the tests? |
|
On 11/09/2013 04:22 PM, Stephan
Herrmann wrote:
I was pleasantly surprised to see that hudson is already doingI've sent a mail on the same mailing list some weeks ago telling that Gerrit was now enabled http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg21628.html . However I did not mention it's using only module build with -Pbuild-individual-bundles. This mail also also speaks about the current issues with automated tests with Tycho and how to handle a +1 or a -1 vote from Hudson on a Gerrit patch. Tests are disabled by default: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-platform-parent/pom.xml#n19 . You can override that locally by and run tests by using the following command line: $ mvn clean verify -Pbuild-individual-bundles -Dmaven.test.skip=false -DskipTests=false Most of the test are working well with surefire, but some have some assumption that don't apply to surefire and needs some tweaks, either in test code or in surefire configuration (for example to add a dependency). Here is the umbrella bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 and the one for JDT Core: https://bugs.eclipse.org/bugs/show_bug.cgi?id=417026 This would be awesome and even I as a committer would switchAs soon as tests are working with surefire, jobs can simply be changed to set the properties as explained above, so tests will be run and taken into account for vote. Note that if we can do it with Hudson, it means that you'll also be able to run tests locally. Without the tests I see little benefit - and contributers mayHudson vote is not enough for accepting a change, it also requires a manual review. Hudson voting +1 means to the reviewer that it's worth looking at the review. Hudson voting -1 means that it's not even necessary to look at the code, because this patch is bad anyway. This is already true for checking compilation errors, and this will be still true when tests will be enabled. Hudson itself is nothing but an indicator, it's not a guarantee of a good stuff. When it comes to compilation errors, it can happen that someone have only a single project open in Workspace and make breaking changes without noticing the impact on other bundles, which are absent or closed. So some compilation errors can be missed in workspace. And in general, the value of Gerrit is not in the automated vote from Hudson, but more in the ability to review and discuss about code more easily and handle a "lifecycle" for a patch. Cheers. |