jdk_custom_0 issue

[llxia]

jdk_custom allows users to set their own CUSTOM_TARGET. But running TARGET=jdk_custom_x (with any suffix) is invalid.

When a user sets TARGET=jdk_custom_0 , the pipeline will try to map it to ${TARGET.toUpperCase()}_TARGET. That is JDK_CUSTOM_0_TARGET

18:13:39  + make _jdk_custom_0 JDK_CUSTOM_0_TARGET=java/lang/Thread/virtual/stress/PinALot.java#id0

But the param that we are replacing is JDK_CUSTOM_TARGET - java/math/BigInteger/BigIntegerTest.java.
https://github.com/adoptium/aqa-tests/blob/master/openjdk/openjdk.mk#L132

As a result, the Grinder will run the default test BigIntegerTest regardless of the user-provided CUSTOM_TARGET value.

When this happens, there is no clear indication in the console output, especially when the default test passes.

https://openj9-jenkins.osuosl.org/view/Test/job/Grinder/2178/
Even in raw TAP file, it shows CUSTOM_TARGET=java/lang/Thread/virtual/stress/PinALot.java#id0[1], but we actually run

16:42:48  F:/Users/jenkins/workspace/Grinder/aqa-tests/\\openjdk\\openjdk-jdk\\test\\jdk\\java/math/BigInteger/BigIntegerTest.java; \

[1]

# AQACert.log content: 
# 
# Hostname: win2019-x64-5

#SHA.txt content: 
# 
# Timestamp: Tue Apr  4 21:25:04 2023 UTC 
# CUSTOM_TARGET: java/lang/Thread/virtual/stress/PinALot.java#id0
1..1
ok 1 - jdk_custom_0
  ---
    success rate: 20/20
    duration_ms: 2535798
  ...

We should update the logic to ensure JDK_CUSTOM_TARGET is set correctly. Otherwise, it will be really hard for the users to notice the problem.

[smlambert]

The behaviour in this case could be that we accept no suffix after jdk_custom (or any xxxx_custom targets), since they are a unique type of target, that we should also never allow variations in the playlists for (as in remove https://github.com/adoptium/aqa-tests/blob/master/openjdk/playlist.xml#L19-L23).

I often use TARGET=jdk_custom with CUSTOM_TARGET left blank to automatically run a very short test. The other option here to protect the user from themselves would be to always enforce the need to set CUSTOM_TARGET if using a TARGET that contains '_custom', but that would not be my preference (and does not resolve the current situation being reported).