services.down() fails if container_name is set in the dockerfile
If the dockerfile defines the container name, then the calling services.down() fails as the down method looks for a container named with the following pattern:
projectName + '_' + serviceName + '_1'
In such case, the down method() should use the container_name defined in the dockerfile instead of its own naming format.
Indeed, the dreaded message `'Conflict. The container name "/
One workaround, as based on the current implementation of down would be:
const projectContainers = await docker.listContainers({
all: true,
filters: { label: [`com.docker.compose.service=${serviceName}`] },
});
for await (const projectContainer of projectContainers) {
const container = await docker.getContainer(projectContainer.Id);
if (projectContainer.State === 'running') {
console.log('Stopped running container', projectContainer);
await container.stop();
}
await container.remove();
}
Whereas serviceName is the name used under your docker-compose's services list/array.
One can also add one's own labels.
There hasn't been any progress on this issue and thankfully this was mentioned in here, because the error is "eaten" and I was confused why down is not working.
Am I missing something or is it really just taking the "container_name" property (or use default if it doesn't exist). I'm willing to write a PR, just want to be sure I'm not missing something.
I also noticed there is an empty array services = [] which does nothing.
I would propose that this error will return successfull / unsucessfull downs, so a developer can react to this properly without being kept in the dark.
I'm having a similar issue. compose.down() is not killing the containers
And also, compose.up() does not do what docker compose up -d command does, that is to replace current running containers with new version in case something in the config changed