| [platform-dev] HIPP for Platform + Hudson votes on Gerrit |
|
Hi all, I recently requested a Hudson instance (called HIPP) for Platform: https://bugs.eclipse.org/bugs/show_bug.cgi?id=417030 Here it is: https://hudson.eclipse.org/platform/ It contains: * The Platform-Sonar job (which is failing because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 , requires changes in almost all pom.xml for tests, and also in some code which expects running in a full Eclipse distro whereas Tycho uses a minimal target platform) * Some *-Gerrit job for each repository. == How to use Gerrit jobs? These jobs are active and will vote +1 or -1 on any Gerrit contribution: if build is green, Hudson votes +1; if not it will vote -1. The command line which is used it "mvn clean verify -Pbuild-individual-bundles -Dmaven.test.skip=true". Just continue to use Gerrit, and you'll see Hudson chatting with you to say what he thinks about this contribution. A "-1" on a contribution should mean a compile or build issue, so it's a blocker for a contribution to be merged. It can be interpreted as a blocking issue for a human review: if Hudson says no, it's too early to review the code, you can tell the contributor "Please make Hudson happy, I come back after that". A "+1" means that the change doesn't break compilation, it's a good starting point to review the contribution. == What's next? It would be nice to have test running with Tycho ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 ), so we could switch the -Dmaven.test.skip to false for all these *-Gerrit jobs. As a consequence, Hudson would run tests, and vote -1 if build fails or a test fails, and +1 if everything is still green. This gives some more trust in the contribution and reduce the risk of merging something bad. Then, when we have all tests running with Tycho, it will also be easy to add some fun metrics such as code coverage. == Goals * Decrease amount of erroneous commits (always using Gerrit should show almost any change that breaks the build) and consequently failed builds * Ease contribution reviews by spotting bad changes automatically * Give immediate feedback to lazy contributors who don't want to build locally. They can push to Gerrit and see what will happen (it's not a very good workflow, but it appears to be helpful for many people) Hopefully, all this leading to better productivity, more contributors, better code quality and so on... == Limitations * https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 makes that those jobs can't run tests * This appraoch uses the last integration build to resolve dependencies, so it won't detect breaking changes between 2 components immediately. Such change needs to wait for next I-Build to be cascaded to other components using them. Cheers, |