docker-compose run ignores the container_name directive

[eldarj]

Description

See #1753 reported by @dunk and @aanand 's PR #1755 for more details.

In the #1753 issue reported, @dunk executed:

docker-compose up
docker-compose run myservice
PR #1930 adds a --name param to docker-compose allowing for one off executions with a custom name

Since a container with a fixed name is already running, the behavior of docker-compose run should be no different than that of docker-compose scale, which is basically the same thing as running docker run --name $some_name_that_already_exists.

Now, when running docker-compose up, the container_name directive is respected; when running docker-compose run myservice, the container_name directive is ignored and the default auto-generated container name is used.

Steps To Reproduce

No response

Compose Version

$ docker-compose --version
docker-compose version: 1.4.0

[ndeloof]

You're using docker compose v1 which is End of Life for years. Urgently adopt Docker Compose v2 !

docker-compose run is by design used to run one-off command, expected to complete short time. Typically, running some data migration or maintenance tasks using same image as the main service. Such a container name MUST NOT collide with service name, which in many cases is running concurrently. So the generated name with a random suffix.

Can you please clarify the use-case you have to require a fixed container name ?

[ndeloof]

Closing as user didn't provided requested detais

[storyd]

I ran into this decade long conversation when trying to diagnose some docker build issues with 3rd party installers and >alpine3:19

services:
  api:
    image: python:3.11-alpine3.19
    container_name: aws-sam
    ...

docker compose run --remove-orphans api bash
WARN[0000] Found orphan containers ([backend-api-run-3a33d7dbd563]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

My opinion is either honor container_name and error on run if one is already running, or if docker compose run is intended for one off runs, then the expected behavior would be terminate any would be orphans if container_name is defined.

Hopefully someone sees this, but I won't hold my breath, the last conversation got closed then ignored for the better part of a decade. seems to me this community prefers open new, close quick, and conversation fragmentation instead of monitoring for activity on closed tickets.