Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9 (original) (raw)
Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Dec 5 15:03:52 PST 2013
- Previous message: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9
- Next message: Proposal to revise forest graph and integration practices for JDK 9
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Required integration testing changes? related to: Proposal to revise forest graph and integration practices for JDK 9
- Next message: Proposal to revise forest graph and integration practices for JDK 9
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]