Add to documentation on adding new systems

[smlambert]

This issue to capture improvements that can be made to step 6 of the instructions in the FAQ for adding new systems (See https://github.com/adoptium/infrastructure/blob/master/FAQ.md#adding-new-systems).

Here are some additional details that may help new folks with testing a new system:

Instructions for running all AQAvit tests on a particular machine

Run the AQA_Test_Pipeline with certain parameters set.

Run https://ci.adoptium.net/job/AQA_Test_Pipeline/ using many of the default settings for the parameters, but explicitly setting the certain parameters. This will take a LONG time, as you are trying to run all of the top-level test targets for multiple JVM versions on one node, so each job launched will queue up and wait for its turn to run.

1. PLATFORMS needs to match the platform of the machine you wish to vet, for our example, let’s pretend it’s x86-64_linux.

   PLATFORMS=x86-64_linux

2. JDK_VERSIONS is a comma-separated list of the versions you wish to test against. If you select all LTS and current versions, it will launch 9 test jobs per version, so use with caution. For example, using the value below of 7 versions times the 9 top-level test TARGETS, would launch 63 test jobs.

   JDK_VERSIONS=8,11,17,21,25,26,27

3. SDK_RESOURCE ideally set to nightly or releases for the purpose of bringing a new machine online.

   SDK_RESOURCE=releases

4. LABEL should be set to the hostname of the node you are wishing to test on (as it is called in Jenkins).

   LABEL=hostNameOfNewNode

For all other parameters, it should be fine to use the default settings.

5. TARGETS are set by default to include all 9 top-level targets that we use for AQAvit verification during a release.
   TARGETS=sanity.functional,extended.functional,special.functional,sanity.openjdk,extended.openjdk,sanity.system,extended.system,sanity.perf,extended.perf

If you want to reduce this list slightly, selecting the extended level from each group [functional, openjdk, system, performance] will likely reveal the most about what configuration updates are needed on the machine you are trying to bring online.

Verify the status of AQA_Test_Pipeline

You can do this by looking at the Jenkins status for the build ID of the AQA_Test_Pipeline that you launched, the Jenkins Blue Ocean view can sometimes be helpful.

You can alternatively use TRSS, grid view or tree view. Find the AQA_Test_Pipeline you launched from the list from this page: https://trss.adoptium.net/builds?buildName=AQA_Test_Pipeline&url=https%3A%2F%2Fci.adoptopenjdk.net&type=Test and click on the Grid link for it when the pipeline completes, the view will look something like this:

Each chiclet in the Grid view represents the status of a test job.
Green is pass and needs no further investigation.
Red indicates the job failed to run properly, so the job status is FAILED and needs investigation.
Grey indicates the job state is ABORTED (either manually or because of hitting the default 15 hour TIME_LIMIT) and needs investigation.
Yellow indicates the job ran to completion, but there are some test cases that failed, so it is marked as UNSTABLE and needs investigation.

If failures are related to missing dependencies or pre-requisites or incorrect machine configuration, fix as needed and rerun the failed test cases or jobs as needed to verify “all green”.

[smlambert]

FYI, @steelhead31 (as per today's discussion)

[steelhead31]

Thanks @smlambert these are really good!.. I've got a set running , following the above for my new windows base image.., and I've tasked myself with doing the documentation update to include this!