fix(build): skip remote URL contexts from bake fs.read allowlist

[ndeloof]

Summary

• Fix docker compose build failing on Windows when a service's build: context is a remote git/HTTP URL
• Apply the same gitutil.ParseGitRef + :// filter to the main Context that was already applied to additional_contexts, so remote URLs are not passed to bake as --allow fs.read=<url>

Why

On Windows, bake interprets fs.read entries as local filesystem paths. When the value is a URL like https://github.com/.../repo.git#main, evaluation fails with:

failed to evaluate path "https://...": CreateFile C:\...\https:: The filename, directory name, or volume label syntax is incorrect.

because https: is invalid Windows path syntax (colon is reserved for drive letters). The fs.read entitlement is only meaningful for local paths anyway.

Fixes #13815

Test plan

• Reproduced the failure on Windows with the compose file from [BUG] docker compose build does not build from remote files. #13815 (uses remote git URLs as build contexts)
• After the fix, docker compose build completes successfully on the same project, building both services from their remote git sources

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟢 APPROVE

The fix correctly applies the same gitutil.ParseGitRef + "://" URL filter that was already guarding AdditionalContexts to the main buildConfig.Context field, preventing remote URLs from being passed as --allow fs.read=<url> to bake. The new guard is logically sound and mirrors the existing pattern exactly.

No high or medium severity issues were found.

[Copilot]

Pull request overview

Fixes docker compose build failing on Windows when a service’s build.context is a remote git/HTTP URL by ensuring such remote contexts are not passed to buildx bake as --allow fs.read=<url> (which bake interprets as a local filesystem path on Windows).

Changes:

• Skip adding build.context to the bake fs.read allowlist when it looks like a remote URL (://) or a git ref (per gitutil.ParseGitRef), matching the existing filtering already used for additional_contexts.

[vaguul]

This lines up with the split from #13815: local build contexts worked on the same Windows setup, while the remote Git URL context failed when bake treated the URL like an fs.read path.

The guard here matches the existing additional_contexts filtering and should avoid passing https://... / Git refs into the filesystem allowlist. The one regression case I would want covered is a service with scalar remote build: context, for example:

services:
  api:
    build: https://github.com/example/repo.git#main

and asserting the bake path does not include that URL in --allow fs.read=.... That is the exact shape from the issue report, separate from additional_contexts.