add logic for jdk-version specific suites

[judovana]

#5553 (comment) have reminded me old issue, where some external tests, eg jacoco, works fine with 8-17 but do not work with jdk21

Unluckily, current logic to clone and checkout is in https://github.com/adoptium/aqa-tests/blob/master/external/jacoco/test.properties

So I see several options with many pros and cons:

• narrow the checkout in test.sh ( I do not like this)
• have duplicated testfolder (so jacoco target would be limited for jdk21 onwards, and will have updated tag, and new jacoco17 wold be limited to 17 and older)
• create flexible checkout logic in properties file similar to what I did for os-based properties (I'm not sure I like this)
  • tag_version -> tag(7|8)_version and tag(21|22)_version ....
  • this is less expendable to other non-external test

This will be quite a precedent for other - at least external - tests

Many others maybe have to be simply disabled for older/newer jdks, but that is easily done in playlists?

• have playlist's <testCase> per set of jdks.

[smlambert]

Thanks for raising this issue @judovana. Before any option is chosen, it will be good to create a table of external apps, their versions and which ones work with which Java version. That will be useful to visualize and help inform the best way forward.

[judovana]

Thanks for raising this issue @judovana. Before any option is chosen, it will be good to create a table of external apps, their versions and which ones work with which Java version. That will be useful to visualize and help inform the best way forward.

thats terrible task.... I would much rather go one by one:(

[judovana]

But yah, would try to do that. You are rigth that it is moreover necessary

[smlambert]

But yah, would try to do that. You are rigth that it is moreover necessary

We can work on it together :)

[judovana]

I will wait for #5553 to merge. Once I will be doing such a matrix, I will include multi-base-images to it.