Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 (original) (raw)

Martijn Verburg martijnverburg at gmail.com
Wed Dec 4 10:00:57 PST 2013

+1 - we're hoping to start running some basic CI infrastructure Q1 next for the hackdays we run (typically a number of small patches come out of it that we want tested before we go bothering reviewer's time).

Cheers, Martijn

On 4 December 2013 17:36, Jeremy Manson <jeremymanson at google.com> wrote:

This may not be the thread to bring up this topic, but, AFAIK, external contributors still can't run JPRT. I guess that doesn't really change the need to run it as part of continuous integration, but it makes it slightly more frustrating to contribute.

Perhaps making it available externally could be done together with whatever jiggering is required to get it integrated into the continuous testing? Jeremy

On Wed, Dec 4, 2013 at 8:31 AM, serguei.spitsyn at oracle.com <_ _serguei.spitsyn at oracle.com> wrote: > +1 > I was about to ask similar questions related to hotspot integrations > through JPRT. > > Thanks! > Serguei > > > > On 12/4/13 8:17 AM, Coleen Phillimore wrote: > >> >> As everyone probably knows, for hotspot, we run JPRT as a integration >> gate. It builds and runs some last-ditch tests on all platforms. We >> disallow checkins that fail this test step. Other diverse tests are also >> required for changes, not in JPRT. >> >> If we make jdk + hotspot changes, how do we check this in to the jdk9 >> forest? Who is making the JPRT (or other equivalent integration testing >> tool) changes so that we do not lose this test step? Sorry if this is >> embedded in this long thread. >> >> I assume JPRT (or equivalent new thing) would build jdk+hotspot on all >> platforms and if hotspot changes, run the hotspot integration tests >> currently defined in the hotspot jprt.properties file. All hotspot >> integrations would have to be full jdk+hotspot jobs to get the latest jdk >> changes (rather than last promoted jdk) because there may be necessary jdk >> changes in the n-1th integration. Is someone working on these changes >> that are needed in order to open this repository? >> >> Thanks, >> Coleen >> >> >> >

More information about the jdk9-dev mailing list