Using custom target for rerun jobs

[sophia-guo]

Rerun job with failed targets might be costly. There might be a few test cases failures but the test target might include a few hundred of test cases. Also with failed targets some original passing test cases may fail as intermittent failure or fail on some agents.

For openjdk and jck tests rerun job can be updated to use custom targets to only run failed test cases instead of test targets.

One example of running time difference
#5016 (comment)

If the set of failed test cases is too big as jenkins parameter to trigger the job a check can be added to run the failed target instead.

Part of #5016

[sophia-guo]

Openjdk has two custom targets, jck has four custom targets.

Currently each test build can only trigger one custom target. That is if more than one custom target is needed we need to trigger rerun build more than once correspondingly. Or can **_custom target can be triggered as TESTLIST so multiple custom target can be run? ( need to invesitgate).

The other thing is the limitation of the hppt url parameter length. There may be situations that a set of test cases fail ( due to setting issues or machine issues) so the string CUSTOM_TARGET is too long as the url parameter. For this case we may either divide the CUSTOM_TARGET to small sets and trigger the rerun multiple times or just fall back to failed targets. Falling back to failed targets might make more sense as this situation most likely some test cases setting issue or environment issues.

[smlambert]

I think it is fair to simply handle the simple case (which are frequent), logic:

if ((test case failure list belongs to only one type of custom list) && (failed test cases string is below the URI too long limit)) then { 
    trigger rerun as a custom target 
} else {
    trigger the failed targets to be  rerun // as we currently do
}

There are many cases that match this simple case, and it would help to reduce execution time without being too complicated.

[sophia-guo]

Not sure what is the maximum of Adoptiums jenkins header size. As Jenkins header size can be set/configured we may not need to know exactly the size. In most cases failed test cases should not be too long unless some environment issues or test setting issues, for which case we may just switch back to failed targets. I would suggest set the number of testcases as 50 for now. If not good can change later.

[smlambert]

I would suggest set the number of testcases as 50 for now. If not good can change later.

It would be somewhat easy to test this, by finding one of the machines that throw "no route to host" error and run jdk_net and jdk_nio targets or some such (can look at triage issues to find an example).