[BUG] Service invisible to build when using profiles

[Gabgobie]

Description

Profiles were added to enable us to choose which images should be included in a docker compose up.

Unfortunately, build dependencies are also filtered.

As a result, my base image - which should never be started - is either unavailable to dependent services or started alongside them.

Steps To Reproduce

Use this simple compose and try to run docker compose --profile classroom up

services:
    base:
        pull_policy: "never"
        image: "internal/base:latest"
        profiles:
            - "disabled_services"
        build:
            context: .
            tags:
                - "internal/course:base"
                - "internal/base:latest"
            dockerfile_inline: |
                FROM ghcr.io/astral-sh/uv:debian

                ENV DEBIAN_FRONTEND=noninteractive
                ENV UV_LINK_MODE=copy

                RUN apt update
                RUN apt full-upgrade -y
                RUN apt install -y --no-install-recommends curl git

                SHELL ["/bin/bash", "-c"]

                RUN curl -fsSL https://install.julialang.org | sh -s -- -y --default-channel=lts --path=/usr/local/juliaup --add-to-path=no
                ENV PATH=/usr/local/juliaup/bin:$$PATH
                RUN julia --version

                ENTRYPOINT ["/bin/bash", "-c"]
                CMD ["bash"]

    classroom:
        pull_policy: "never"
        image: "internal/classroom:latest"
        profiles:
            - "all"
            - "classroom"
        build:
            context: .
            tags:
                - "internal/course:classroom"
                - "internal/classroom:latest"
            additional_contexts:
                base: service:base
            dockerfile_inline: |
                FROM base

                # Prepare impure global venv
                RUN uv venv --seed --python 3.14 /.venv
                ENV VIRTUAL_ENV=/.venv
                ENV PATH=/.venv/bin:$$PATH

                # Install dependencies to match state right after following along with the installation guide
                RUN uv pip install jupyter
                RUN julia -e 'using Pkg; Pkg.add(["IJulia"]); Pkg.update(); Pkg.instantiate()'

                WORKDIR /course

                ENTRYPOINT ["uv", "run", "jupyter", "notebook"]
                CMD ["--help-all"]

This should result in a launch failure because base is unavailable. If you remove the profile from the base image, it will again be able to build and run the classroom image but the base image will also be launched.

When not using profiles at all and launching with docker compose up classroom, base is built as expected and only classroom is started.

I believe this is a bug but feel free to demote this to feature/change request if you think this is working as expected.

Compose Version

docker compose version
Docker Compose version v5.5.1

Docker Environment

docker info
Client: Docker Engine - Community
 Version:    29.8.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.37.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.5.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 12
  Running: 10
  Paused: 0
  Stopped: 2
 Images: 18
 Server Version: 29.8.0
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  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
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1294c24a7da8e5a793ed378161673abe94118892
 runc version: v1.5.1-0-g8f2685a4
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.14.0-687.46.1.el9_8.x86_64
 Operating System: Rocky Linux 9.8 (Blue Onyx)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: enough
 Name: example.com
 ID: nope
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables
  EnableUserlandProxy: true
  UserlandProxyPath: /usr/bin/docker-proxy

Anything else?

No response

[vaguul]

Could you try separating the build from startup while keeping the profile on base?

docker compose --profile classroom build classroom
docker compose --profile classroom up --no-build classroom

In v5.5.1, the standalone build command keeps disabled resources, and addBuildDependencies follows service: additional contexts, including services in DisabledServices. The build path then enables those dependencies for building. That suggests it can build base without enabling it for the subsequent up.

I have checked that path in the source but have not run your images. If this works, it would help narrow the regression to the implicit build during up, rather than profile handling in the standalone build command.

[Gabgobie]

Thanks for getting to this so quickly.

[myuser@docker course-public]$ docker compose --profile classroom up
service "classroom" declares unknown service "base" as additional contexts base

[myuser@docker course-public]$ docker compose --profile classroom build classroom
service "classroom" declares unknown service "base" as additional contexts base

[myuser@docker course-public]$ docker compose --profile classroom up --no-build classroom
service "classroom" declares unknown service "base" as additional contexts base

---

After removing the profiles key from services:base:

[myuser@docker course-public]$ docker compose --profile classroom up -d
[+] up 3/3
 ✔ Network course-public_default                Created
0.1s ✔ Container course-public-classroom-1      Started
0.4s ✔ Container course-public-base-1           Started

Edit: formatting

[Shubham-Padkonde]

I reproduced the error in compose-go with consistency checks enabled: the additional-context lookup uses GetService, which rejects services in DisabledServices before the build path runs. A focused fix can validate the disabled build service without enabling it for startup. The regression now passes locally, including rejection of missing and image-only context targets. I am running the full library checks before proposing a PR. Prepared with Codex assistance.

[ndeloof]

Opened a draft regression test at #14242 (expected to fail until compose-go bumps past compose-spec/compose-go#931), and reviewed/approved that fix upstream.