Grinder re-run links at the end of job logs are faulty

[sxa]

(Good first issue? I don't think I've seen this covered in another issue - apologies if it has already been formally raised)

Describe the bug
When a job runs and tests fails, there are Grinder re-run links after the results summary in the log - it is expected that these will "just work" to re-run the failing parts of the test but they do not

To Reproduce
One example from https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk11_hs_sanity.openjdk_ppc64_aix/365/console (HotSpot) is this link:

• https://ci.adoptopenjdk.net/job/Grinder/parambuild/?JDK_VERSION=11&JDK_IMPL=hotspot&JDK_VENDOR=adoptopenjdk&BUILD_LIST=openjdk&PLATFORM=ppc64_aix_xl&TARGET=jdk_lang_1
  It should not have _xl on the PLATFORM name. Another example is https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk16_j9_extended.openjdk_x86-64_linux/22/console from an OpenJ9 test log:
• https://ci.adoptopenjdk.net/job/Grinder/parambuild/?JDK_VERSION=16&JDK_IMPL=openj9&JDK_VENDOR=adoptopenjdk&BUILD_LIST=openjdk&PLATFORM=x86-64_linux_mixed&TARGET=jdk_net_0
  This has _mixed suffixed onto the platform name which prevents the Grinder from working, causing confusion on the part of the person attempting to reproduce the problem

Expected behavior
Click the Grinder link, and run it without having to change any options in order to re-run a test.

While Shelley has suggested removing these convenience links they are extremely useful so it would be preferable if we could make them "just work" especially if it could be done just by stripping the second _ and anything after it from the link when it is inserted into the log.

[smlambert]

While Shelley has suggested removing these convenience links they are extremely useful so it would be preferable if we could make them "just work" especially if it could be done just by stripping the second _ and anything after it from the link when it is inserted into the log.

My response was out of exasperation/fatigue (similar response when being barked at by attack dogs). Agree that simplification (which can be removal) and/or improvements can be made in this area. Did not have the energy to give this detailed response to the complaints in infra/1992, simply chose to create adoptium/TKG#184 to address the _xl/_mixed leftovers.

For clarity, there are 2 types of rerun links that are produced. Hopefully this will aid in the understanding of what constraints are for each case (when the link is built, what information is available to us at the time its created).

1. TKG rerun link - Re-run links produced at the end of console output are produced by TKG and serve to help those who are running locally to transfer the local run to Jenkins. They do not attempt to capture ALL of the parameters set by the test job. They attempt to capture the parameters that TKG knows about locally including the TARGET parameter (failed test targets) captured AFTER the test run completes. TKG does not have access to all parameters used by Jenkins (nor does it need to), so in the case of this type of rerun link, the user would be expected to fill in more of the parameters in the Grinder they wish to run. Agree that if some values are actually being filled in incorrectly as reported, this should be fixed via a PR to adoptium/TKG repo (and I had created Verify Rerun links produced by TKG contain correct information TKG#184 to address the concerns raised around incorrect param value information). Code to create these links is here.

2. Jenkins rerun link - Rerun links generated before the test job in Jenkins completes. This was based on a request from development team. This one is interchangeable with the Jenkins "Rebuild" link. I suggested removing this link if it was confusing people who have complained that they have to change SDK_RESOURCE from upstream to nightly because the upstream builds no longer exist at the time they go to use the rerun link (same would be true for the Rebuild link in Jenkins). Code to create these links in here.

Pictures to aid clarity regarding the information above:

1. Rerun from TKG - created via perl script post test run

2. Rerun from Jenkins - created via groovy script pre test run (same as Rebuild link that comes with Jenkins)

[smlambert]

TKG is 'doing what it is told' by being parsing the https://github.com/adoptium/TKG/blob/master/resources/buildPlatformMap.properties file and determining the platform to be _xl, _mixed, based on how it was decided to handle the openj9 transition from having 2 separate builds, to one build. (See related: eclipse-openj9/openj9#9231 (comment))

There is an additional check that should occur in the case of hotspot, where a different mapping should be used.

[smlambert]

adoptium/TKG#197 opened to address this issue. Closing this as duplicate.