Explicitly set Docker as test runtime to avoid issues with docker info

[danegsta]

Description

Windows tests seem to have started having issues with container runtime detection. This PR forces the tests to use the Docker runtime since that's what's installed. It'll cause us to skip most of the detection logic hopefully the issue.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[radical]

this should probably also be added to

aspire/eng/pipelines/templates/BuildAndTest.yml

Lines 107 to 114 in 48950f0

	env:
	DOCKER_BUILDKIT: 1
	# https://github.com/dotnet/aspire/issues/5195#issuecomment-2271687822
	DOTNET_ASPIRE_DEPENDENCY_CHECK_TIMEOUT: 180
	DCP_DIAGNOSTICS_LOG_LEVEL: debug
	DCP_DIAGNOSTICS_LOG_FOLDER: $(Build.ArtifactStagingDirectory)/artifacts/log/dcp
	DCP_PRESERVE_EXECUTABLE_LOGS: 1
	DOTNET_ROOT: $(Build.SourcesDirectory)/.dotnet

and

aspire/tests/helix/send-to-helix-inner.proj

Lines 157 to 159 in 48950f0

	<HelixPreCommand Include="$(_EnvVarSetKeyword) DCP_DIAGNOSTICS_LOG_LEVEL=debug" />
	<HelixPreCommand Include="$(_EnvVarSetKeyword) DCP_DIAGNOSTICS_LOG_FOLDER=$(_HelixLogsPath)" />
	<HelixPreCommand Include="$(_EnvVarSetKeyword) DCP_PRESERVE_EXECUTABLE_LOGS=1" />

[danmoseley]

failure is
Download failed: server closed connection. URL: https://cdn.playwright.dev/dbazure/download/playwright/builds/chromium/1155/chromium-linux.zip
@radical do we have enough retries on this ? I've seen it before.

[danegsta]

failure is Download failed: server closed connection. URL: https://cdn.playwright.dev/dbazure/download/playwright/builds/chromium/1155/chromium-linux.zip @radical do we have enough retries on this ? I've seen it before.

Saw the same error from the test runs on the first commit to this PR. The URL works fine from my home network; test pool getting rate limited?

[danmoseley]

@radical copilot says htere's no way to request retries of the playwright download short of looping in msbuild

<PropertyGroup>
  <MaxRetries>3</MaxRetries>
  <RetryCount>0</RetryCount>
</PropertyGroup>

<Target Name="InstallPlaywrightWithRetry">
  <Exec Command="dotnet exec --runtimeconfig $(MSBuildThisFileDirectory)Microsoft.Playwright.runtimeconfig.json $(_MicrosoftPlaywrightDllPath) install @(BrowsersForPlaywrightToInstall, ' ')"
        EnvironmentVariables="@(_EnvVarsForPlaywrightInstall)"
        IgnoreExitCode="true">
    <Output TaskParameter="ExitCode" PropertyName="PlaywrightExitCode" />
  </Exec>

  <Message Text="Playwright install attempt $(RetryCount), ExitCode: $(PlaywrightExitCode)" Importance="high" />

  <Error Condition="'$(PlaywrightExitCode)' != '0' and '$(RetryCount)' == '$(MaxRetries)'" Text="Playwright install failed after $(MaxRetries) attempts." />

  <PropertyGroup>
    <RetryCount Condition="'$(PlaywrightExitCode)' != '0'">$(RetryCount)</RetryCount>
    <RetryCount Condition="'$(PlaywrightExitCode)' != '0'">$([MSBuild]::Add($(RetryCount), 1))</RetryCount>
  </PropertyGroup>

  <CallTarget Condition="'$(PlaywrightExitCode)' != '0' and '$(RetryCount)' != '$(MaxRetries)'" Targets="InstallPlaywrightWithRetry" />
</Target>

[danegsta]

Green tests, so I'll merge this to unblock the other PRs hitting test failures.

[danmoseley]

thanks @danegsta . is there a product bug here for 9.3?

[davidfowl]

Are we sure this isn’t a product issue?

[danegsta]

thanks @danegsta . is there a product bug here for 9.3?

Best guess is that Docker on the test pool is hanging on the docker info command. We added the workaround we're using here in 9.2 after a couple users reported similar behavior (but we couldn't reproduce at the time). I do want to make a change to switch from using docker info in our runtime health check to checking if Docker is a symlink instead, but I don't know if we want to take that change in 9.3 if we aren't running into it outside of the test machines.

[afscrome]

This sounds related to #8737 - I see tests intermittently fail on 9.2 for RuntimeUnhealthy, even though other containers have started up successfully (had one fail like that this morning). Also see similar with the dashboard, although dashboard is less impacted as the RuntimeHealthy resources eventually retry and start up.

[danegsta]

I've made a change in DCP main to avoid calling docker info in the runtime checks.