[BUG] Docker login/logout in Jenkins cause gradle check to fail on Windows

[peterzhuamazon]

The windows runner does not have docker installed by default due to various reasons mentioned in opensearch-project/opensearch-ci#281.

When we add docker login for gradle check rate limit in #3367 we only make it run on linux.

We need to ignore this for windows for now. Thanks.

[peterzhuamazon]

Example issues: https://build.ci.opensearch.org/job/gradle-check/20933/console

[rishabh6788]

Waiting on opensearch-project/opensearch-ci#281 to be resolved.

[peterzhuamazon]

PRs:

• Make docker command detection consistently across OSes opensearch-build-libraries#254
• Make sure docker is only checked on non-windows gradle check #3817
• [Windows Container] Setup docker for windows docker images to build docker images #3903
• [Windows Container] Windows docker setups jenkins docker build #3905
• Update the gradle check with docker command checks #4178
• Update Windows ami opensearch-ci#370

[peterzhuamazon]

More PR:

• Switch Windows gradle check runner from C524large to M58xlarge matching LINUX opensearch-ci#354
• Remove old Windows runner and replace Windows Gradle Check Runner AMI ID with M58xlarge opensearch-ci#355
• Make sure windows gradle check runner is supporting docker opensearch-ci#356
• Update ami id for windows runner gradle check from #356 opensearch-ci#357
• Add docker host required init script to gradle check windows runner opensearch-ci#358
• Update Windows Gradle Check Runner to use 126GB WINRM Mem on M58xlarge opensearch-ci#359
• Make sure only 110G mem is utilized for WINRM M58xlarge on Windows Gradle Check Runner opensearch-ci#360
• Add ami id from the PR #360 opensearch-ci#361
• Switch back to c5.24large before further investigation on windows runner opensearch-ci#362
• Make sure noshutdown settings is removed for windows instances opensearch-ci#363
• Update AMI from #363 and make sure AL2023 update latest pkgs opensearch-ci#364

[peterzhuamazon]

Keep seeing this:

ERROR: Timed out after 1210 seconds of waiting for winrm to be connected
com.amazonaws.AmazonClientException: Timed out after 1210 seconds of waiting for winrm to be connected
	at hudson.plugins.ec2.win.EC2WindowsLauncher.connectToWinRM(EC2WindowsLauncher.java:142)
	at hudson.plugins.ec2.win.EC2WindowsLauncher.launchScript(EC2WindowsLauncher.java:52)
	at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:48)
	at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:298)
	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
	at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:80)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Will switch to c5 instance for windows as m5 is not stable at all for it.

[peterzhuamazon]

It is fixed now after several other PRs.

[peterzhuamazon]

Even more PRs:

• Update jdk setup to include jdk14 for gradle check #4154
• Add docker-compose and fix docker-re-release lib version #4174
• Restore old windows runner for gradle and update jdk21 opensearch-ci#367
• Restore all the way back to original c524xlarge as m58xlarge just not stable on Windows opensearch-ci#368
• Reset the windows runner label to C524large and update AMI opensearch-ci#369

[peterzhuamazon]

We are moving to docker container run gradle check on both linux and windows now.
It does not make sense to maintain both docker image and ami version of the same setups.
Thanks.

[peterzhuamazon]

The container running gradle check is not returning stable runs.
We also have an issue with our Windows 2019 instance that does not support wsl2, which means we cannot run linux containers natively on Windows for now.

Per @mch2 discussion, we should either remove those docker-compose tasks for Windows, or put this task to backlog until we re-visit with update to Windows 2022 later.

As of now, it will still run windows but fail the docker-compose tasks, but at least it will not get blocked on the start because docker does not exist. Thanks.

[peterzhuamazon]

This has been fixed for now for docker commands not having errors on Windows agent.
But still, core team needs to disable linux containers on Windows runs.

@mch2 Thanks.