Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Warning when running docker from symlink #12412

Open
aXtionTim opened this issue Dec 19, 2024 · 6 comments · May be fixed by compose-spec/compose-go#722
Open

[BUG] Warning when running docker from symlink #12412

aXtionTim opened this issue Dec 19, 2024 · 6 comments · May be fixed by compose-spec/compose-go#722

Comments

@aXtionTim
Copy link

aXtionTim commented Dec 19, 2024

Description

We create symlinks for all our dependent projects and run docker compose up -d from there. This generates a lot of warnings recently, which are annoying.

The docs state that you can use the name attribute in your compose file, but the issue still persists.

Steps To Reproduce

  1. In Linux (arch in my case)
  2. Specify a symlink to a project folder which contains a docker-compose.yml
  3. Navigate to the symlink
  4. Run docker compose up -d
  5. The following warning is shown:
❯ dcupd
WARN[0000] project has been loaded without an explicit name from a symlink. Using name "<symlink_name>" 
[+] Running 1/0
 ✔ Container <symlink_name>-app-1  Running  

Compose Version

❯ docker compose version
Docker Compose version 2.32.1
❯ docker-compose version
Docker Compose version 2.32.1

Docker Environment

Client:
 Version:    27.3.1
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc.)
    Version:  2.32.1
    Path:     /usr/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 127
  Running: 18
  Paused: 0
  Stopped: 109
 Images: 858
 Server Version: 27.3.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 88aa2f531d6c2922003cc7929e51daf1c14caa0a.m
 runc version: 
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.4-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 30.96GiB
 Name: lt-axtionunix07
 ID: 64ccc3fb-930a-4ecd-af96-fe7b9140b7b0
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

Example docker-compose.yml:

name: example-name
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      target: development
@jtognazzi
Copy link

If the name of the symlink match the name of the canonical directory then the warning disappears.

@ndeloof
Copy link
Contributor

ndeloof commented Dec 19, 2024

We added this warning because the mechanism to generate project name based on local folder was creating some confusion for our users. To avoid such an ambiguity and remove this warning you can run compose with (-p) --project-name xx

@ndeloof
Copy link
Contributor

ndeloof commented Dec 19, 2024

Closing as "not planned" as this warning is there for reasons

@ndeloof ndeloof closed this as not planned Won't fix, can't repro, duplicate, stale Dec 19, 2024
@jtognazzi
Copy link

But in this case adding
name: xx

to the compose file should also remove the warning and this is not the case

@ndeloof
Copy link
Contributor

ndeloof commented Dec 19, 2024

yes indeed, this should be considered

@ndeloof ndeloof reopened this Dec 19, 2024
@ndeloof
Copy link
Contributor

ndeloof commented Dec 19, 2024

the challenge we will have to address here is that this sanity check takes place before compose.yaml file is loaded, and we know name attribute is set. To be investigated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants