Continuous builds for OpenJDK

[Kelly O'Hair]

Jesse Glick wrote:
> David Herron wrote:
>> I would be happy to have more quality metrics like findbugs results
>> to publish on the site.
> 
> On that note, has anyone set up or thought about setting up a public 
> continuous builder for OpenJDK, e.g. using Hudson? This would ensure 
> that the codeline is still buildable (of course), and could show test 
> status, show FindBugs metrics, permit downloads of snapshot builds, etc.

Last I looked, Hudson did not support building native code on all 8
basic platforms, and more platforms if you want to include all the various
Linux flavors.

Having the OpenJDK build on just one platform is valuable, but not
really very re-assuring when it's so easy to break native code when using
all the different architectures and C/C++ compilers we use.

The findbugs issue doesn't get any better with Hudson, not sure how
it can help when it takes 12+hours to run findbugs on the jdk.

Hudson is a great tool, but I think it's sweet spot is the typical
Java project or product, built with a build.xml file and with
little or no native code.

> 
> One issue with Hudson is that it does not yet support the Forest 
> extension in its Mercurial plugin. You can 'hg fpull -u' in your build 
> script to do the update, but then the changelog will only show changes 
> in the root tree, and polling will not work correctly. Probably fixable 
> in the plugin; or it might just be better to set up a separate job for 
> each tree, assuming these components can be built meaningfully in 
> isolation (definitely true for langtools). You can also have 
> "downstream" jobs, so it would be possible for a jdk job to use binary 
> artifacts from the most recent successful build of a hotspot job, 
> assuming the makefile supports this scenario.

We have an in-house build/test system for the jdk called JPRT, which we hope to
open source, but it requires all the various platform client hardware.
The JPRT principle is based on a distributed SCM model, where
all the builds on all the platforms are guaranteed successful before the
changes ever get pushed to any shared repository.
This is different than doing a continuous build, which detects when an area
won't build and raises alarms when a shared repository fails to build.
JPRT works on a 'on-demand' job request from a user needing to push changes,
the shared repository is always guaranteed to build.

-kto