Conversation
* Remove probably-unnecessary install step. * Tweak IRC notification so it might not be blocked.
Specifying openjdk9 appears to break the fetching of some gem resources in the build, perhaps because the openjdk9 build has crippled crypto or stale certificates. The error looks like this: ``` [ERROR] Failed to execute goal on project jruby-stdlib: Could not resolve dependencies for project org.jruby:jruby-stdlib:jar:9.2.1.0-SNAPSHOT: Failed to collect dependencies at rubygems:cmath:gem:1.0.0: Failed to read artifact descriptor for rubygems:cmath:gem:1.0.0: Could not transfer artifact rubygems:cmath:pom:1.0.0 from/to mavengems (mavengem:https://rubygems.org): Error transferring file: RubygemsFile[type=POM, storage=/maven/releases/rubygems/cmath/1.0.0/cmath-1.0.0.pom, remote=/maven/releases/rubygems/cmath/1.0.0/cmath-1.0.0.pom, name=cmath, state=ERROR, exception=IOException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] on https://rubygems.org -> [Help 1] ``` This commit returns to openjdk9 in an attempt to fix this error.
* Move slowest tests to top, so they'll run while others do. * Reduce git depth to 1.
The test_syntax test from MRI runs a number of tests that launch lots of subprocesses, which is still rather slow under JRuby. This commit moves the entire script to its own build so it can run in parallel with other suites and not hold up test:mri builds as much.
This reverts commit 2df82c1.
|
Additional changes: reordered test suites so the longer ones come at the top; they will start earlier and run while the shorter suites complete. This does mean fewer short suites will run in parallel but given that the MRI suites are nearly as long as the entire CI run, I think the new orientation is better. I reverted a last-minute bump from j2 to j3 for the remaining core MRI tests. It appeared to slow things down. |
|
We could also just remove the deploy stage, which would cut another couple minutes off the build. We do not link to the sonatype snapshot repos from anywhere, and have never officially used these builds as our snapshots. The CI builds run periodically on Cloudbees serve as our snapshots at present. @mkristian I don't think anything in our builds is using the snapshot deploys either, right? |
|
@headius |
|
LGTM |
|
spec:regression remains unstable but I will examine that separately. This PR looks ok. |
3 participants
Numeric changes here to improve the overall time of our CI builds.
Some changes were necessary but unrelated to the work above:
With these changes in place plus @enebo's tweaks to use --dev, the most recent build on this branch took 22 minutes to complete, versus 45 minute for a build before any of this work began. The most recent master build, with @enebo's changes, took 25 minutes.
There's still room to improve.