Acceptance tests fail on Windows due to volume mounts

[natalieparellano]

Summary

See here: https://ci.buildpacks.io/teams/main/pipelines/pack/jobs/acceptance-lifecycle-current-windows/builds/96

This line of code is failing:

pack/acceptance/acceptance_test.go

Line 501 in 007ab0c

when("--volume", func() {

With error message: Error response from daemon: Drive has not been shared

The volume we are trying to mount: C:\Users\Admin\AppData\Local\Temp\my-volume-mount-source229023759

It looks like the C:\ drive needs to be shared.

This post indicates that the settings can be updated using the Docker Desktop UI. It looks like this also requires the latest stable version as some bugs have recently been fixed around this process.

Open questions:

• will updating this setting fix the issue
• does this complicate a move to GitHub actions (assuming this is otherwise possible)

---

Reproduction

Steps

1. Run the acceptance tests in CI

Current behavior

The tests fails

Expected behavior

I expect the tests to pass

---

Environment

Concourse Windows worker in Packet

pack info

docker info

[natalieparellano]

Current status:

• RPD'd onto the worker, tried to enable sharing for C:\ per the Stack Overflow thread above
• Ran into what I think is this bug: Cannot share one specific drive after updating to 2.2.0 docker/for-win#5567 (submitting the dialog box had no effect)
• Need to update to the latest stable Docker (currently 2.2.0.4) to get the fix, but that version of Docker is not compatible with the version of Windows that we're running (error: "Docker Desktop requires Windows 10 Pro or Enterprise version 15063 to run.")

Next step: update the worker?

[natalieparellano]

Managed to re-install Docker Desktop, left breadcrumbs here: https://github.com/buildpacks/ci/wiki/Windows-worker-configuration

[natalieparellano]

Update: the existing worker is now unusably slow (specifically, network connections). I tried spinning up a brand new medium sized VM and it is also unusably slow. Opened a ticket.

Looked into whether a GCP-provisioned Windows Server 2019 VM can do the job for us. I don't think it will work - trying to start Docker Desktop fails with "Failed to start the virtual machine 'DockerDesktopVM' because one of the Hyper-V components is not running." which seems to be a nested virtualization problem (googling around, suggested fixes include "expose hardware assisted virtualization to the guest OS" in vsphere; meanwhile GCP documentation indicates that Hyper-V containers are not supported).

Next steps - hope that support will fix our issue; investigate Azure?

[natalieparellano]

The existing worker became happy and the tests passed but there now seems to be a flake: https://ci.buildpacks.io/teams/main/pipelines/pack/jobs/acceptance-lifecycle-current-windows/builds/121

Current status: wondering what other options are available, pondering in Slack.

Blocking this issue on consensus around what we should do.

[natalieparellano]

To update this issue: we decided that our current configuration is good enough for now, but we'll investigate upgrading the worker to Windows Server 2019 in the future. Tests are happy so I think this issue can be closed.