config output strips quote marks and loses version number

[sixeyed]

Description of the issue

docker-compose config has a reversion in the 1.27 release. The output strips the minor version number and removes quote marks for cpu limits and ports. This turns a valid input file into invalid output, so it can't be deployed as a stack in Swarm mode.

Context information (for bug reports)

This is an issue because you can't join multiple Compose files together for a stack deploy, so you use config to join all your overrides into a single stack file to deploy. I guess this will break a lot of pipelines (and the exercises in chapter 14 of Learn Docker in a Month of Lunches).

Output of docker-compose version

PS>docker-compose version
docker-compose version 1.27.0, build 980ec85b
docker-py version: 4.3.1
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.1c  28 May 2019

Steps to reproduce the issue

Input:

PS>cat .\docker-compose.yml
version: "3.7"  

services:       
  nginx:        
    image: nginx
    deploy:
      resources:
        limits:
          cpus: "0.75"

Output from 1.27:

PS>docker-compose config   
services:
  nginx:
    deploy:
      resources:
        limits:
          cpus: 0.75
    image: nginx
version: '3'

Version 3.7 has become version 3, and the cpu has lost its quotes. If you try to stack deploy the output then you get the error services.nginx.deploy.resources.limits.cpus must be a string.

Expected result

This is the output from 1.22 - which is correct and will deploy as a stack:

docker-compose config

services:
  nginx:
    deploy:
      resources:
        limits:
          cpus: '0.75'
    image: nginx
version: '3.7'

Additional information

Docker Desktop Edge on Windows.

[HeavenVolkoff]

Also experiencing this issue, reverting to docker-compose 1.26 solves it.

[chrisregnier]

I also, just hit this with docker-compose 1.27.4 for both mac and linux which breaks my builds cause we use the docker-compose config output in docker swarm, which apparently only allows strings.
The issue #7766 is related, but doesn't fix the output here

[lnking81]

As a workaround I just use docker-compose config|sed -E "s/cpus: ([0-9\\.]+)/cpus: '\\1'/"

[csmithson12345]

@sixeyed I found this because it broke Ch14 of DIAMOL :) . just manually quoting the cpu value in the stack output to get it working, but yes, I would love for it to work as smoothly as it does in your demonstrations.

[broneq]

bump

[cadavre]

Any news on this? More than 0.5yr and no fix to core functionality?

[camol]

same here

[marlonklc]

docker-compose config|sed -E "s/cpus: ([0-9\.]+)/cpus: '\1'/"

this works for me on windows, thanks man !

[andyjaeger]

Also having this issue because we use it to merge compose files for deployment...

[eltonk]

2 years later, and the issue still here.
I'm currently using docker-compose version 1.29.2

[chrisregnier]

This is still a problem for us as well, but due to the upcoming forced transition to docker-compose V2 and V2 using the strict compose spec, I can't imagine this will ever get fixed at this point. So should this be turned into a feature request to have a docker compose config --spec=swarm ... mode? I would love to have an explicit mode that will check against the swarm spec instead of giving compose spec warnings about fields that aren't applicable.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ndeloof]

docker-compose config is not designed to render the exact same configuration syntax used by input file, but to validate and dump the processed compose model. So it is fully legitimate for cpus: '0.75' that can be parsed as a numeric value to be rendered without quotes.

About version: '3' that sounds like a bug in compose v1, anyway this one is deprecated, you should use Compose v2 which adopted the compose specification, and doing so version is just ignored/skipped from output.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.