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

[Daniel D. Daugherty]

On 12/4/13 10:56 AM, Joe Darcy wrote:
> On 12/04/2013 08: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
>>
>>
>
> Hi Coleen,
>
> This issue was raised before in some internal discussions. IIRC, there 
> was a workaround without changing jprt.

More precisely, the '-forest' option "works" to build and test a 'jdk' repo
plus a 'hotspot' repo with a couple of (big) caveats:

- embedded builds aren't done since the 'jdk' repo does not yet
   support building on embedded
- the tests that are executed are the 'jdk' repo tests and not
   the 'hotspot' repo tests

The "work around" that Alejandro and John C currently use is to do
a pair of jobs. One is a HotSpot job to get all the builds and HotSpot
specific testing done along with the push. The second job is a control
build with all the repos necessary to build the combined 'jdk' and
'hotspot' changes together. I believe the second job is used for PIT.

Painful? You bet.

Dan


>
> In any case, we could still change the graph of forests first and 
> initially do HotSpot + libs fixes as we do today and still get latency 
> benefits before any needed adjustments to jprt are made.
>
> Thanks,
>
> -Joe