aqa-tests: Windows jdk16 test run hangs retrieving openjdk source

Describe the bug A hang during a git ls-remote call to the jdk16 source repo.

The git ls-remote call appears to be the ant openjdk-tests/openjdk/build.xml’s way of determining whether the jdk source repo we want is that of an upgrade jdk or not (jdk16.git vs jdk16.git) if the job’s JDK_REPO parameter is empty.

However, sometimes we’ll make the call, and the process will hang. This behaviour can be caused by ls-remote responding with a request for a username. The process stops there, and we then have a 9-hour wait until the jenkins job times out.

Problem: The build.xml script is not set up to perceive the login as a sign that the openjdk-jdk${JDK_VERSION}u.git repo is not accessible, and that the non-u repo “openjdk-jdk${JDK_VERSION}.git” repo should be used instead (as I interpret a restricted-access jdk source repo as a sign the repo is not ready to be used yet).

Solution: Somehow transform the request for a user ID into a failure that the build.xml can correctly interpret.

To Reproduce Run a Windows grinder for jdk16 on any openjdk regression test target (e.g. jdk_foreign_native), specifying a jdk16 nightly jdk, but leaving the JDK_REPO parameter blank.

Expected behavior I expect that either the user login should be interpreted as a failure immediately, or (second best) that a timeout should be set for the exec task running that command, with a timeout of more than a few seconds taken as evidence that the non-u repo should be used.

Screenshots

15:58:21  getOpenjdk:
15:58:23       [echo] git ls-remote -h https://github.com/AdoptOpenJDK/openjdk-jdk16u.git
Cancelling nested steps due to timeout
01:44:18  Sending interrupt signal to process

Additional context Grinder has only run on test-azure-win2012r2-x64-2 so far, but this issue has been reproduced locally on 2 other machines.