[BUG] docker-compose 2.17.1 changes syntex limitation - will not accept stack names with a '.'

[ezaton]

Description

Regression from previous version (2.17) - a stack name which includes a '.' symbol is now considered illegal:

Example:
$ docker-compose ps
"lokal.co.il" is not a valid project name: it must contain only characters from [a-z0-9_-] and start with [a-z0-9]

Steps To Reproduce

Have a working (on previous versions) stack with a name in it:
mkdir domain.co.il
cd domain.co.il
cat << EOF > docker-compose.yaml
version: '3'

volumes:
domain_html:

networks:
web_internal:

services:
domain.co.il:
image: nginx:alpine
restart: always
volumes:
- lokal_html:/usr/share/nginx/html:ro
environment:
- VIRTUAL_HOST=domain.co.il
- VIRTUAL_PORT=80
- VIRTUAL_NETWORK=web_internal
networks:
- web_internal
logging:
driver: "json-file"
options:
max-size: "30m"
max-file: "3"
EOF

docker-compose ps (fails)
docker-compose-v2.17 ps # Returns results

Compose Version

No response

Docker Environment

Docker Compose version v2.17.1

Worked correctly on:
Docker Compose version v2.17.0

Anything else?

No response

[yskszk63]

I am experiencing the same problem.
For example, when I run the Dev Container CLI with the following configuration.

https://github.com/yskszk63/my-devcontainer-with-compose

It is as follows.

$ docker-compose --version
Docker Compose version 2.17.1
$ devcontainer --workspace-folder . up
[18 ms] @devcontainers/cli 0.33.0. Node.js v19.8.1. linux 6.2.8-arch1-1 x64.
Error: Command failed: docker-compose -f /home/yskszk63/work/my-devcontainer-with-compose/.devcontainer/docker-compose.yml --profile * config
    at Dc (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:1921:867)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async uie (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:1887:1370)
    at async aie (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:1869:3170)
    at async _ie (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:1936:2807)
    at async zf (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:1936:3759)
    at async aoe (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:2060:17326)
    at async ooe (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:2060:17067)
{"outcome":"error","message":"Command failed: docker-compose -f /home/yskszk63/work/my-devcontainer-with-compose/.devcontainer/docker-compose.yml --profile * config","description":"An error occurred retrieving the Docker Compose configuration."}
$ 
$ docker-compose -f /home/yskszk63/work/my-devcontainer-with-compose/.devcontainer/docker-compose.yml --profile \* config
".devcontainer" is not a valid project name: it must contain only characters from [a-z0-9_-] and start with [a-z0-9]

Up to 2.17.0, it worked as follows.

$ docker-compose --version
Docker Compose version 2.17.0
$ devcontainer --workspace-folder . up
[15 ms] @devcontainers/cli 0.33.0. Node.js v19.8.1. linux 6.2.8-arch1-1 x64.
[309 ms] Start: Run: docker-compose -f /home/yskszk63/work/my-devcontainer-with-compose/.devcontainer/docker-compose.yml --profile * config
[332 ms] name: devcontainer
...
"outcome":"success","containerId":"5f184c38eafab019b8f9f0bc73336de67e1e18f1f0b51f0ef50b444d6f451a67","composeProjectName":"my-devcontainer-with-compose_devcontainer","remoteUser":"vscode","remoteWorkspaceFolder":"/workspace"}

[milas]

Fixed by #10406 and released as v2.17.2.

Thanks for the report!

[bryandam]

@milas: FWIW, I'm coming across this same issue (our project names have periods) in Docker Desktop v4.18.0 which included Docker Compose v2.17.2:

C:\>docker-compose  -f "C:\[...]\docker-compose.yml" -f "C:\[...]\docker-compose.override.yml" -p dockercompose5310333527275421019 --ansi never --profile "*" config
name Does not match pattern '^[a-z0-9][a-z0-9_-]*$'

C:\>docker-compose version
Docker Compose version v2.17.2

The logic checks out: a project name with periods in the name doesn't match that RegexPattern.
Downgraded to Docker Desktop 4.17.0 with Docker Compose v2.15.1 and the same projects composed just fine.

[bertrandgorge]

Same problem here with a recent upgrade to docker desktop 4.18.0 (Docker Compose version v2.17.2) :

"tripleperformance_MW35" is not a valid project name: it must contain only characters from [a-z0-9_-] and start with [a-z0-9]

This is actually quite a show stopper since our project even follows the rules !

[bryandam]

@bertrandgorge I think that's by design as according to #10431 uppercase violates the specifications and therefore that error is valid.

What I'm not certain of right now is if periods are valid according to the spec. In my case it just say 'name is not...' without mentioning the actual name that's violating the regex. So, to be fair, I'm guessing it's the same issue of having periods in the name as @ezaton reported here. Though, full disclosure, I've been too lazy to do a minimal repro required to open a new issue.

[bertrandgorge]

Ah ! I didn't see the uppercase thing ! Indeed... Thanks for the tip! (for those reading this later - in such case, it seems to be enough to put it all in lowercase, the build now works and I didn't seem to have lost my volumes)

[milas]

@bryandam If I'm understanding your case correctly, this is expected.

If you have:

name: my.app
services:
  nginx:
    image: nginx

