Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] docker compose config --ouput=json omits x-* fields - generally some differences in marshalled YAML vs. JSON forms #11528

Closed
Code0x58 opened this issue Feb 20, 2024 · 4 comments

Comments

@Code0x58
Copy link

Code0x58 commented Feb 20, 2024

Description

The JSON config output omits x-* entries. Diff from the actual generated JSON to the JSON-ified YAML of example below:

--- actual.json
+++ expect.json
@@ -2,18 +2,16 @@
     "name": "COMPOSE_PROJECT_NAME",
     "networks": {
         "default": {
-            "name": "COMPOSE_PROJECT_NAME_default",
-            "ipam": {}
+            "name": "COMPOSE_PROJECT_NAME_default"
         }
     },
     "services": {
         "some_service": {
-            "command": null,
-            "entrypoint": null,
             "image": "ubuntu:latest",
             "networks": {
                 "default": null
-            }
+            },
+            "x-something": "hello"
         }
     }
 }

My main issue is the absence of the x-* fields, but can see there's at least some additional difference as the default network's ipam, command, and entrypoint entries are omitted in YAML whereas it is an empty objects/nulls in the JSON.

I imagine in an ideal world that diff <(docker compose config --output=yaml | yq -output-format=json) <(docker compose config --output=json) would always have a 0 exit code/no diff, and that x-* fields would be included.

Steps To Reproduce

# docker-compose.yml
version: "4"
services:
  some_service:
    image: ubuntu:latest
    x-something: hello

docker compose config output

name: COMPOSE_PROJECT_NAME
services:
  some_service:
    image: ubuntu:latest
    networks:
      default: null
    x-something: hello
networks:
  default:
    name: COMPOSE_PROJECT_NAME_default

docker compose config --format=json | python3 -m json.tool output

{
    "name": "COMPOSE_PROJECT_NAME",
    "networks": {
        "default": {
            "name": "COMPOSE_PROJECT_NAME_default",
            "ipam": {}
        }
    },
    "services": {
        "some_service": {
            "command": null,
            "entrypoint": null,
            "image": "ubuntu:latest",
            "networks": {
                "default": null
            }
        }
    }
}

Compose Version

Docker Compose version v2.24.5
@ndeloof
Copy link
Contributor

ndeloof commented Feb 22, 2024

This issue is due to limitation in the golang json binding library: this one doesn't ditsinguish empty vs null (so "ipam": {} missing from output) and doesn't allow to restore x-* as inlined attributes (golang/go#6213)

We should be able soon-ish to workaround this limitation as compose-go is now able to manage the compose file parsing without having to convert input into go structs.

@ndeloof
Copy link
Contributor

ndeloof commented Feb 22, 2024

Can you please let us know which usage you have for compose config output as a json stream ?

@Code0x58
Copy link
Author

Code0x58 commented Feb 22, 2024

Thanks @ndeloof.

I'm using docker-compose.yml manifests to store additional configuration/information that is required for the deployment environment I'm working with, x-* feels like a natural place for this, particularly as I use things like service.extends. Its fairly similar in concept to how extra config is added for the ecs docker context, but not built in with go. This allows me to have things like compose['x-my-manifest-extension'] and compose['services']['some-service']['x-my-service-extension'].

In my case, I'm using python and prefer to avoid extra dependencies where possible, so am relying on the built in json parsing module. I've worked around the issue for now by piping the YAML output through yq --output-format=json.

@jhrotko jhrotko assigned ndeloof and unassigned jhrotko Feb 23, 2024
@ndeloof
Copy link
Contributor

ndeloof commented Mar 1, 2024

fixed by #11556

@ndeloof ndeloof closed this as completed Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants