Create new jobs to handle running Solaris tests via a Linux proxy machine

[sxa]

This covers the implementation of what has been discussed in adoptium/infrastructure#3742 (comment)

Current status: Prototype jobs have been created for x64 and SPARC at:

• https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-x64-temurin-simpletest
• https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simpletest

These are currently connecting to the target machine as the vagrant user (even on SPARC where I've created a user with that name for consistency).

Jobs are currently set up to run the full AQA suite of tests instead of running as individual jobs but that can be changed later if desired and archive the artefacts

[sxa]

Prototype now working (although hard coded to a specific tag. There is a dotests.x64.sh script and a dotests.sparcv9 script on the proxy host which is copied across to the target machine using scp as dotests.sh and that is executed.

It needs to be parameterised to be able to take the tag/URL as a parameter (for use when retrieving the artifact directly from jenkins, since we can't use copyArtifact) but otherwise it works.
It currently has a loop which can loop over each suite that is required and then copy the TAP output back to the proxy machine for archiving. The proxy agent is running as the solaris user on dockerhost-azure-ubuntu2204-x64-1

[sxa]

Verification (Solaris/x64)

Failures (based on looking at https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-x64-temurin-simpletest/50/tapResults:

• sanity.openjdk:
  • jdk/lambda/vm/InterfaceAccessFlagsTest.java
• sanity.system (All due to being unable to locate mauve/mauve.jar:
  • MauveSingleThrdLoad_HS_5m_0
  • MauveSingleInvocLoad_HS_5m_0
  • MauveMultiThrdLoad_5m_0
• extended.system (All except OAuthTest_0 are due to being unabel to locate mauve/mauve.jar:
  • MiniMix_5m_0
  • MiniMix_10m_0
  • MiniMix_aot_5m_0
  • OAuthTest_0
• extended.openjdk:
  • jdk_beans_0 (10 failures - mostly font/color related)
  • jdk_security3_0 (javax/net/ssl/ciphersuites/DisabledAlgorithms.java)
  • jdk_management_0 (sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh)
  • jdk_imageio_0 (2 failures - plugins/jpeg/JPEGsNotAcceleratedTest.java and javax/imageio/AppletResourceTest.java)
• special.openjdk:
  • jdk_math_jre_0 (Error: JDK not found)

Solaris/SPARC

The SPARC run had mostly the same failures although OAuthTest_0 in the extended.system suite didn't fail as it was skipped. Two other failures:

• extended.openjdk:
  • hotspot_jdk_0 `serviceability/sa/jmap-hashcode/Test8028623.java
  • jdk_security3_0: sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java (NOTE: Different failure in this suite from the x64 run)

[adamfarley]

These test failures were seen in the old Solaris pipelines:

Sparc:

• Test8028623.java Example.

x64:

• DisabledAlgorithms.java Example
• SSLConfigFilePermissionTest Example

---

These test failures appear to be new:

Sparc:

• ClientSocketCloseHang.java Example.

x64: in progress

• InterfaceAccessFlagsTest.java Example.
• jdk_math_jre_0 Example.
• jdk_beans_0 Example
• AppletResourceTest Example
• All the "could not find mauve jar" issues, though we did have an instance of "could not find stf.pl in those extended tests. Example.
• OAuthTest_0 timeout (connection refused errors are common in the old pipeline, though). Example.

[sxa]

@adamfarley FYI I've brought the "normal" solaris jenkins agents for the test boxes back online in case you want to try anything via Grinder

[sxa]

@adamfarley Also if you're going to run grinders it would probably be good to compare on the last published EA ones and the "new" builds from my pipelines in https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simplepipe/ and https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-x64-temurin-simplepipe/ just in case there's something wrong with the build itself.

[adamfarley]

Sure thing.

TLDR: No problems on the new build that weren't on the old build (when run in Grinder, anyway).

Details:

x64:

• Old builds: OpenJDK, System
• New builds: OpenJDK, System

OpenJDK result: All tests passed except for the jdk_math_jre_0 target which failed in both cases with the same error
Note: The jdk_custom appears to have run wrong (test/tkg bug, I think) for both builds, so here's are the reruns (which all passed): Old build, new build.

System result:

Can't open perl script "/export/home/jenkins/workspace/Grinder/aqa-tests/TKG/../../jvmtest/system/security/..//STF/stf.core/scripts/stf.pl": No such file or directory

This error occurs with both old and new builds, so the framework is equally broken in both cases. :/

sparc:

• Old builds: OpenJDK, System
• New builds: OpenJDK, System

OpenJDK result: Targets passed, except for math jre, which failed on both builds. Custom reruns are here: Old build, new build.

System result: Same as above. stf.pl not found.