That's an invalid Compose YAML file - name does not meet the regex. It would also be rejected if e.g. a field had an invalid type or was not legal YAML. These are more extreme, but fundamentally the Compose loader does schema validation on each file as it's loaded, so they do need to be valid.

The reason it works on an older version is because Compose was doing automatic normalization on the name field in YAML by mistake - that logic was only supposed to apply when Compose determines a name from the directory (i.e. to ensure that Compose itself generates valid names). On my example above, running docker compose config on an older version yields name: myapp with the . removed.

[milas]

(All that said, I am looking at improving the error messaging around schema validation, as it's rather confusing as seen in this thread)

[bryandam]

Thanks for the reply @milas. Since this bug was marked as 'fixed' I was assuming that the period was valid.

What's confusing to me is that I'm not even specifying a name property in the root of the document. I tried adding one and that didn't fix it either.

Here's my sanitized (hopefully) compose file:

version: '3.9'

services:
  mongodb:
    image: mongo
    restart: always
    container_name: mongodb
    hostname: mongodb
    ports:
      - 27017:27017
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${USER}
      MONGO_INITDB_ROOT_PASSWORD: ${PASS}
    volumes:
      # Set up read/write volumes to store data in host file system so data will persist
      - ${APPDATA}/mongodb:/data/db:rw
      - ${APPDATA}/mongoconfig:/data/configdb:rw
    networks:
      - org-dev
      
  mongo-express:
    image: mongo-express
    restart: unless-stopped
    container_name: mongo-express
    hostname: mongoexpress
    ports:
      - 8080:8081
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME: ${USER}
      ME_CONFIG_MONGODB_ADMINPASSWORD: ${PASS}
      ME_CONFIG_MONGODB_SERVER: mongodb
      ME_CONFIG_OPTIONS_EDITORTHEME: material-darker
      ME_CONFIG_MONGODB_ENABLE_ADMIN: true
    depends_on:
      - mongodb
    links:
      - mongodb:mongodb
    networks:
      - org-dev

  org.cloud.project.api:
    image: ${DOCKER_REGISTRY-}catalog:local
    hostname: catalog
    environment:
      # env variables below will overwrite anything configured in appSettings.json
      ASPNETCORE_ENVIRONMENT: Development
      ASPNETCORE_URLS: https://+:443;http://+:80
      VulnerabilityCatalogDatabase__ConnectionString: mongodb://${USER}:${PASS}@mongodb:27017
      SeriLog__WriteTo__3__Args__databaseUrl: mongodb://${USER}:${PASS}@mongodb:27017/logs?authSource=admin
    ports:
      - 8000:80
      - 4433:443
    volumes:
      # set up read-only mapping to host file system to override values at runtime from usersecrets
      # https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-7.0&tabs=windows
      - ${APPDATA}\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro
      # set up read-only mapping to TLS certificates 
      # https://learn.microsoft.com/en-us/aspnet/core/security/docker-compose-https?view=aspnetcore-7.0
      - ${APPDATA}\ASP.NET\Https:/root/.aspnet/https:ro
    networks:
        - org-dev
    build:
      context: ../org.cloud.project.api
      dockerfile: Dockerfile
      args:
        - FEED_ACCESSTOKEN=${VSS_NUGET_ACCESSTOKEN}

networks:
  org-dev:
    external: false
    name: org-dev

[milas]

Hm, that file seems ok, so there must be something else here.

You mentioned:

our project names have periods

Can you clarify? Is that via dir name, -p flag, or YAML field?

Also, I noticed you're running from C:\ above - it's possible there's something Windows-specific here, so I'll look into that. (One of the edge cases some of the name validation fixed were before was actually around running from drive root on Windows, so it's possible there's still a weird interaction here.)

Can you also confirm the exact error you're getting? There's several error strings that are VERY similar here unfortunately 😅

[bryandam]

What I meant by project names is in the example above 'org.cloud.project.api' as those represent the VS project name and the folder for the build context. To be clear, maybe those are red-herrings ... I just know it's not uppercase because we don't use uppercase.

Can you also confirm the exact error you're getting?

name Does not match pattern '^[a-z0-9][a-z0-9_-]*$'

That's the whole thing, unmodified. Which is why I'm only guessing it's the periods and latched onto this issue. I legit don't know if periods are my actual issue because the error doesn't tell me the string it's complaining about.

And again, I'm being too lazy to do a repro though so feel free to give me the finger and tell me to try harder and come back when I'm ready to actually be helpful.

[bryandam]

Figured it out. We had a override file that I had overlooked and it had an uppercase name element.

[hpe-ykoehler]

So, if ".devcontainer" is not a valid stack name, and the solution was to implement proper stack name validation rules. How do we get devcontainer working again, since they required/recommend the use of .devcontainer folder in the stack.

Do we need a change to devcontainer/cli to pass some other argument to docker-compose?

[thaJeztah]

I think one option would be for the devcontainer compose-file to include a name: top-level field for it to use a name that's not based on the directory name (.devcontainer); https://docs.docker.com/compose/compose-file/04-version-and-name/

[hpe-ykoehler]

Ok thanks, for this issue on devcontainer/cli related to this.
microsoft/vscode-remote-release#512