"This issue was filed by an AI agent on a human's behalf. The human submitter may not have independently verified the report."
What this issue is about
PR #14093 fixed create and start so that targeting a declared jobs: entry (instead of a services: entry) gives a clear, actionable error instead of compose-go's raw no such service: <name> — and, when COMPOSE_PROJECT_NAME is set, instead of silently doing nothing.
That fix was scoped to create/start only. The same underlying helper, projectOrName (cmd/compose/compose.go), also backs stop, kill, pause, unpause, logs, rm, down, ps and events — none of which got the fix, so they still show both problems:
- Confusing raw error — without
COMPOSE_PROJECT_NAME, targeting a job by name surfaces compose-go's generic no such service: <name> instead of a message pointing the user at docker compose run.
- Silent no-op — with
COMPOSE_PROJECT_NAME set, projectOrName falls back to a label-driven, file-less project on any project-load failure (including "no such service"), swallowing the error entirely. Since a job that was never run left no container behind, the label-driven command finds nothing to act on and exits 0 as if it had succeeded.
Illustration
Given:
services:
web:
image: nginx
jobs:
migrate:
image: alpine
command: ["echo", "migrating"]
triggers:
manual: trueWithout COMPOSE_PROJECT_NAME:
$ docker compose stop migrate
no such service: migrate
Nothing here tells the user migrate is actually a valid job name and that docker compose run migrate is what they meant. Compare with start, fixed in #14093:
$ docker compose start migrate
job "migrate" can only be triggered with "docker compose run"
With COMPOSE_PROJECT_NAME set — as CI pipelines and scripts commonly do:
$ export COMPOSE_PROJECT_NAME=myproj
$ docker compose stop migrate; echo "exit=$?"
exit=0
No error, no output: stop silently did nothing.
Suggested fix
Generalize the jobTargetErr/unselectedJobs helpers introduced in #14093 (cmd/compose/run.go) to the other projectOrName callers — or fold the check directly into projectOrName so every caller benefits at once, rather than repeating the wiring per command.
"This issue was filed by an AI agent on a human's behalf. The human submitter may not have independently verified the report."
What this issue is about
PR #14093 fixed
createandstartso that targeting a declaredjobs:entry (instead of aservices:entry) gives a clear, actionable error instead of compose-go's rawno such service: <name>— and, whenCOMPOSE_PROJECT_NAMEis set, instead of silently doing nothing.That fix was scoped to
create/startonly. The same underlying helper,projectOrName(cmd/compose/compose.go), also backsstop,kill,pause,unpause,logs,rm,down,psandevents— none of which got the fix, so they still show both problems:COMPOSE_PROJECT_NAME, targeting a job by name surfaces compose-go's genericno such service: <name>instead of a message pointing the user atdocker compose run.COMPOSE_PROJECT_NAMEset,projectOrNamefalls back to a label-driven, file-less project on any project-load failure (including "no such service"), swallowing the error entirely. Since a job that was never run left no container behind, the label-driven command finds nothing to act on and exits0as if it had succeeded.Illustration
Given:
Without
COMPOSE_PROJECT_NAME:Nothing here tells the user
migrateis actually a valid job name and thatdocker compose run migrateis what they meant. Compare withstart, fixed in #14093:With
COMPOSE_PROJECT_NAMEset — as CI pipelines and scripts commonly do:No error, no output:
stopsilently did nothing.Suggested fix
Generalize the
jobTargetErr/unselectedJobshelpers introduced in #14093 (cmd/compose/run.go) to the otherprojectOrNamecallers — or fold the check directly intoprojectOrNameso every caller benefits at once, rather than repeating the wiring per command.