fix(up): surface Docker connection errors before missing config

[scarab-systems]

What I did

This updates docker compose up so that, when no compose file was explicitly selected and default discovery has no compose file candidate to load, Compose checks the Docker API connection before returning the missing-config error. That lets the Moby client surface the daemon/socket connection error for the empty-directory case reported in #13649.

The guard is intentionally narrow. It does not run ahead of explicit config loading: -f, COMPOSE_FILE, env-file based configuration, .env defining COMPOSE_FILE, or an existing default compose file all keep the normal Compose project-loading path. This preserves the COMPOSE_FILE-points-to-directory behavior discussed in review.

Related issue

Fixes #13649

Testing

• go test ./cmd/compose -run 'TestUp(ChecksDockerConnectionBeforeDefaultConfigDiscovery|LoadsConfigBeforeDockerConnection)$' -count=1
• go test ./cmd/compose ./pkg/compose -count=1
• make lint
• make test
• make validate
• make build
• Manual smoke: empty directory plus unreadable Docker socket now returns permission denied while trying to connect to the docker API ....
• Manual smoke: explicit COMPOSE_FILE pointing at a directory still returns read ... is a directory.
• make build-and-e2e attempted locally. It still fails in this Docker Desktop environment on TestImageVolume, TestImageVolumeRecreateOnRebuild, and TestComposeModel; those same local/base failures were reproduced previously on clean current origin/main.

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[thaJeztah]

wonder if this should be inside runUp to avoid connecting to the API before all other validation is completed (at least at a glance it feels like a more natural place to validate the connection)

[scarab-systems]

I checked this against the command path after your note. runUp is reached after the project has already been loaded by p.WithServices(...); the misleading is a directory error from #13649 is raised during that earlier project-loading path, so moving the ping into runUp would leave the reported case unchanged.

I kept the reachability check after local validation but before project loading, and moved the remaining --attach / --attach-dependencies conflict into validateFlags so that flag-only validation still wins before any Docker API call. Added coverage for both paths. If there is another pre-load owner you prefer for the connection check, I can adjust the placement.

[ndeloof]

#13649 is actually unrelated to docker.sock permission
This is well reported by moby Client with a dedicated error message.
We could check the client is well set on first call to apiClient() relying on a sync.Once block

[scarab-systems]

I updated the branch again after a deeper pass through the empty-directory path.

The branch now includes a production fix, not only the config-order regression test. For docker compose up, when no compose file is explicitly selected and default discovery has no candidate, Compose now checks the Docker API connection before returning the missing-config error. That lets the Moby client surface the daemon/socket connection error for the #13649 empty-directory case.

The guard stays narrow and preserves the config-loading behavior you pointed out: if config selection is explicit (-f, COMPOSE_FILE, env files, .env defining COMPOSE_FILE) or a default compose file exists, Compose keeps the normal project-loading path. The existing regression test still proves a COMPOSE_FILE directory reports read ... is a directory.

Validation run locally:

• go test ./cmd/compose -run 'TestUp(ChecksDockerConnectionBeforeDefaultConfigDiscovery|LoadsConfigBeforeDockerConnection)$' -count=1
• go test ./cmd/compose ./pkg/compose -count=1
• make lint
• make test
• make validate
• make build
• Manual smoke: empty directory plus unreadable Docker socket returns permission denied while trying to connect to the docker API ....
• Manual smoke: explicit COMPOSE_FILE directory still returns read ... is a directory.
• make build-and-e2e attempted locally. It still fails in this Docker Desktop environment on TestImageVolume, TestImageVolumeRecreateOnRebuild, and TestComposeModel; those same local/base failures were reproduced previously on clean current origin/main.