[BUG] inconsistent handling for the attach property between docker compose up and logs

[luciangabor]

Description

The attach property documentation says logs are collected only when explicitly required for the service it's set to false, but it's not working as expected for the logs command.

Steps To Reproduce

1. Given this compose.yaml

services:
  interesting:
    build:
      dockerfile_inline: |
        FROM busybox
        CMD echo something interesting

  irrelevant:
    build:
      dockerfile_inline: |
        FROM busybox
        CMD echo something irrelevant
    attach: false

2. Observe the output of the up and logs commands

$ docker compose --progress none up --build --force-recreate
Attaching to interesting-1
interesting-1  | something interesting
interesting-1 exited with code 0

$ docker compose logs
irrelevant-1  | something irrelevant
interesting-1  | something interesting

The fact that it works for the up command might not even be that relevant, since for long running services up -d would be the norm and only then the attach property would be useful so that logs -f only shows more ... relevant logs.

Compose Version

Docker Compose version v2.24.6

Docker Environment

No response

Anything else?

There's also a ... puzzling behavior when the logging driver is set to none.

Given this compose.yaml

services:
  silent:
    build:
      dockerfile_inline: |
        FROM busybox
        CMD echo logging disabled?
    logging:
      driver: none

The result of the same commands would be to ... see the logs but get an error when trying to ... see them again:

$ docker compose --progress none up --build
Attaching to silent-1
silent-1  | logging disabled?
silent-1 exited with code 0

$ docker compose logs
WARN[0000] Can't retrieve logs for "imp-silent-1": Error response from daemon: configured logging driver does not support reading 

If the attach property would be taken into account for logs, the none logging driver could be complemented by setting (maybe even implicitly) the attach to false and avoid this issue too.

[ndeloof]

attach indeed only applies to the up command as this one .. attach to container to get logs. logs command on the other hand, just like docker logs, query docker engine for collected logs, and depends on log driver being used. The compose specification trying to abstract away from implementation details doesn't distinguish those scenarios

[luciangabor]

I was testing this issue using the latest ci artifacts (https://github.com/docker/compose/actions/runs/8063698832) and stumbled upon a regression

here's my setup:

$ find -name '*.yaml' -print -exec cat {} \;
./compose.yaml
include:
  - path:
      - dir/included.yaml
./dir/included.yaml
services:
  service:
    extends:
      file: extended.yaml
      service: service
./dir/extended.yaml
services:
  service:
    build: .

the regression is about running compose from a different dir:

$ docker compose version
Docker Compose version e2762b1

$ find
.
./compose.yaml
./dir
./dir/included.yaml
./dir/extended.yaml

$ docker compose config
name: attach
services:
  service:
    build:
      context: /path/to/attach/dir
      dockerfile: Dockerfile
    networks:
      default: null
networks:
  default:
    name: attach_default

$ env -C dir docker compose config
cannot read extended.yaml

[ndeloof]

please open a dedicated issue for this