[BUG] `docker compose build` does not build from remote files.

[tryhardsnipehrd]

Description

When building/running a compose file on Windows using docker compose build, it errors with The filename, directory name, or volume label syntax is incorrect when using a remote repository.

Steps To Reproduce

1. run git clone https://github.com/South-Dakota-Mines-Esports-Association/Rocky.git
2. cd into the Rocky directory
3. run docker compose build

Compose Version

Docker Compose version v5.1.3

Docker Environment

Client:
 Version:    29.5.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: Docker AI Agent Runner (Docker Inc.)
    Version:  v1.57.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-agent.exe
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.20.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.34.0-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.3
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.3.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.3
    Path:     C:\Program Files\Docker\cli-plugins\docker-dhi.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.42.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.1.37
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.92
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.27
    Path:     C:\Program Files\Docker\cli-plugins\docker-pass.exe
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.12.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.20.4
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 5
 Server Version: 29.5.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc version: v1.3.5-0-g488fc13e
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.114.1-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 22
 Total Memory: 15.37GiB
 Name: docker-desktop
 ID: 681f70f1-5bd9-4893-8d03-5c14d517b35e
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Anything else?

Repository containing original compose file, which currently errors on Windows while working in Linux: https://github.com/South-Dakota-Mines-Esports-Association/Rocky/

[vaguul]

Not a maintainer, but I cloned the referenced repo and the failing part looks nicely reducible: both buildable services use remote Git build contexts as the scalar build: value:

api:
  build: https://github.com/South-Dakota-Mines-Esports-Association/Rocky-API.git#main
bot:
  build: https://github.com/South-Dakota-Mines-Esports-Association/Rocky-Bot.git#main

Both remote repos do have a root Dockerfile, so this does not look like a missing-Dockerfile issue. If this only fails on Windows, it may be worth reducing the repro further to a one-service compose file with just one of those Git URLs. That would separate "Compose handling of remote Git contexts on Windows" from the rest of the Rocky stack (env_file, MySQL, bind mount, healthcheck, etc.).

As a workaround, I would try cloning the two build repos locally and switching the compose file to local contexts:

api:
  build:
    context: ../Rocky-API
bot:
  build:
    context: ../Rocky-Bot

If local contexts build on the same Windows machine while the Git URL context fails, that should give maintainers a much smaller signal: the issue is likely in the remote-context path handling rather than in the app Dockerfiles or compose service graph.

[tryhardsnipehrd]

@vaguul
I went ahead and cloned them locally, and used that local copy in the compose file. That causes the application to build and run perfectly fine, just as on Linux.
Additionally, it looks like a fix is currently in the works (#13816).

[vaguul]

Thanks for checking that. That confirms the useful split: local build contexts work on the same Windows setup, and only the remote Git URL context path is failing.

The PR you linked also matches that diagnosis: the URL was being passed into bake's fs.read allowlist as if it were a local filesystem path, which explains the Windows https: path error. Looks like #13816 should be the right fix path.