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
