Skip to content

Custom compose project name not handled properly #361

Description

@NathanBaulch

Quite a few areas of lazydocker are broken when working with compose projects that were started with a custom project name, eg docker compose -p foo up -d. It looks like some of these can be fixed by conditionally adding the -p flag to the command templates (project name context is not always available):

commandTemplates:
  dockerCompose:  docker compose
  restartService: '{{ .DockerCompose }} -p {{ .Service.Container.ProjectName }} restart {{ .Service.Name }}'
  startService:   '{{ .DockerCompose }} -p {{ .Service.Container.ProjectName }} start {{ .Service.Name }}'
  ...

However project name context is not passed to the bulk commands so I wasn't able to "fix" those in the same way.

It seems like we either need to implement a -p flag similar to -f or find a reliable way to discover and apply custom project names internally. Unfortunately there is no docker-compose ls and docker-compose config doesn't look at what's actually running. Maybe the existing strategy of looking for a com.docker.compose.project label could be moved out of the gui package?

By the way, I'm aware of the top level name element introduced earlier in the year but the spec specifically says this should be overridable (-p flag or COMPOSE_PROJECT_NAME env var).

Actually, that's probably a much better workaround than modifying all the templates - just make sure COMPOSE_PROJECT_NAME is set in the current shell. This seems to work reliably in my project COMPOSE_PROJECT_NAME=foo lazydocker. It doesn't look like lazydocker supports dotenv files, so perhaps the popular godotenv package could be integrated?

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions